[Wien] Re: in1new and AW: Language variables
Gerhard H Fecher
fecher at uni-mainz.de
Wed Dec 21 16:58:56 CET 2005
Thanks to you all for the suggestions,
I wonder why the global parameter is changed from .3 to .311 with the '.'
correctly, whereas the other values come with a ',' ?
Ciao Gerhard
Am Mittwoch, 21. Dezember 2005 14:31 schrieb L. D. Marks:
> I ran into something similar with some other code a year or so ago. In
> a nutshell, there is at least a 10% chance of a large code collapsing
> if it is compiled and/or run in anything except english (or american).
> I would suggest setting "LC_ALL=C" in .bashrc and .cshrc; maybe
> something also for w2web. One source of more information is
> http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html .
>
> On Wed, 21 Dec 2005, Peter Blaha wrote:
>
> > 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/
> > --------------------------------------------------------------------------
> > _______________________________________________
> > Wien mailing list
> > Wien at zeus.theochem.tuwien.ac.at
> > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> >
>
> Note: if you have an old email address for me, please note that "nwu" has
> been changed to "northwestern".
> -----------------------------------------------
> Laurence Marks
> Department of Materials Science and Engineering
> MSE Rm 2036 Cook Hall
> 2220 N Campus Drive
> Northwestern University
> Evanston, IL 60201, USA
> Tel: (847) 491-3996 Fax: (847) 491-7820
> email: L-marks at northwestern dot edu
> http://www.numis.northwestern.edu
> -----------------------------------------------
>
More information about the Wien
mailing list