[Wien] 'LOPW' - Plane waves exhausted

Florian Meirer fmeirer.wien2k.mlist at gmail.com
Thu May 3 16:40:20 CEST 2012


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


More information about the Wien mailing list