in1new and AW: [Wien] Ghostbands appear in Wien2k05 but not in
Wien2k03, aproblem of bcc Fe ?
Peter Blaha
pblaha at theochem.tuwien.ac.at
Wed Dec 21 13:55:52 CET 2005
The next version of WIEN2k will have a modified "QTL-B" handling.
There will be a :WARN warning for qtl-b between 2 and 15 (you also
get a warning in E-tot, but this can be ignored if it just happens at the
first iterations)
It will stop only for larger qtl-b.
----------------------------
The problem with -in1new is related to your language settings.
some scripts use awk, or more specifically fprint to format some output.
floatingpoint numbers are formatted using eg. %5.3f
Unfortunately, some languages (like German !) print the decimal point with a
"comma", and not with a "dot", as required by programming languages like f90.
Solution: Check your "environment". Use for instance env
and check the value of LANG
If it is not en_US you may have troubles
(I don't know the settings for all languages, most likely several other
would work too.)
However, most likely you want to keep "your" language, so you can set the
LC_NUMERIC variable only to en_US
to check your system and the effects of these settings try:
env|grep LANG
env|grep LC
setenv LC_NUMERIC de_DE (for tcsh)
printf "%5.3f \n" 0.15
setenv LC_NUMERIC en_US
printf "%5.3f \n" 0.15
If you do not have "root" access, put this into your .cshrc/.bashrc
otherwise set it globally (on SUSE Linux use the /etc/sysconfig editor in
yast2)
----------------------
And remember also a third remark:
For "semi-localized" states (like the 3d bands in Fe) it might be best to
add a 3d-LO; i.e. put two lines something like
2 1.000 0.000 CONT 1
2 0.000 0.000 CONT 1
into case.in1. This however, requeres that you "understand" what is happening
and it may need some modifications.
-----------------------------
> I changed the test1 query in lapw2 to 10. instead of 7., just for the purpose of optimization.
> I found that (for Fe or some other 3d TM) a too large QTL-B (slightly above 7) is found only in one of the first cycles.
>
> There is, however, still a problem left that I mentioned only briefly in my question:
> If test1 .GT. 2 one receives a message like:
> QTL-B VALUE .EQ. 2.42180 in Band of energy 0.69894 ATOM= 1 L= 2
> Most likely no ghostbands, but adjust Energy-parameters or use -in1new
>
> (This QTL-B value was not much changed if using different energy parameter like 0.8 (and others) instead of 0.3. On the other hand, if choosing parameter such that finally QTL-B above 5 appeared charge converegence (-cc 0.01) was never reached - Is that always the case ? - and indeed the total energy was some type of bad.)
>
> Now if restarting the calculation with -in1new n one receives in the n-th cycle the error (described already in the FAQ):
> forrtl: severe (64): input conversion error, unit 1001, file /home/someone/somewhere/somewhat.helpup031
> and checking helpup031 one finds lines with ********************
> like:
> L= 1 85.49314 ********** 80.097******************** -18.850
>
> This is here not related to a QTL-B problem as seen if inspecting the in1new file. One finds that the numerical format of some lines is wrong. The new in1 is:
>
> WFFIL (WFPRI, SUPWF)
> 7.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT
> .31122 4 0 global e-param with N other choices, napw
> 0 0,000 0,000 CONT 1
> 1 0,000 0,000 CONT 1
> 1 -3,000 0,000 CONT 1
> 2 0,000 0,000 CONT 1
> K-VECTORS FROM UNIT:4 -7.0 3.5 emin/emax window
>
> However, correcting from ',' to '.' leads to large QTL-B values (here >14 for the Fe example) what is clear from youre answer.
>
> You explained already recently that in1new may not deliver "better" energy parameter, but I wonder if the write_in1_lapw script (or wherever these lines are produced) is doing something wrong (not only format but also values) or if something is wrong with my setup (seems to appear also with an English SUSE distribution). I had no old Versions at hand to check whether this is a problem of my current version.
>
> As there was recently another question about in1new and possible problems, it may be that the same appeared in that case.
>
> Thanks and Ciao
> Gerhard
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: wien-bounces at zeus.theochem.tuwien.ac.at im Auftrag von Peter Blaha
> Gesendet: Mo 12.12.2005 14:31
> An: A Mailing list for WIEN2k users
> Betreff: Re: [Wien] Ghostbands appear in Wien2k05 but not in Wien2k03, aproblem of bcc Fe ?
>
> Hi,
> Yes, I tightened the critera in the newer versions of WIEN2k. I want to make
> sure that you cannot do a "bad calculation", but I admit, maybe I was slightly
> too strict.
> Anyway, at the same time I also added some information which should make it
> easier to change the corresponding E-parameter
>
> QTL-B VALUE .EQ. 1.27789 in Band of energy 0.50621 ATOM= 2 L= 2
>
> It gives information about: which atom, which angular momentum (L=2) and
> at which eigenvalue it happens.
>
> Usually it is sufficient to change the E-parameter for this atom and L
> (eg. raise the default 0.3 to 0.8 (check your FERMI energy).
>
> The other features you describe can also be easily understood:
> Volume contraction leads to a higher EF (this your default 0.3 becomes "bad");
> and the E-dependency of a wavefunction is largeest at large distances, thus
> for small RMT your correction due to the B_lm . u-dot term should be smaller
> (no QTL-B problem).
>
>
> Unfortunately I don't know a simple solution which
> a) makes sure that one cannot make a "bad" calculation
> b) is "user-friendly" and "fault-tolerant".
>
> Regards
>
> > I wonder if there was somewhen betwen Wien2k04 and Wien2k05 any change with the QTL-B Ghostband error recognition that was not present in Wien2k03.
> >
> > The problem is the following and appears in the actuall and some older Versions of Wien2k05:
> > I tried to optimize Fe, intended to calculate the range of about -8% to +8% of the lattice parameter.
> > I started with the experimental lattice parameters (2.867A spacegroup 229 for Fe).
> > I used RMTs being 8% (I tried also 6%) lower than needed for the experimental lattice parameter, otherwise the spheres will later overlap for the "small" lattice parameter.
> >
> > The calculations stopped with a QTL-B Ghostband error in lapw2 either in the first, but latest in the 3rd scf cycle.
> > In particular this was the cases for lattice parameters -2% ... -6% (-8%). It is probably interesting to note that the larger lattice parameter worked with the small RMT. The error appears rather fuzzy, sometimes a very small change of the RMT already makes it vanishing, in spin polarized calculations it appears either in lapw2 -up or -dn, just with small changes in the input parameters (unfortunately I did not keep all possibilities I tried in mind)
> >
> > I also changed the energy values in the in.. files, without healing the problem.
> > The use of the switch in1new did not help, but leads to another error that one of the files cannot be read (but thats another story). Anyway, in case of the crash in the first cycle it cannot help at all.
> >
> > I also tried nearly everything reported and suggested in the last year about the Ghostband error, nothing helped really, maybe just for a particular set of the input what points only on some instability.
> >
> > I tried also different fortran compilers (different Versions of Intel and Portland Group), computers, and Linux Kernel Versions, so optimization of the code or any bad library do not cause the problem.
> >
> > Note the errors occure, indeed, if one just tries to do a simple scf cycle, using the same input parameter, without using the optimization script. It appears for spinpolarized as well as non-spinpolarized calculations but interesting to note for Cr it appeared for bcc but not for CsCl structure with 2 different Cr atoms as a practice for an AFM calculation.
> >
> > However, all this seems not to be the real problem. I was wondering because its usually a practice for our students to optimize Fe, and last year I never experienced any troubles with calculating or optimizing Fe.
> >
> > I have one old Version (Wien2k03) running on one computer, and with this Version I do not have any problems (it is even possible to use much smaller RMT values without any troubles).
> > I recognized that problem first time with one of the first Wien2k05 Versions at the beginning of the year, but did not follow it as I had not enough time and first thought I just made an error during initialization, and with more complicated structures I haven't had the problem, actually, I guess just by chance.
> >
> > I am already about to change the fortran code and switch of the stop after the error and convert it to a printed warning only, but do not know whether this may cause any other troubles.
> >
> > Peter, in case you cannot reproduce the error or if you need more information then let me know, I will ask Hem to prepare and send a complete set of files.
> >
> > Thanks and Ciao from Mainz
> > Gerhard
> >
> >
> >
>
>
> P.Blaha
> --------------------------------------------------------------------------
> Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
> Phone: +43-1-58801-15671 FAX: +43-1-58801-15698
> Email: blaha at theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/
> --------------------------------------------------------------------------
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
>
P.Blaha
--------------------------------------------------------------------------
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-15671 FAX: +43-1-58801-15698
Email: blaha at theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/
--------------------------------------------------------------------------
More information about the Wien
mailing list