[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] '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] 'LOPW' - Plane waves exhausted
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 0.1 for Sn (as recommended: http://www.wien2k.at/reg_user/faq/r0.html); Default settings for the rest: RKmax=7, k=200, PBE-GGA, -6.0Ry, not spin-polarized SCF: run_lapw -p -it -ec 0.0001 -fc 1 -cc 0.001 -NI I am running 10 parallel jobs and lapw1_10.error returns: Error in LAPW1 ?'LOPW' - Plane waves exhausted - I have already consulted the mailing list and tried to following: 1) replaced SRC_lapw1/lopw.f with the one provided here: http://zeus.theochem.tuwien.ac.at/pipermail/wien/2011-August/015142.html and recompiled in folder. 2) increased RKmax (also suggested in the mailing list somewhere) 3) changed number of parallel jobs 4) broke symmetry of struct file completely; i.e. each atom labeled individually, P-type struct - LOPW does not crash but a) the calculation takes forever and b) the forces did not converge 5) finally, as it seems related to the k-points, I reduced the number of k-points to 4 (k=100) and LOPW does not crash ... however, I am not happy using only 4 k-points... this seems too low? 6) I read that: This is usually due to an error in your struct file. (Specifying the same atom twice,) (http://www.wien2k.at/reg_user/mailing_list/wien-digest.archive/summary_2001), but I cannot find my mistake... - The thing that puzzles me is the fact that the same calculation worked perfectly fine for an As impurity in Si (same structure, same parameters ...) I am probably missing something but cannot find my mistake. Many thanks for any suggestions! Best regards, Florian Meirer Florian Meirer (PhD) MiNALab - Center for Materials and Microsystems - irst FBK - Fondazione Bruno Kessler
[Wien] 'LOPW' - Plane waves exhausted
here is the attachment (struct file) - sorry 2012/5/2 Florian Meirer fmeirer.wien2k.mlist at gmail.com: 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 0.1 for Sn (as recommended: http://www.wien2k.at/reg_user/faq/r0.html); Default settings for the rest: RKmax=7, k=200, PBE-GGA, -6.0Ry, not spin-polarized SCF: run_lapw -p -it -ec 0.0001 -fc 1 -cc 0.001 -NI I am running 10 parallel jobs and lapw1_10.error returns: Error in LAPW1 ?'LOPW' - Plane waves exhausted - I have already consulted the mailing list and tried to following: 1) replaced SRC_lapw1/lopw.f with the one provided here: http://zeus.theochem.tuwien.ac.at/pipermail/wien/2011-August/015142.html and recompiled in folder. 2) increased RKmax (also suggested in the mailing list somewhere) 3) changed number of parallel jobs 4) broke symmetry of struct file completely; i.e. each atom labeled individually, P-type struct - LOPW does not crash but a) the calculation takes forever and b) the forces did not converge 5) finally, as it seems related to the k-points, I reduced the number of k-points to 4 (k=100) and LOPW does not crash ... however, I am not happy using only 4 k-points... this seems too low? 6) I read that: This is usually due to an error in your struct file. (Specifying the same atom twice,) (http://www.wien2k.at/reg_user/mailing_list/wien-digest.archive/summary_2001), but I cannot find my mistake... - The thing that puzzles me is the fact that the same calculation worked perfectly fine for an As impurity in Si (same structure, same parameters ...) I am probably missing something but cannot find my mistake. Many thanks for any suggestions! Best regards, Florian Meirer Florian Meirer (PhD) MiNALab - Center for Materials and Microsystems - irst FBK - Fondazione Bruno Kessler -- next part -- A non-text attachment was scrubbed... Name: SnGe_supercell_test.struct Type: application/octet-stream Size: 7707 bytes Desc: not available URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120502/9b66a5d7/attachment.dll
[Wien] 'LOPW' - Plane waves exhausted
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 0.1 for Sn (as recommended: http://www.wien2k.at/reg_user/faq/r0.html); Default settings for the rest: RKmax=7, k=200, PBE-GGA, -6.0Ry, not spin-polarized SCF: run_lapw -p -it -ec 0.0001 -fc 1 -cc 0.001 -NI I am running 10 parallel jobs and lapw1_10.error returns: Error in LAPW1 ?'LOPW' - Plane waves exhausted - I have already consulted the mailing list and tried to following: 1) replaced SRC_lapw1/lopw.f with the one provided here: http://zeus.theochem.tuwien.ac.at/pipermail/wien/2011-August/015142.html and recompiled in folder. 2) increased RKmax (also suggested in the mailing list somewhere) 3) changed number of parallel jobs 4) broke symmetry of struct file completely; i.e. each atom labeled individually, P-type struct - LOPW does not crash but a) the calculation takes forever and b) the forces did not converge 5) finally, as it seems related to the k-points, I reduced the number of k-points to 4 (k=100) and LOPW does not crash ... however, I am not happy using only 4 k-points... this seems too low? 6) I read that: This is usually due to an error in your struct file. (Specifying the same atom twice,) (http://www.wien2k.at/reg_user/mailing_list/wien-digest.archive/summary_2001), but I cannot find my mistake... - The thing that puzzles me is the fact that the same calculation worked perfectly fine for an As impurity in Si (same structure, same parameters ...) I am probably missing something but cannot find my mistake. Many thanks for any suggestions! Best regards, Florian Meirer Florian Meirer (PhD) MiNALab - Center for Materials and Microsystems - irst FBK - Fondazione Bruno Kessler ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- 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
[Wien] 'LOPW' - Plane waves exhausted
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: 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 0.1 for Sn (as recommended: http://www.wien2k.at/reg_user/faq/r0.html); Default settings for the rest: RKmax=7, k=200, PBE-GGA, -6.0Ry, not spin-polarized SCF: run_lapw -p -it -ec 0.0001 -fc 1 -cc 0.001 -NI I am running 10 parallel jobs and lapw1_10.error returns: Error in LAPW1 ?'LOPW' - Plane waves exhausted - I have already consulted the mailing list and tried to following: 1) replaced SRC_lapw1/lopw.f with the one provided here: http://zeus.theochem.tuwien.ac.at/pipermail/wien/2011-August/015142.html and recompiled in folder. 2) increased RKmax (also suggested in the mailing list somewhere) 3) changed number of parallel jobs 4) broke symmetry of struct file completely; i.e. each atom labeled individually, P-type struct - LOPW does not crash but a) the calculation takes forever and b) the forces did not converge 5) finally, as it seems related to the k-points, I reduced the number of k-points to 4 (k=100) and LOPW does not crash ... however, I am not happy using only 4 k-points... this seems too low? 6) I read that: This is usually due to an error in your struct file. (Specifying the same atom twice,) (http://www.wien2k.at/reg_user/mailing_list/wien-digest.archive/summary_2001), but I cannot find my mistake... - The thing that puzzles me is the fact
[Wien] 'LOPW' - Plane waves exhausted
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 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: 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 Ge1NPT= 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 0.1 for Sn (as recommended: http://www.wien2k.at/reg_user/faq/r0.html); Default settings for the rest: RKmax=7, k=200, PBE-GGA, -6.0Ry, not spin-polarized SCF: run_lapw -p -it -ec 0.0001 -fc 1 -cc 0.001 -NI I am running 10 parallel jobs and lapw1_10.error returns: Error in LAPW1 'LOPW' - Plane waves exhausted - I have already consulted the mailing list and tried to following: 1) replaced SRC_lapw1/lopw.f with the one provided here: http://zeus.theochem.tuwien.ac.at/pipermail/wien/2011-August/015142.html and recompiled in folder. 2) increased RKmax (also suggested in the mailing list somewhere) 3) changed number of parallel
[Wien] 'LOPW' - Plane waves exhausted
I am calculating alpha-Mn (I -43m, cI58) using the latest Version of Wien2k and face a problem that appeared sometime ago to someone else for gamma-brass, too. The 'LOPW' error appears for more than 2 k-points in the irrep part of the BZ. It is interesting to note that it was running with some older Version of Wien2k with much more k-points and all other input unchanged (I just did not finish that calculation and don't remember which Version of Wien it was). Peter, in about July you were sending a revised lopw.f with relaxed conditions for orthogonality, unfortunatel I don't have it anymore, could you (or anyone else) send it to me that I can test wether it also solves my problem. (I have an struct file attached that was created from a P1 cif File, alternative positions for the atoms result in the same error) Ciao Gerhard Dr. Gerhard H. Fecher Institut of Inorganic and Analytical Chemistry Johannes Gutenberg - University 55099 Mainz -- next part -- A non-text attachment was scrubbed... Name: a-Mn_test.struct Type: application/octet-stream Size: 4373 bytes Desc: a-Mn_test.struct URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20111002/cddd5a98/attachment.dll -- next part -- A non-text attachment was scrubbed... Name: a-Mn_aexp.struct Type: application/octet-stream Size: 4301 bytes Desc: a-Mn_aexp.struct URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20111002/cddd5a98/attachment-0001.dll
[Wien] 'LOPW' - Plane waves exhausted
http://zeus.theochem.tuwien.ac.at/pipermail/wien/2011-August/015142.html 2011/10/2 Gerhard Fecher fecher at uni-mainz.de: I am calculating alpha-Mn (I -43m, cI58) using the latest Version of Wien2k and face a problem that appeared sometime ago to someone else for gamma-brass, too. The 'LOPW' error appears for more than 2 k-points in the irrep part of the BZ. It is interesting to note that it was running with some older Version of Wien2k with much more k-points and all other input unchanged (I just did not finish that calculation and don't remember which Version of Wien it was). Peter, in about July you were sending a revised lopw.f with relaxed conditions for orthogonality, unfortunatel I don't have it anymore, could you ?(or anyone else) send it to me that I can test wether it also solves my problem. (I have an struct file attached that was created from a P1 cif File, alternative positions for the atoms result in the same error) Ciao Gerhard Dr. Gerhard H. Fecher Institut of Inorganic and Analytical Chemistry Johannes Gutenberg - University 55099 Mainz ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2220 N Campus Drive Northwestern University Evanston, IL 60208, USA Tel: (847) 491-3996 Fax: (847) 491-7820 email: L-marks at northwestern dot edu Web: www.numis.northwestern.edu Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi
[Wien] 'LOPW' - Plane waves exhausted
Thank you, it works Ciao Gerhard Dr. Gerhard H. Fecher Institut of Inorganic and Analytical Chemistry Johannes Gutenberg - University 55099 Mainz Von: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at zeus.theochem.tuwien.ac.at]quot; im Auftrag von quot;Laurence Marks [L-marks at northwestern.edu] Gesendet: Sonntag, 2. Oktober 2011 16:20 Bis: A Mailing list for WIEN2k users Betreff: Re: [Wien] 'LOPW' - Plane waves exhausted http://zeus.theochem.tuwien.ac.at/pipermail/wien/2011-August/015142.html 2011/10/2 Gerhard Fecher fecher at uni-mainz.de: I am calculating alpha-Mn (I -43m, cI58) using the latest Version of Wien2k and face a problem that appeared sometime ago to someone else for gamma-brass, too. The 'LOPW' error appears for more than 2 k-points in the irrep part of the BZ. It is interesting to note that it was running with some older Version of Wien2k with much more k-points and all other input unchanged (I just did not finish that calculation and don't remember which Version of Wien it was). Peter, in about July you were sending a revised lopw.f with relaxed conditions for orthogonality, unfortunatel I don't have it anymore, could you (or anyone else) send it to me that I can test wether it also solves my problem. (I have an struct file attached that was created from a P1 cif File, alternative positions for the atoms result in the same error) Ciao Gerhard Dr. Gerhard H. Fecher Institut of Inorganic and Analytical Chemistry Johannes Gutenberg - University 55099 Mainz ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2220 N Campus Drive Northwestern University Evanston, IL 60208, USA Tel: (847) 491-3996 Fax: (847) 491-7820 email: L-marks at northwestern dot edu Web: www.numis.northwestern.edu Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] 'LOPW' - Plane waves exhausted
Please check your custom klist. When the invalid or wrongly-formatted case.klist exists, the error can be occurred. 2011/2/22 Laurence Marks L-marks at northwestern.edu It is very hard to know exactly what you have done wrong, or it could be something special to your problem. Do you have d and f states in the valence region? You might need to increase RKMAX. 2011/2/21 Volodymyr Svitlyk svitlyk at esrf.fr: Hi all, I have tried to use my custom klist. I have copied my klist into the directory, set TEMP as a Fermi-method with eval = 0.002, then I just skipped the kgen command during the initialize calc. At the lapw1 I got the error 'LOPW' - Plane waves exhausted. I guess something is wrong in the way I feed the klist? Thank you. ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2220 N Campus Drive Northwestern University Evanston, IL 60208, USA Tel: (847) 491-3996 Fax: (847) 491-7820 email: L-marks at northwestern dot edu Web: www.numis.northwestern.edu Chair, Commission on Electron Crystallography of IUCR www.numis.northwestern.edu/ Electron crystallography is the branch of science that uses electron scattering and imaging to study the structure of matter. ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Min Wook OH, Ph. D., Korea Electrotechnology Research Institute (KERI) Tel: 82-55-280-1638 Fax: 82-55-280-1590 E-mail: minwookoh at keri.re.kr -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110223/9553dd02/attachment.htm
[Wien] 'LOPW' - Plane waves exhausted
It is very hard to know exactly what you have done wrong, or it could be something special to your problem. Do you have d and f states in the valence region? You might need to increase RKMAX. 2011/2/21 Volodymyr Svitlyk svitlyk at esrf.fr: Hi all, I have tried to use my custom klist. I have copied my klist into the directory, set TEMP as a Fermi-method with eval = 0.002, then I just skipped the kgen command during the initialize calc.? At the lapw1 I got the error 'LOPW' - Plane waves exhausted. I guess something is wrong in the way I feed the klist? Thank you. ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2220 N Campus Drive Northwestern University Evanston, IL 60208, USA Tel: (847) 491-3996 Fax: (847) 491-7820 email: L-marks at northwestern dot edu Web: www.numis.northwestern.edu Chair, Commission on Electron Crystallography of IUCR www.numis.northwestern.edu/ Electron crystallography is the branch of science that uses electron scattering and imaging to study the structure of matter.
[Wien] 'LOPW' - Plane waves exhausted
Thank you, Laurence, actually it started to cycle after I have made the number of spaces in my file the same as in the native k-list Le 22/02/2011 15:01, Laurence Marks a ?crit : It is very hard to know exactly what you have done wrong, or it could be something special to your problem. Do you have d and f states in the valence region? You might need to increase RKMAX. 2011/2/21 Volodymyr Svitlyksvitlyk at esrf.fr: Hi all, I have tried to use my custom klist. I have copied my klist into the directory, set TEMP as a Fermi-method with eval = 0.002, then I just skipped the kgen command during the initialize calc. At the lapw1 I got the error 'LOPW' - Plane waves exhausted. I guess something is wrong in the way I feed the klist? Thank you. ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] 'LOPW' - Plane waves exhausted
Hi all, I have tried to use my custom klist. I have copied my klist into the directory, set TEMP as a Fermi-method with eval = 0.002, then I just skipped the kgen command during the initialize calc. http://coral33.esrf.fr:7891/exec/initlapw.pl?SID=195473At the lapw1 I got the error 'LOPW' - Plane waves exhausted. I guess something is wrong in the way I feed the klist? Thank you. -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110221/91c58f9c/attachment.htm
