[Wien] 'LOPW' - Plane waves exhausted
Florian Meirer
fmeirer.wien2k.mlist at gmail.com
Thu May 3 17:00:38 CEST 2012
I checked again and the lapw1 and lapw1c were indeed the old ones (not
compiled using the new lopw.f)
I obviously did not copy them to wien2k root - very embarrassing! I
corrected it and everything seems to work fine now.
I am sorry for the inconvenience.
Many thanks for your help!
(ad RKMAX: thanks for the tip, I will do that - usually I test several
RKMAX values and choose the one poviding the best time/precision
ratio)
2012/5/3 Laurence Marks <L-marks at northwestern.edu>:
> Doing "make all" and "cp lapw1* ../" updates the executables; they are
> built in SRC_lapw1 but need to be in $WIENROOT. If you did not copy
> them then you are still using the old version which does fail for your
> problem.
>
> It may be that RKMAX=7.5 would be better as your RMT's are about 10%
> larger than 2.0. It will help with the LOPW issue, although of course
> it is slower and you are only using a single machine so would have to
> be patient.
>
> My suggestion is to check that you do have the most recent lapw1
> properly installed, make a fresh directory and redo the initialization
> then test. It should work fine...
>
> Good luck.
>
> On Thu, May 3, 2012 at 9:40 AM, Florian Meirer
> <fmeirer.wien2k.mlist at gmail.com> wrote:
>> I understand - many thanks for following up on my problem!
>> Here is the info:
>> a) NMATMAX=13000 (seemed sufficient so far, I have only 64 atoms;
>> anyway I have 24GB RAM available)
>> b) I did 'make -all' in SRC_lapw1/, but not 'cp lapw1* ../' (but this
>> was done after the error occurred using the 'old' lopw.f file)
>> c) I always used RKmax=7 (:RKM : MATRIX SIZE 5348LOs: 256 RKM= 7.00
>> WEIGHT= 8.00 PGR:)
>> d) no mpi - I just use k-point parallelization (.machines file)
>> Thanks!
>>
>> 2012/5/3 Laurence Marks <L-marks at northwestern.edu>:
>>> 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.50000 (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.50000 (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.000000 90.000000 90.000000
>>>>>>> >> ATOM 1: X=0.12500000 Y=0.12500000 Z=0.12500000
>>>>>>> >> MULT= 2 ISPLIT= 2
>>>>>>> >> 1: X=0.87500000 Y=0.37500000 Z=0.37500000
>>>>>>> >> Ge1 NPT= 781 R0=0.00005000 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.00005 for Ge and to 0.00001 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 mailing list
>>>>>>> > Wien at zeus.theochem.tuwien.ac.at
>>>>>>> > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>>>>>> _______________________________________________
>>>>>>> Wien mailing list
>>>>>>> Wien at zeus.theochem.tuwien.ac.at
>>>>>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Wien mailing list
>>>>>> Wien at zeus.theochem.tuwien.ac.at
>>>>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>>>>>
>>>>> _______________________________________________
>>>>> 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 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 mailing list
>>> Wien at zeus.theochem.tuwien.ac.at
>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>> _______________________________________________
>> 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 mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
More information about the Wien
mailing list