in1new and AW: [Wien] Ghostbands appear in Wien2k05 but not in
Wien2k03, aproblem of bcc Fe ?
Gerhard Fecher
fecher at uni-mainz.de
Wed Dec 21 11:08:26 CET 2005
Hallo Peter,
thanks for youre detailed reply.
My workarround is:
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 7258 bytes
Desc: not available
Url : http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20051221/50a02efc/attachment.bin
More information about the Wien
mailing list