[Wien] Slab convergence -- continuation
Lukasz Plucinski
pluto at physics.ucdavis.edu
Thu Sep 23 11:38:05 CEST 2010
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.
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
>
More information about the Wien
mailing list