[Wien] Slab convergence
Laurence Marks
L-marks at northwestern.edu
Tue Sep 14 16:00:12 CEST 2010
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
>
--
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.
More information about the Wien
mailing list