[Wien] Slab convergence -- continuation

Peter Blaha pblaha at theochem.tuwien.ac.at
Wed Sep 22 16:57:36 CEST 2010 

Fe1Au20 ? do you have inversion symmetry ? (otherwise put Fe on both ends of the slab).

What means:  having problems with convergence ? What means "crashes" after 20 it ?   Why ?

Keep the default inputs except:
     fix the r0 (maybe the structeditor does not set this correctly, but maybe you started from wrong ones ?)
     use TEMP (or TEMPS) with 0.004; or if convergence is still difficult, increase it to 0.010
     use a good k-mesh (Never classify a kmesh according to the points in the IBZ, but either in the full zone
        or in divisions (like 10x10x1). 10x10x1 is a minimum mesh (corresponds to only 1000k in bulk Cu),
        but most likely more (20x20x1) is better and helps convergence.

If the scf stops after 40 it, check    grep :DIS case.scf
     if DIS reduces slowly, just continue with the next 40 cycles. Some cases may really need a few 100 cycles.
     if DIS is not reducing further, consider a larger DE in TEMP; or restart the MSEC1 cycle every 20 iterations
       (rm *.broy*)

RMT .gt. 2.5 might lead to substantial "linearization errors" and is thus not supported by the automatic setup.
You can of course increase them on your own risk. (In fact, somtimes even smaller RMTs are necessary for highest precision).


Am 22.09.2010 14:12, schrieb Lukasz Plucinski:
> Dear WIEN2k experts,
>
> I keep having problems with Fe1Au20 (one Fe layer on top of 20 Au layers, (001) surface) slab SCF convergence.
>
> I recently compiled WIEN2k using ifort 10.1.011 and mkl 10.0.1.014 without errors.
>
> SCF converged nicely for Au20 slab and for Fe1Au5 slab, where I reproduced the work of Li and Freeman JMMM 75, 201 (1988). My Fe1Au20 slab is of 60.5A length to have sufficient
> vacuum separation.
>
> I typically use all options default. I tried 10 and 21 effective points case.klist (automatically generated). I tried -6 and -8 Ry cutoff. The SCF cycle crashes after 20-30
> iterations.
>
> I did volume optimization of bulk Au and now I use 2.906 A for the lattice constant. I also tried to relax the Fe1Au5 slab and no problem with excessive forces was found.
> Therefore Fe1Au20 slab is unrelaxed, and Fe-Au layer distance is taken from Li and Freeman JMMM 75, 201 (1988).
>
> So far I was using Rmt*Kmax = 7.0. Increase from 7.0 to 8.0 costs a lot of CPU time, the lapw1 computation time seems to triple. Please let me know what other parameters I should
> try to change to increase the convergence efficiency.
>
> Another question: why is my automatic RMT program not able to set RMT above 2.5 ? Is 2.5 some magic number or maybe I have some bug ?
>
> Furthermore I keep having problems with R0. It seems it is not set properly by StructGen, and I must correct it manually after lstart gives the warning. So far I set it 0.000001
> for Au and 0.00005 for Fe, I am not sure if this is ok.
>
> Regards,
> Lukasz
>
>
>
> On 9/14/2010 4:00 PM, Laurence Marks wrote:
>> On Tue, Sep 14, 2010 at 5:49 AM, Lukasz Plucinski
>> <pluto at physics.ucdavis.edu> wrote:
>>> Dear Laurence,
>>>
>>> I was able to compile entire program using Portland compiler with generic
>>> options. Now iterations work, however, neither Au20 nor Fe1Au20 slabs didn't
>>> converge yet (sp far I got down to 0.0016 in energy for Au20 slab). For
>>> simple cases there is no problem with convergence, I tested for bulk Au (not
>>> complex) and bulk GaAs (complex).
>>>
>>> So far I am happy with this, and I would like to thank you for your
>>> supporting and motivating comments last couple of days. At the moment I am
>>> using old 2.8 GHz P4 CPU (released in 2002), maybe I will order a new
>>> computer, and then compile things properly. Is there any preference for the
>>> CPU type nowadays ? For example I can see various Intel i7 and i5 priced
>>> around 200 Euro. Are some Linux systems more preferable than others ?
>> Assuming that you are buying a box, dual-quadcore's with Intel
>> compilers and mkl are good. Not sure about laptops.
>>
>>> lapw0 and lapw1 produced by Portland compiler are very slow, and instead of
>>> them I use precompiled executables (especially lapw0 was very very slow :)
>>> ).
>>>
>>> At this point I can concentrate again on optimizing the convergence. You
>>> have mentioned 2 things:
>>>
>>> - using TEMPS instead of TETRA with 0.0018 temperature factor,
>>> - using iterative mode,
>>>
>>> Could you comment if and how they may help the convergence ?
>> TETRA is a bit noisy, particularly for metals. Iterative mode is much
>> faster and almost as accurate. I prefer -noHinv, others may prefer the
>> alternative iterative mode.
>>
>>> i
>>> Do you think changing cutoff from -6 to -8 Ry could help the convergence
>>> when Fe atom is involved ?
>> It will probably have no effect. Do a grep -e :NEC to see if you are
>> losing density from high-energy core states and need to move them into
>> the valence regime. I would not increase RMT's, you could run into
>> other problems.
>>
>> Good luck.
>>
>>> Regards,
>>> Lukasz
>>>
>>>
>>>
>>>
>>> On 9/13/2010 6:58 PM, Laurence Marks wrote:
>>>> -noHinv (not -nohns, they are VERY different)!
>>>>
>>>> A SIGSEV is a moderately serious problem, and might be in the
>>>> executables you are using -- I don't know and I believe Peter Blaha is
>>>> at a conference. I would strongly suggest getting help with the
>>>> compilation, it is not that hard and I think you have some people at
>>>> Davis who know what they are doing.
>>>>
>>>> On Mon, Sep 13, 2010 at 11:53 AM, Lukasz Plucinski
>>>> <pluto at physics.ucdavis.edu> wrote:
>>>>> Dear Laurence,
>>>>>
>>>>> Thank you for your support.
>>>>>
>>>>> Before starting another test I always delete all files in the "case"
>>>>> directory, leaving only the case.struct file there.
>>>>>
>>>>> I would really like to avoid compiling the program and I try to use
>>>>> executables which are also available. I am not really interested in
>>>>> optimized performance of the system, and my 20ML slab should calculate
>>>>> within several hours on my machine if all works fine. I am using Fedora
>>>>> Linux, and Wien2k_08 compiled executables were working fine on this
>>>>> system.
>>>>>
>>>>> But maybe compiling will be mandatory at the end, which for me probably
>>>>> means that I will have to get some support from the IT group in our
>>>>> institute. But before I start organizing this I would like to further
>>>>> explore the option with compiled executables :)
>>>>>
>>>>> At the moment the problem seems to be lapw2c (bulk Au calculation, which
>>>>> works, does not use the -c complex option). The history of my last try
>>>>> with
>>>>> -it and -nohns (as you suggested) options is below. Here is the
>>>>> case.dayfile:
>>>>>
>>>>> Calculating Au20_ver2 in /local/WORK/Au20_ver2
>>>>> on iff187 with PID 3798
>>>>> using WIEN2k_10.1 (Release 7/6/2010) in /local/WIEN
>>>>>
>>>>> start (Mon Sep 13 18:20:57 CEST 2010) with lapw0 (40/99 to go)
>>>>>
>>>>> cycle 1 (Mon Sep 13 18:20:58 CEST 2010) (40/99 to go)
>>>>>
>>>>>> lapw0 (18:20:58) 82.578u 1.729s 1:25.89 98.1% 0+0k 0+16856io
>>>>>> 0pf+0w
>>>>> moving Au20_ver2.vectorup to Au20_ver2.vectorup.old
>>>>> moving Au20_ver2.vectordn to Au20_ver2.vectordn.old
>>>>>> lapw1 -it -c -up -nohns (18:22:24) 115.475u 4.607s 2:05.42 95.7%
>>>>>> 0+0k 0+156080io 0pf+0w
>>>>>> lapw1 -it -c -dn -nohns (18:24:29) 96.951u 3.882s 1:42.15 98.7%
>>>>>> 0+0k
>>>>>> 0+153000io 0pf+0w
>>>>>> lapw2 -c -up (18:26:11) 0.274u 0.108s 0:00.38 97.3% 0+0k
>>>>>> 0+1848io 0pf+0w
>>>>> error: command /local/WIEN/lapw2c uplapw2.def failed
>>>>>
>>>>>> stop error
>>>>>
>>>>> and the STDOUT:
>>>>>
>>>>> File: STDOUT Line 1 Col 0 144 bytes
>>>>> 100%
>>>>> LAPW0 END
>>>>> LAPW1 END
>>>>> LAPW1 END
>>>>> forrtl: severe (174): SIGSEGV, segmentation fault occurred
>>>>>
>>>>> Stack trace terminated abnormally.
>>>>>
>>>>>> stop error
>>>>> Regards,
>>>>> Lukasz
>>>>>
>>>>>
>>>>>
>>>>> On 9/13/2010 5:48 PM, Laurence Marks wrote:
>>>>>> 1. Do "rm *.rec*" -- old files with k-vectors in them might be a
>>>>>> problem.
>>>>>> 2. Are you using openmpi? This can be an issue.
>>>>>> 3. Did you restart in a fresh directory from just your struct file and
>>>>>> redo init_lapw? Safest.
>>>>>>
>>>>>> On Mon, Sep 13, 2010 at 10:41 AM, Lukasz Plucinski
>>>>>> <pluto at physics.ucdavis.edu> wrote:
>>>>>>> Dear Laurence,
>>>>>>>
>>>>>>> Thank you for the rapid response. Indeed I deleted all files in Wien
>>>>>>> root
>>>>>>> directory, and started from there.
>>>>>>>
>>>>>>> Now the calculation for bulk Au runs, and the R0 warning is gone, when
>>>>>>> the
>>>>>>> number is 100 times smaller (it was 0.0001, and now its 0.000001 for
>>>>>>> Au).
>>>>>>> Also struct editor keeps setting RMT as 2.5, which is too small for
>>>>>>> bulk
>>>>>>> Au.
>>>>>>>
>>>>>>> The calculation for 20ML Au slab (which has worked before) gets stuck
>>>>>>> at
>>>>>>> first LAPW2 in SCF cycle -- LAPW1 ends after 1 or 2 minutes, and LAPW2
>>>>>>> keeps
>>>>>>> running 20 or more minutes, then I kill it (because I assume it will
>>>>>>> never
>>>>>>> end).
>>>>>>>
>>>>>>> I suspect things are still not properly installed, however, this does
>>>>>>> not
>>>>>>> explain why bulk Au calculation works fine...
>>>>>>>
>>>>>>> Maybe you could suggest some simple tests I could do ?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Lukasz
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 9/13/2010 3:05 PM, Laurence Marks wrote:
>>>>>>>> Pay attention to the warning about R0 and change this in the struct
>>>>>>>> file. (Previously it was possible to run calculations with too large a
>>>>>>>> value and not know.) Apart from this it is hard to know and rerunning
>>>>>>>> siteconfig is safer.
>>>>>>>>
>>>>>>>> On Mon, Sep 13, 2010 at 7:36 AM, Lukasz Plucinski
>>>>>>>> <pluto at physics.ucdavis.edu> wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I copied newest version of Wien2k (previously I was using version
>>>>>>>>> 08).
>>>>>>>>> I
>>>>>>>>> would really prefer to avoid compiling a new version, thus I just
>>>>>>>>> copied
>>>>>>>>> (overwritten) the binaries (executables) into the root Wien
>>>>>>>>> directory.
>>>>>>>>> However, not everything seems to work now...
>>>>>>>>>
>>>>>>>>> First I tried to calculate bulk Au as a test. Automatic RMT procedure
>>>>>>>>> has
>>>>>>>>> determined the RMT as 2.5 although it should be around 2.72... I
>>>>>>>>> don't
>>>>>>>>> understand why but this does not really change much.
>>>>>>>>>
>>>>>>>>> First warning appears when running lstart:
>>>>>>>>>
>>>>>>>>> WARNING: R0 for atom 1 Z= 79.00 too big
>>>>>>>>>
>>>>>>>>> There is no problems with leaking charge:
>>>>>>>>>
>>>>>>>>> TOTAL CORE-CHARGE: 54.000001
>>>>>>>>> TOTAL CORE-CHARGE INSIDE SPHERE: 53.999826
>>>>>>>>> TOTAL CORE-CHARGE OUTSIDE SPHERE: 0.000175
>>>>>>>>>
>>>>>>>>> Then the rest of initialization goes fine and there is no problem
>>>>>>>>> with
>>>>>>>>> convergence. I can also calculate the band structure, however, not
>>>>>>>>> the
>>>>>>>>> option of partial charges. Trying to calculate partial charges gives
>>>>>>>>> the
>>>>>>>>> following error:
>>>>>>>>>
>>>>>>>>> Commandline: x lapw2 -band -qtl -up
>>>>>>>>> Program input is: ""
>>>>>>>>> forrtl: severe (256): unformatted I/O to unit open for formatted
>>>>>>>>> transfers,
>>>>>>>>> uni
>>>>>>>>> t 15, file /local/WORK/Au-bulk-no-SO/Au-bulk-no-SO.tmpup
>>>>>>>>> Image PC Routine Line Source
>>>>>>>>> lapw2 082CDBED Unknown Unknown Unknown
>>>>>>>>> lapw2 082CD165 Unknown Unknown Unknown
>>>>>>>>> lapw2 08288C98 Unknown Unknown Unknown
>>>>>>>>> lapw2 08252AFA Unknown Unknown Unknown
>>>>>>>>> lapw2 0825241B Unknown Unknown Unknown
>>>>>>>>> lapw2 08279804 Unknown Unknown Unknown
>>>>>>>>> lapw2 080899EE outp_ 207 outp.f
>>>>>>>>> lapw2 0807B3AF l2main_ 1710
>>>>>>>>> l2main_tmp_.F
>>>>>>>>> lapw2 08083AFB MAIN__ 545
>>>>>>>>> lapw2_tmp_.F
>>>>>>>>> lapw2 080482A1 Unknown Unknown Unknown
>>>>>>>>> lapw2 082D8E30 Unknown Unknown Unknown
>>>>>>>>> lapw2 08048161 Unknown Unknown Unknown
>>>>>>>>> 0.324u 0.097s 0:00.42 97.6% 0+0k 0+2224io 0pf+0w
>>>>>>>>>
>>>>>>>>> Doing all this on my Fe1Au20 slab gives the same "WARNING: R0 for
>>>>>>>>> atom
>>>>>>>>> 1
>>>>>>>>> Z= 79.00 too big" warning, and then during SCF run the programs gets
>>>>>>>>> stuck
>>>>>>>>> on a first LAPW2, it does not give the error, but the LAPW2 continues
>>>>>>>>> forever... Thus probably there is something wrong with my LAPW2, or
>>>>>>>>> perhaps
>>>>>>>>> my Wien2k_10 is not properly installed.
>>>>>>>>>
>>>>>>>>> I will keep working to solve this, but I am sure your suggestions
>>>>>>>>> will
>>>>>>>>> help.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Lukasz
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 9/12/2010 3:37 PM, Laurence Marks wrote:
>>>>>>>>>> N.B., of course when you compare to the number of k-points for bulk
>>>>>>>>>> Au
>>>>>>>>>> remember to use the primitive cell volume.
>>>>>>>>>>
>>>>>>>>>> On Sun, Sep 12, 2010 at 8:21 AM, Laurence Marks
>>>>>>>>>> <L-marks at northwestern.edu> wrote:
>>>>>>>>>>> Some comments:
>>>>>>>>>>>
>>>>>>>>>>> 1. 100 k-points for a surface is a lot. What I suggest you do is
>>>>>>>>>>> determine how many k-points you need per reciprocal nm^3 (i.e. the
>>>>>>>>>>> multiple of the 3 numbers after "div:" in line 1 of case.klist and
>>>>>>>>>>> the
>>>>>>>>>>> cell volume) for a bulk calculation then use the same density for a
>>>>>>>>>>> surface.
>>>>>>>>>>>
>>>>>>>>>>> 2. Are you using TETRA? I recommend TEMPS for surfaces with a
>>>>>>>>>>> temperature factor of 0.0018 (room temperature).
>>>>>>>>>>>
>>>>>>>>>>> 3. DO NOT REDUCE THE MIXING FACTOR (better called MIXING GREED)
>>>>>>>>>>> unless
>>>>>>>>>>> you understand what you are doing. For old PRATT and BROYD methods
>>>>>>>>>>> this was correct, for MSEC1 it is fundamentally wrong. Too large a
>>>>>>>>>>> mixing greed (say 0.5) is being too greedy, but the algorithm in
>>>>>>>>>>> fact
>>>>>>>>>>> prevents this from happening. To small a greed and the algorithm
>>>>>>>>>>> will
>>>>>>>>>>> starve to death.
>>>>>>>>>>>
>>>>>>>>>>> 4. In 98% of cases where the calculation does not converge this is
>>>>>>>>>>> because something is wrong in the physics of the model, i.e. bad
>>>>>>>>>>> functional or incorrect structure. Possibly the Fe atom is too far
>>>>>>>>>>> from the surface -- have you set FOR in case.in2 and looked at how
>>>>>>>>>>> big
>>>>>>>>>>> these are? With care, you can run a minimization with something
>>>>>>>>>>> like
>>>>>>>>>>> -fc 4 -ec 0.001 at first, then improve these later.
>>>>>>>>>>>
>>>>>>>>>>> 5. When you say it is not converging what do you really mean? The
>>>>>>>>>>> default -ec 0.0001 is very strict for a surface (with incorrect
>>>>>>>>>>> positions), realise that the energy convergence should scale as
>>>>>>>>>>> something like the number of atoms (or the square root of this).
>>>>>>>>>>>
>>>>>>>>>>> 6. Are you using 10.1 and iterative mode? 10.1 is noticeably better
>>>>>>>>>>> and I prefer to use -noHinv.
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Sep 12, 2010 at 7:26 AM, Lukasz Plucinski
>>>>>>>>>>> <pluto at physics.ucdavis.edu> wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> I am trying to calculate 1ML of Fe on top of Au(001).
>>>>>>>>>>>>
>>>>>>>>>>>> It was no problem to calculate 20ML slab of Au(001), it converged
>>>>>>>>>>>> after
>>>>>>>>>>>> 37
>>>>>>>>>>>> iterations with mixing 0.1, 100k-points and all other standard
>>>>>>>>>>>> settings,
>>>>>>>>>>>> also using "spin-polarized" calculation mode. I use 50 A of the
>>>>>>>>>>>> unit
>>>>>>>>>>>> cell
>>>>>>>>>>>> dimension, to have appropriate amount of vacuum.
>>>>>>>>>>>>
>>>>>>>>>>>> However, when I put 1 Fe atom on top of one side of the slab the
>>>>>>>>>>>> calculation
>>>>>>>>>>>> didn't converge after 100 iterations (I did couple of trials). I
>>>>>>>>>>>> also
>>>>>>>>>>>> tried
>>>>>>>>>>>> to increase the cutoff to -8 Ry, and the calculation is running
>>>>>>>>>>>> now,
>>>>>>>>>>>> however, no convergence indications after 35 iterations.
>>>>>>>>>>>>
>>>>>>>>>>>> My slab is not relaxed, and the distance between Fe and Au (3.295
>>>>>>>>>>>> au)
>>>>>>>>>>>> is
>>>>>>>>>>>> taken from the old publication of Freeman JMMM 75, 201 (1988).
>>>>>>>>>>>>
>>>>>>>>>>>> Automatic RMT distance procedure has put all RTM to 2.5, however,
>>>>>>>>>>>> this
>>>>>>>>>>>> way
>>>>>>>>>>>> there is a lot of space between Au atoms. I think its better to
>>>>>>>>>>>> use
>>>>>>>>>>>> 2.72
>>>>>>>>>>>> for
>>>>>>>>>>>> Au atoms and 2.34 for Fe atom -- is there any problem with this ?
>>>>>>>>>>>> Neither
>>>>>>>>>>>> setting helps the convergence...
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe I could decrease the amount of k-points to have faster
>>>>>>>>>>>> iterations
>>>>>>>>>>>> with
>>>>>>>>>>>> even lower mixing parameter ?
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Lukasz
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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

-- 

                                       P.Blaha
--------------------------------------------------------------------------
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-15671             FAX: +43-1-58801-15698
Email: blaha at theochem.tuwien.ac.at    WWW: http://info.tuwien.ac.at/theochem/
--------------------------------------------------------------------------

More information about the Wien mailing list