[Wien] Slab convergence

Laurence Marks L-marks at northwestern.edu
Mon Sep 13 18:58:19 CEST 2010 

-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
>



-- 
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