Re: [Wien] Speed of cluster nodes
Am 14.11.2023 um 14:24 schrieb pluto via Wien: 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". This sequence is ok. Note, the x qtl step will automatically recalculate x lapw2 -fermi -so ..., so you get a new case.scf2up/dn file. When you get as EF, something must be wrong. When you reduce Emin in case.inso, you also have to adjust properly the number of electrons NOE in case.in2c (Check from the band ranges in case.output2 of a "normal" calculation how many bands you will cut away and reduce NOE accordingly). In any case, EF will be wrong since your k-mesh is not a regular one. And of course Emax must still be large enough to cover all electrons ... 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". When you rerun x lapwso with modified inso file, all previous data from the lapwso step are overwritten. What you describe is not possible. 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? Yes. 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
Re: [Wien] Speed of cluster nodes
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 WITH0.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@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 ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at
Re: [Wien] Speed of cluster nodes
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.atWIEN2k: 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
