[Wien] 'LOPW' - Plane waves exhausted

Laurence Marks L-marks at northwestern.edu
Thu May 3 15:37:19 CEST 2012


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


More information about the Wien mailing list