[Wien] Slab convergence
Lukasz Plucinski
pluto at physics.ucdavis.edu
Mon Sep 13 18:53:49 CEST 2010
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
>>
>
>
More information about the Wien
mailing list