[Wien] 'LOPW' - Plane waves exhausted
[solved] 'LOPW' - Plane waves exhausted Many thanks for the help! It seems I was able to solve the problem by removing the LOs AND setting the d-levels to LAPW for all atoms: -- WFFIL EF= 0.5 (WFFIL, WFPRI, ENFIL, SUPWF) 7.00 104 (R-MT*K-MAX; MAX L IN WF, V-NMT 0.303 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) 2 -1.83 0.002 CONT 0 00.30 0.000 CONT 1 10.30 0.000 CONT 1 -- I am not sure if I fully understand the reasoning, however, it seems to work... 2012/5/3 Laurence Marks L-marks at northwestern.edu: Apologies for the slow response.? Try removing the first d LAPW, having two for the same level can lead to problems (i think). I may be wrong, check what is in case.output1_* (it is too late for me). --- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu 1-847-491-3996 Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi On May 2, 2012 11:29 AM, Florian Meirer fmeirer.wien2k.mlist at gmail.com wrote: Thanks for the fast reply! As suggested I tested using LAPW instead of APW+lo first (changed all switches to 0 in case.in1_st) but it didn't work. I have LO terms for d-levels and tested changing to LAPW only for them (see below) - no success either... here is the content of my .in1_st file (lines 4-7 are the same for all 10 inequivalent atoms - all Ge, one Sn): -- WFFIL ?EF= 0.5 ? ? ? (WFFIL, WFPRI, ENFIL, SUPWF) ?7.00 ? ? ? 10 ? ?4 (R-MT*K-MAX; MAX L IN WF, V-NMT ?0.30 ? ?4 ?0 ? ? ?(GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) ?2 ? -1.83 ? ? ?0.002 CONT 0 ?2 ? ?0.30 ? ? ?0.000 CONT 0 ?0 ? ?0.30 ? ? ?0.000 CONT 1 ?1 ? ?0.30 ? ? ?0.000 CONT 1 ... ... K-VECTORS FROM UNIT:4 ? -9.0 ? ? ? 2.5 ?898 ? emin/emax/nband #red -- What could be wrong with the struct file? Is there something I do fundamentally wrong ... should I try to reduce symmetry? Many thanks! 2012/5/2 Laurence Marks L-marks at northwestern.edu: It could be that there is some error in your file. One test might be to use LAPW instead of APW+lo and see if that runs (a single iteration). If it does then your structure is OK. Please check the UG if you are unclear what to change in case.in1 Some comments that might be helpful: I believe that changing the number of k-points only helps by chance, i.e. avoiding a specific k-point that leads to problems, so that is not the issue. Similarly changing the number of parallel jobs should not matter, I would not reduce it to P, but you might be able to reduce the symmetry to something slightly lower than what you started with (e.g. P4mm + inversion or simple cubic). I use Cryscon for this, but I am sure that there are other ways. Last, maybe not least, the issue comes about for high-symmetry structures because the APW terms within the muffin-tins need to be orthogonal. With many identical atoms for higher L levels this can become complicated as many of the PW's are not unique (e.g. (001) and (002)). Hence I would check whether you have an LO terms for d-levels in your calculation by looking at case.in1. I don't think you should have, but maybe. You can also look in case.output1_* to see where they stop. It may be that you can change to LAPW for the d in case.in1 (I expect by default it is APW+lo). On Wed, May 2, 2012 at 9:59 AM, Florian Meirer fmeirer.wien2k.mlist at gmail.com wrote: Dear Wien2k users, I am having a problem with a supercell calculation: - I am running wien version 11.1 (Release 14/6/2011) on a Intel XEON X5650 @ 2.67Ghz (2 Processors), 24Gb RAM with operating system Ubuntu 64bit, fortran compiler ifort 11.1.073 and math libraries R_LIB (LAPACK+BLAS): -lmkl_lapack -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -openmp -lpthread -lguide - The purpose of my calculations is to perform a structural relaxation (PORT) around an impurity (Sn dopant in Germanium) - I successfully performed the same calculation for an As impurity in Silicon and achieved good agreement with literature and experimental data (XANES). - I started with the struct: -- Germanium F?? LATTICE,NONEQUIV.ATOMS:? 1 227 Fd-3m MODE OF CALC=RELA unit=ang ?10.691735 10.691735 10.691735 90.00 90.00 90.00 ATOM?? 1: X=0.1250 Y=0.1250 Z=0.1250 ? MULT= 2? ISPLIT= 2 ?? 1: X=0.8750 Y=0.3750 Z=0.3750 Ge1??? NPT=? 781? R0=0.5000 RMT=??? 2.2300?? Z: 32.0 -- then created a supercell (2x2x2) and replaced one Ge by Sn (final .struct file attached). The parameters I used for testing: R0's were adjusted to 0.5 for Ge and to
[Wien] Fixed Spin Moment Calculations (Heavy Elements)
Dear Wien2k users, I was keen to know if somebody has experience in doing FSM calculations for heavy elements (runsfm_lapw) Since it is mentioned in UG, -so interaction is not supported, how do we carry out a total energy calculation (-so contribution around 1.2-1.5 Ry per atom in heavy elements) for heavy elements at various volume changes for a fixed spin moment. Thanks and regards Suddhasattwa -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120503/4e28e855/attachment.htm
[Wien] version prior to wien2k
Dear users. I am needing to get a version prior to wien2k. how can I get -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120503/5822cc18/attachment.htm
[Wien] 'LOPW' - Plane waves exhausted
This is not quite a solution, it instead verifies that there are perhaps no other errors in your files. I downloaded your file this morning and tested it myself, and I do not reproduce the problem. I have an idea what the issue is, but I am not certain so some questions: a) What is the value of NMATMAX in SRC_lapw1/param.inc ? I have this set at 13000. It looks like you have plenty of memory so you may want to raise it. b) When you added the lopw.f file, did you use siteconfig to update or just do make. If the later, did you do make all then cp lapw1* ../ ? c) In the case that is working, what RKMAX is the program using (as it can reduce it when there is not enough space) d) Are you running mpi (I suspect not)? On Thu, May 3, 2012 at 5:31 AM, Florian Meirer fmeirer.wien2k.mlist at gmail.com wrote: [solved] 'LOPW' - Plane waves exhausted Many thanks for the help! It seems I was able to solve the problem by removing the LOs AND setting the d-levels to LAPW for all atoms: -- WFFIL ?EF= 0.5 ? ? ? (WFFIL, WFPRI, ENFIL, SUPWF) 7.00 ? ? ? 10 ? ?4 (R-MT*K-MAX; MAX L IN WF, V-NMT 0.30 ? ?3 ?0 ? ? ?(GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) 2 ? -1.83 ? ? ?0.002 CONT 0 0 ? ?0.30 ? ? ?0.000 CONT 1 1 ? ?0.30 ? ? ?0.000 CONT 1 -- I am not sure if I fully understand the reasoning, however, it seems to work... 2012/5/3 Laurence Marks L-marks at northwestern.edu: Apologies for the slow response.? Try removing the first d LAPW, having two for the same level can lead to problems (i think). I may be wrong, check what is in case.output1_* (it is too late for me). --- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu 1-847-491-3996 Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi On May 2, 2012 11:29 AM, Florian Meirer fmeirer.wien2k.mlist at gmail.com wrote: Thanks for the fast reply! As suggested I tested using LAPW instead of APW+lo first (changed all switches to 0 in case.in1_st) but it didn't work. I have LO terms for d-levels and tested changing to LAPW only for them (see below) - no success either... here is the content of my .in1_st file (lines 4-7 are the same for all 10 inequivalent atoms - all Ge, one Sn): -- WFFIL ?EF= 0.5 ? ? ? (WFFIL, WFPRI, ENFIL, SUPWF) ?7.00 ? ? ? 10 ? ?4 (R-MT*K-MAX; MAX L IN WF, V-NMT ?0.30 ? ?4 ?0 ? ? ?(GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) ?2 ? -1.83 ? ? ?0.002 CONT 0 ?2 ? ?0.30 ? ? ?0.000 CONT 0 ?0 ? ?0.30 ? ? ?0.000 CONT 1 ?1 ? ?0.30 ? ? ?0.000 CONT 1 ... ... K-VECTORS FROM UNIT:4 ? -9.0 ? ? ? 2.5 ?898 ? emin/emax/nband #red -- What could be wrong with the struct file? Is there something I do fundamentally wrong ... should I try to reduce symmetry? Many thanks! 2012/5/2 Laurence Marks L-marks at northwestern.edu: It could be that there is some error in your file. One test might be to use LAPW instead of APW+lo and see if that runs (a single iteration). If it does then your structure is OK. Please check the UG if you are unclear what to change in case.in1 Some comments that might be helpful: I believe that changing the number of k-points only helps by chance, i.e. avoiding a specific k-point that leads to problems, so that is not the issue. Similarly changing the number of parallel jobs should not matter, I would not reduce it to P, but you might be able to reduce the symmetry to something slightly lower than what you started with (e.g. P4mm + inversion or simple cubic). I use Cryscon for this, but I am sure that there are other ways. Last, maybe not least, the issue comes about for high-symmetry structures because the APW terms within the muffin-tins need to be orthogonal. With many identical atoms for higher L levels this can become complicated as many of the PW's are not unique (e.g. (001) and (002)). Hence I would check whether you have an LO terms for d-levels in your calculation by looking at case.in1. I don't think you should have, but maybe. You can also look in case.output1_* to see where they stop. It may be that you can change to LAPW for the d in case.in1 (I expect by default it is APW+lo). On Wed, May 2, 2012 at 9:59 AM, Florian Meirer fmeirer.wien2k.mlist at gmail.com wrote: Dear Wien2k users, I am having a problem with a supercell calculation: - I am running wien version 11.1 (Release 14/6/2011) on a Intel XEON X5650 @ 2.67Ghz (2 Processors), 24Gb RAM with operating system Ubuntu 64bit, fortran compiler ifort 11.1.073 and math libraries R_LIB (LAPACK+BLAS): -lmkl_lapack -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -openmp -lpthread -lguide - The purpose of my calculations is to perform a structural
[Wien] 'LOPW' - Plane waves exhausted
N.B., to see what value it is using do grep -e :RKM *.scf On Thu, May 3, 2012 at 8:37 AM, Laurence Marks l-marks at northwestern.edu wrote: This is not quite a solution, it instead verifies that there are perhaps no other errors in your files. I downloaded your file this morning and tested it myself, and I do not reproduce the problem. I have an idea what the issue is, but I am not certain so some questions: a) What is the value of NMATMAX in SRC_lapw1/param.inc ? I have this set at 13000. It looks like you have plenty of memory so you may want to raise it. b) When you added the lopw.f file, did you use siteconfig to update or just do make. If the later, did you do make all then cp lapw1* ../ ? c) In the case that is working, what RKMAX is the program using (as it can reduce it when there is not enough space) d) Are you running mpi (I suspect not)? On Thu, May 3, 2012 at 5:31 AM, Florian Meirer fmeirer.wien2k.mlist at gmail.com wrote: [solved] 'LOPW' - Plane waves exhausted Many thanks for the help! It seems I was able to solve the problem by removing the LOs AND setting the d-levels to LAPW for all atoms: -- WFFIL ?EF= 0.5 ? ? ? (WFFIL, WFPRI, ENFIL, SUPWF) 7.00 ? ? ? 10 ? ?4 (R-MT*K-MAX; MAX L IN WF, V-NMT 0.30 ? ?3 ?0 ? ? ?(GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) 2 ? -1.83 ? ? ?0.002 CONT 0 0 ? ?0.30 ? ? ?0.000 CONT 1 1 ? ?0.30 ? ? ?0.000 CONT 1 -- I am not sure if I fully understand the reasoning, however, it seems to work... 2012/5/3 Laurence Marks L-marks at northwestern.edu: Apologies for the slow response.? Try removing the first d LAPW, having two for the same level can lead to problems (i think). I may be wrong, check what is in case.output1_* (it is too late for me). --- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu 1-847-491-3996 Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi On May 2, 2012 11:29 AM, Florian Meirer fmeirer.wien2k.mlist at gmail.com wrote: Thanks for the fast reply! As suggested I tested using LAPW instead of APW+lo first (changed all switches to 0 in case.in1_st) but it didn't work. I have LO terms for d-levels and tested changing to LAPW only for them (see below) - no success either... here is the content of my .in1_st file (lines 4-7 are the same for all 10 inequivalent atoms - all Ge, one Sn): -- WFFIL ?EF= 0.5 ? ? ? (WFFIL, WFPRI, ENFIL, SUPWF) ?7.00 ? ? ? 10 ? ?4 (R-MT*K-MAX; MAX L IN WF, V-NMT ?0.30 ? ?4 ?0 ? ? ?(GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) ?2 ? -1.83 ? ? ?0.002 CONT 0 ?2 ? ?0.30 ? ? ?0.000 CONT 0 ?0 ? ?0.30 ? ? ?0.000 CONT 1 ?1 ? ?0.30 ? ? ?0.000 CONT 1 ... ... K-VECTORS FROM UNIT:4 ? -9.0 ? ? ? 2.5 ?898 ? emin/emax/nband #red -- What could be wrong with the struct file? Is there something I do fundamentally wrong ... should I try to reduce symmetry? Many thanks! 2012/5/2 Laurence Marks L-marks at northwestern.edu: It could be that there is some error in your file. One test might be to use LAPW instead of APW+lo and see if that runs (a single iteration). If it does then your structure is OK. Please check the UG if you are unclear what to change in case.in1 Some comments that might be helpful: I believe that changing the number of k-points only helps by chance, i.e. avoiding a specific k-point that leads to problems, so that is not the issue. Similarly changing the number of parallel jobs should not matter, I would not reduce it to P, but you might be able to reduce the symmetry to something slightly lower than what you started with (e.g. P4mm + inversion or simple cubic). I use Cryscon for this, but I am sure that there are other ways. Last, maybe not least, the issue comes about for high-symmetry structures because the APW terms within the muffin-tins need to be orthogonal. With many identical atoms for higher L levels this can become complicated as many of the PW's are not unique (e.g. (001) and (002)). Hence I would check whether you have an LO terms for d-levels in your calculation by looking at case.in1. I don't think you should have, but maybe. You can also look in case.output1_* to see where they stop. It may be that you can change to LAPW for the d in case.in1 (I expect by default it is APW+lo). On Wed, May 2, 2012 at 9:59 AM, Florian Meirer fmeirer.wien2k.mlist at gmail.com wrote: Dear Wien2k users, I am having a problem with a supercell calculation: - I am running wien version 11.1 (Release 14/6/2011) on a Intel XEON X5650 @ 2.67Ghz (2 Processors), 24Gb RAM with operating system Ubuntu 64bit, fortran compiler ifort 11.1.073 and math libraries R_LIB (LAPACK+BLAS):
[Wien] 'LOPW' - Plane waves exhausted
I used your struct file, init -b -numk 200 run -p -i 3 and I do NOT have any problems. I can see that some check is active for k-point nr.10, but finally, by automatically relaxing the orthogonality constrains, it runs without problems. Are you sure you applied the fixes supplied in the mailing list ? Eventually I could send you my version privately. A new release WIEN2k_12.1 is in preparation anyway, but it may still take some time. Am 03.05.2012 04:35, schrieb Laurence Marks: Apologies for the slow response. Try removing the first d LAPW, having two for the same level can lead to problems (i think). I may be wrong, check what is in case.output1_* (it is too late for me). --- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu http://www.numis.northwestern.edu 1-847-491-3996 Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi On May 2, 2012 11:29 AM, Florian Meirer fmeirer.wien2k.mlist at gmail.com mailto:fmeirer.wien2k.mlist at gmail.com wrote: Thanks for the fast reply! As suggested I tested using LAPW instead of APW+lo first (changed all switches to 0 in case.in1_st) but it didn't work. I have LO terms for d-levels and tested changing to LAPW only for them (see below) - no success either... here is the content of my .in1_st file (lines 4-7 are the same for all 10 inequivalent atoms - all Ge, one Sn): -- WFFIL EF= 0.5 (WFFIL, WFPRI, ENFIL, SUPWF) 7.00 104 (R-MT*K-MAX; MAX L IN WF, V-NMT 0.304 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) 2 -1.83 0.002 CONT 0 20.30 0.000 CONT 0 00.30 0.000 CONT 1 10.30 0.000 CONT 1 ... ... K-VECTORS FROM UNIT:4 -9.0 2.5 898 emin/emax/nband #red -- What could be wrong with the struct file? Is there something I do fundamentally wrong ... should I try to reduce symmetry? Many thanks! 2012/5/2 Laurence Marks L-marks at northwestern.edu mailto:L-marks at northwestern.edu: It could be that there is some error in your file. One test might be to use LAPW instead of APW+lo and see if that runs (a single iteration). If it does then your structure is OK. Please check the UG if you are unclear what to change in case.in1 Some comments that might be helpful: I believe that changing the number of k-points only helps by chance, i.e. avoiding a specific k-point that leads to problems, so that is not the issue. Similarly changing the number of parallel jobs should not matter, I would not reduce it to P, but you might be able to reduce the symmetry to something slightly lower than what you started with (e.g. P4mm + inversion or simple cubic). I use Cryscon for this, but I am sure that there are other ways. Last, maybe not least, the issue comes about for high-symmetry structures because the APW terms within the muffin-tins need to be orthogonal. With many identical atoms for higher L levels this can become complicated as many of the PW's are not unique (e.g. (001) and (002)). Hence I would check whether you have an LO terms for d-levels in your calculation by looking at case.in1. I don't think you should have, but maybe. You can also look in case.output1_* to see where they stop. It may be that you can change to LAPW for the d in case.in1 (I expect by default it is APW+lo). On Wed, May 2, 2012 at 9:59 AM, Florian Meirer fmeirer.wien2k.mlist at gmail.com mailto:fmeirer.wien2k.mlist at gmail.com wrote: Dear Wien2k users, I am having a problem with a supercell calculation: - I am running wien version 11.1 (Release 14/6/2011) on a Intel XEON X5650 @ 2.67Ghz (2 Processors), 24Gb RAM with operating system Ubuntu 64bit, fortran compiler ifort 11.1.073 and math libraries R_LIB (LAPACK+BLAS): -lmkl_lapack -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -openmp -lpthread -lguide - The purpose of my calculations is to perform a structural relaxation (PORT) around an impurity (Sn dopant in Germanium) - I successfully performed the same calculation for an As impurity in Silicon and achieved good agreement with literature and experimental data (XANES). - I started with the struct: -- Germanium F LATTICE,NONEQUIV.ATOMS: 1 227 Fd-3m MODE OF CALC=RELA unit=ang 10.691735 10.691735 10.691735 90.00 90.00 90.00 ATOM 1: X=0.1250
[Wien] 'LOPW' - Plane waves exhausted
Many thanks for your reply - the problem was that I did not successfully update the lapw1 files in wienroot after compiling the 'new' lopw.f file in SRC_lapw1/ using 'make all' (see my earlier email to the mailing list) Sorry for the inconvenience! 2012/5/3 Peter Blaha pblaha at theochem.tuwien.ac.at: I used your struct file, init -b -numk 200 run -p -i 3 and I do NOT have any problems. I can see that some check is active for k-point nr.10, but finally, by automatically relaxing the orthogonality constrains, it runs without problems. Are you sure you applied the fixes supplied in the mailing list ? Eventually I could send you my version privately. A new release WIEN2k_12.1 is in preparation anyway, but it may still take some time. Am 03.05.2012 04:35, schrieb Laurence Marks: Apologies for the slow response. ?Try removing the first d LAPW, having two for the same level can lead to problems (i think). I may be wrong, check what is in case.output1_* (it is too late for me). --- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu http://www.numis.northwestern.edu 1-847-491-3996 Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi On May 2, 2012 11:29 AM, Florian Meirer fmeirer.wien2k.mlist at gmail.com mailto:fmeirer.wien2k.mlist at gmail.com wrote: ? ?Thanks for the fast reply! ? ?As suggested I tested using LAPW instead of APW+lo first (changed all ? ?switches to 0 in case.in1_st) but it didn't work. ? ?I have LO terms for d-levels and tested changing to LAPW only for them ? ?(see below) - no success either... ? ?here is the content of my .in1_st file (lines 4-7 are the same for all ? ?10 inequivalent atoms - all Ge, one Sn): ? ?-- ? ?WFFIL ?EF= 0.5 ? ? ? (WFFIL, WFPRI, ENFIL, SUPWF) ? ? ?7.00 ? ? ? 10 ? ?4 (R-MT*K-MAX; MAX L IN WF, V-NMT ? ? ?0.30 ? ?4 ?0 ? ? ?(GLOBAL E-PARAMETER WITH n OTHER CHOICES, global ? ?APW/LAPW) ? ? ?2 ? -1.83 ? ? ?0.002 CONT 0 ? ? ?2 ? ?0.30 ? ? ?0.000 CONT 0 ? ? ?0 ? ?0.30 ? ? ?0.000 CONT 1 ? ? ?1 ? ?0.30 ? ? ?0.000 CONT 1 ? ?... ? ?... ? ?K-VECTORS FROM UNIT:4 ? -9.0 ? ? ? 2.5 ?898 ? emin/emax/nband #red ? ?-- ? ?What could be wrong with the struct file? Is there something I do ? ?fundamentally wrong ... should I try to reduce symmetry? ? ?Many thanks! ? ?2012/5/2 Laurence Marks L-marks at northwestern.edu ? ?mailto:L-marks at northwestern.edu: ? ? It could be that there is some error in your file. One test might be ? ? to use LAPW instead of APW+lo and see if that runs (a single ? ? iteration). If it does then your structure is OK. Please check the UG ? ? if you are unclear what to change in case.in1 ? ? ? ? Some comments that might be helpful: ? ? I believe that changing the number of k-points only helps by chance, ? ? i.e. avoiding a specific k-point that leads to problems, so that is ? ? not the issue. ? ? Similarly changing the number of parallel jobs should not matter, ? ? I would not reduce it to P, but you might be able to reduce the ? ? symmetry to something slightly lower than what you started with (e.g. ? ? P4mm + inversion or simple cubic). I use Cryscon for this, but I am ? ? sure that there are other ways. ? ? ? ? Last, maybe not least, the issue comes about for high-symmetry ? ? structures because the APW terms within the muffin-tins need to be ? ? orthogonal. With many identical atoms for higher L levels this can ? ? become complicated as many of the PW's are not unique (e.g. (001) and ? ? (002)). Hence I would check whether you have an LO terms for d-levels ? ? in your calculation by looking at case.in1. I don't think you should ? ? have, but maybe. You can also look in case.output1_* to see where ? ?they ? ? stop. It may be that you can change to LAPW for the d in case.in1 (I ? ? expect by default it is APW+lo). ? ? ? ? On Wed, May 2, 2012 at 9:59 AM, Florian Meirer ? ? fmeirer.wien2k.mlist at gmail.com ? ?mailto:fmeirer.wien2k.mlist at gmail.com wrote: ? ? Dear Wien2k users, ? ? ? ? I am having a problem with a supercell calculation: ? ? ? ? - I am running wien version 11.1 (Release 14/6/2011) on a Intel XEON ? ? X5650 @ 2.67Ghz (2 Processors), 24Gb RAM with operating system ? ?Ubuntu ? ? 64bit, fortran compiler ifort 11.1.073 and math libraries R_LIB ? ? (LAPACK+BLAS): -lmkl_lapack -lmkl_intel_lp64 -lmkl_intel_thread ? ? -lmkl_core -openmp -lpthread -lguide ? ? ? ? - The purpose of my calculations is to perform a structural ? ?relaxation ? ? (PORT) around an impurity (Sn dopant in Germanium) ? ? - I successfully performed the same calculation for an As ? ?impurity in ? ? Silicon and achieved good agreement with literature and experimental ? ? data (XANES). ? ? ? ? - I
[Wien] warning in the first iteration
Dear Sir/Madam, I'm using WIEN2k_11. My material has 3d electrons. So I used APW+lo for valence electrons. I got a warning message at the first iteration. As I understand it, I need to change energy parameters in the case.in1 so as to avoid ghost band. However, the error message only appears in the first iteration. In the subsequent iterations, it never appears again. Is it fine to assume that the ghost band went away? :WARN : QTL-B value eq. 2.98 in Band of energy 0.67735 ATOM=2 L= 2 :WARN : You should change the E-parameter for this atom and L-value in case.in1 (or try the -in1new switch) :ENE : *WARNING** TOTAL ENERGY IN Ry = -109280.95603169
