For your problem, you just need to reduce the Energy window in case.inso
when you do the fine k-mesh (no scf with this k-mesh).
Make sure, your emin does not cut bands, but falls in a "gap".
Usually, all k-points take the same time (within 10 % or so).
It looks more as if one node is (temporarely) overloaded or has network
(disk) problems.
Try to check it by logging into this node and use eg. "top".
Am 10.11.2023 um 18:53 schrieb pluto via Wien:
Dear Prof. Blaha, dear All,
Thank you for you comment. When changing numbers as you suggested the
convergence over few cycles didn't look very good. So I decided to redo
the calculation with init_lapw -prec 1 -ecut 0.999, I think this is
safer and I hope the files will be smaller. Once this is done, I will
try to reduce emax in case.inso.
The origin of the problem is that I would like to make a kx-ky mesh for
the slab, this means maybe 2000-3000 kpoints to see bands as surfaces
nicely. Then the output files become very large, and case.qtl files are
large too (I typically do a SOC and FM calculation). One can limit the
energy range in case.inq to e.g. from -1 to 1, but this sometimes (for
unknown reasons) leads to some counting issues of the bands, i.e.
different k-points have different bands order. This might be related to
the lower energy cutting though a band, but some time ago I tried
different ranges in case.inq and it was not very helpful (but I need to
try more). Anyway, not a big deal, in the end this can be sorted out in
many ways. In general most of the time I only need bands from say -10 to
10 eV around the Fermi level, so in general it is good to learn how to
calculate only that, perhaps increasing the calculation speed and
reducing the output file sizes.
Another question: I often run on the older cluster. All nodes should be
the same and I distribute k-points uniformly (e.g. 8 k-points per node).
I noticed that sometimes some nodes are calculating much slower (e.g.
lapw1 or lapwso) than other nodes. Is that normal? I would expect maybe
small fluctuations due to the particular CPU cooling efficiency etc.,
but nothing dramatic. Or perhaps sometimes some k-points need more time?
Best,
Lukasz
On 2023-11-07 18:42, Peter Blaha wrote:
I'm not quite sure what you mean.
restore your saved calculation and:
i) Reduce emax in case.inso
This reduces the size of case.vectorso, but has no influence on the
scf. (One iteration is enough).
ii) reduce Ecut in case.in1. However, this will make your spinorbit
calculation much less accurate. You need to run the scf, but it should
converge quicker .
Am 07.11.2023 um 18:26 schrieb pluto via Wien:
Dear All,
I have a larger FM-SOC calculation converged (and saved) with the
default Ecut.
I would like to converge with smaller Ecut (say 1 Ry), to have the
output files smaller.
Is there a good way to do this, using the converged one as a starting
point, to avoid the lenghty convergence?
Best,
Lukasz
_______________________________________________
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
_______________________________________________
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
--
--------------------------------------------------------------------------
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300
Email: peter.bl...@tuwien.ac.at WIEN2k: http://www.wien2k.at
WWW: http://www.imc.tuwien.ac.at
-------------------------------------------------------------------------
_______________________________________________
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html