[Wien] RMT, El and warnings in qtl-b and :ENE
Guo-ping Zhang
gpzhang at nano.indstate.edu
Sun Mar 25 06:37:54 CEST 2007
Dear Dr. Blaha, Dr. Cottenier and all the WIEN users,
Thank you so much for your help!
I would like to obtain a good set of linearization energies (case.in1)
for fcc nickel and other geometries, where I closely follow the paper
by Dr. Cottenier.
Here is what I did. All the calculations are run sequentially on a
single computer (intel, see below) and parallel calculations on a
different machine (Opteron) do not have the following problem.
(1) Reproduce the fccni results (example), with default parameters in
case.in1 and sp case plus -cc 0.0001 (I run first -ec 0.00001).
Results are good.
userguide: MMTOT: 0.63068 (RMT=2.3 )
mine : 0.63041 (with -ec RMT=2.35)
0.63040 (with -cc RMT=2.35)
0.63066 (with -cc RMT=2.30)
(2) Change rkm from 7.0 to 9.5 in case.in1 (3000 KPT) by
re-initializing (init) (case.in1 is checked afterwards to make sure
9.5 is there and save all the previous calculation (save))
(a) If RMT=2.30, then
my MMTOT: 0.62917 (runsp -I -i 40 -ec 0.00001 )
optimized MMTOT: 0.63057 (runsp -I -i 40 -ec 0.00001 )
^__no qtl-b warning and no :ENE **WARN** for energy
(b) If RMT=2.35 (which is suggested by the program), then
FORTRAN STOP LAPW0 END
FORTRAN STOP SECLR4 - Error
Cholesky INFO = 91
'SECLR4' - POTRF (Scalapack/LAPACK) failed.
(3) Does this (referring to 2(b)) indicate overcompleteness as
suggested by Dr. Cottenier, where the quasi-linear dependence among
the basis states as you mentioned? If so, why does my parallel job on
a pc cluster run without any problem? Is it possible each machine has
different thresholds to invoke the Cholesky warning?
(4) I noticed in attached fccni example, if grep :ENE *.scf
:ENE : ********** TOTAL ENERGY IN Ry = -3041.652575
:ENE : ********** TOTAL ENERGY IN Ry = -3041.652605
however, if I use the exact same parameters (case.in1,in2,struct), I got
:ENE : *WARNING** TOTAL ENERGY IN Ry = -3041.652612
:ENE : *WARNING** TOTAL ENERGY IN Ry = -3041.652589
even though I got a similar qtl-b 3.72 or 2.47.
Is this normal or something I should worry?
(5) I managed to get rid of the above warnings (qtl-b and *WARNING*)
by modifying the case.in1's parameters (E_l), but I found it is not
enough to simply follow Dr. Cottenier's method which emphasizes on the
low-lying states (below Ef) and I have to combine -in1new and dos to
get rid of warnings of states above Ef. I wish someone would
systematically explain how to balance the unoccupied and occupied
states, and in particular how to add additional E_l such as 2 1.50
0.000 Cont 0. In Ni, adding this line leads to an immediate error and
make things worse. Is there any rule of thumb or theory behind this?
If you need any additional info, please let me know.
Thank you so much for your time and help in advance!
Best regards,
Guoping
More information about the Wien
mailing list