[Wien] Speed of cluster nodes

[pluto]

Dear Prof. Blaha,

Reducing the energy window in case.inso seems to work, but there are 
some minor issues. I would like to clarify them.

Normally I run the sequence:

x lapw1 -band -up -p
x lapw1 -band -dn -p
x lapwso -up -p
x qtl -up -p -band -so
x qtl -dn -p -band -so

When I limit the range a lot in case.inso before starting this sequence, 
I don't have Fermi energy in the case.scf2up/dn (I paste such "bad" file 
below). This then leads to an error when running "x qtl".

It seems there is no error when first running "x lapw1 up/dn" and "x 
lapwso" with the default case.inso, then limiting the range in 
case.inso, and then re-running only "x lapwso".

Maybe you could comment what would be the correct sequence here.

Best,
Lukasz

PS: "x qtl" needs case.in1c for running correctly. So, if that file does 
not exist then I simply make a copy of the case.in1. Is that OK?





        TEMP.-SMEARING WITH    0.00200 Ry
           -S / Kb           =  -6.57973595
           -(T*S)/2          =  -0.00328987
           Chem Pot          = ************
          Bandranges (emin - emax) and occupancy:
         Energy to separate low and high energystates:    0.39949


:NOE  : NUMBER OF ELECTRONS          = 1440.000

:FER  : F E R M I - ENERGY(FERMI-SM.)= **************
:GMA  : POTENTIAL AND CHARGE CUT-OFF  16.00 Ry**.5








On 2023-11-11 18:20, Peter Blaha wrote:
> 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 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
>> _______________________________________________
>> 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