[Wien] Slab convergence -- continuation
Lukasz Plucinski
pluto at physics.ucdavis.edu
Wed Sep 22 14:12:07 CEST 2010
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
>>
>
>
More information about the Wien
mailing list