[Wien] Slab convergence -- continuation

Thu Sep 23 13:46:58 CEST 2010

Next time don't delete the case.scf file and run the attached file (sh
Check2) then include the results in an email.

On Thu, Sep 23, 2010 at 4:38 AM, Lukasz Plucinski
<pluto at physics.ucdavis.edu> wrote:
>  Dear Prof. Blaha,
>
> Thank you for the rapid and extensive answer ! I am following your
> suggestions, but on my slow system I will have to wait couple of days for
> some conclusions.
>
k> This is, however, no problem, if the slab can finally converge :)
>
> I don't have the inversion symmetry and the complex version of the program
> is running. I will try with Fe atoms on both sides, however, I will also
> need to do Fe2Au20 and Fe3Au20, which then makes problems with increasing
> slab size (to get enough vacuum). Of course I would like to have as many Au
> atoms as possible to increase the grid of projected band structure, this way
> Fe-related states are better separated. I understand that semi-infinite slab
> is not possible in WIEN2k ?
>
> Is there some specific problem with no-inversion symmetry (complex)
> calculation ?
>
> Regarding errors: Each time I start a new test I delete all files in the
> directory, only leaving the case.struct file. Thus I don't have the long
> history of errors. I think last error said something about the FERMI, but
> the calculation was already diverging with -ec numbers of the order of
> 50-100. Typically I was getting down to 0.3 - 0.05 energy convergence after
> few cycles, and then it was again increasing and oscillating between 20 and
> 0.1 for another several tenths of iterations. But I was always trying with
> 10x10x1 (or smaller) mesh.
>
> Could you let me know what should be the proper R0 for Fe and Au ? I am
> using R0=0.000005 or 0.000001 for Au and R0=0.00005 for Fe.
>
> Regards,
> Lukasz
>
>
>
>
>
> On 9/22/2010 4:57 PM, Peter Blaha wrote:
>>
>> 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
>>
>
> _______________________________________________
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Check2
Type: application/octet-stream
Size: 100 bytes
Desc: not available
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20100923/2a91c026/attachment.dll>