[Wien] Speed of cluster nodes

[pluto]

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 at 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