Dear Stefaan,
I ran your case (exactly your input files) and had NO problems at all.
The case converges quickly and smoothly.
One possibility: You have a memory error on one of your nodes ?
Run a memory check utility and verify if the ghostbands occur always on
the same node(s).
Peter
:ENE : *
Seems to be a difficult and strange situation. I've met that before only one a
very few cases. I'm NOT surprised that the problems happen only for a certain
k-point, that was also in my cases.
Definitely the -in1new case needs some changed eseper-parameters (in2c), so
that it does
not separate sc
Dear wien2k community,
I want to come back to this thread, as I did not yet succeed to identify
what is really going on.
To summarize the original problem: a crash in lapw2 for impurities in
Ge, with very large (actually **) QTL-B warnings and (sometimes)
"Eigenvalues below" warnings in t
please consider it as a speculation:
I guess you are using GGA for your calculations. It may make sense to check
whether such problem appears within LDA or not.
Javad Hashemifar
On Tue, Jul 29, 2008 at 9:19 AM, Stefaan Cottenier <
Stefaan.Cottenier at fys.kuleuven.be> wrote:
>
> Hello again,
>
Hello again,
I have been too optimistic, yesterday. The reported problem
("eigenvalues below...") did indeed disappear when I modified the
sphere radii and/or put deep semi-core states in the core, as reported
yesterday. But when I applied the same modification to a Cu atom at a
different
Laurence Marks wrote:
> Wow, to me this is a clear red flag -- you have 10 too many electrons.
>
>
>> All looks fine here too (data taken from the diverging run with LAPW):
>>
>> :NEC01: NUCLEAR AND ELECTRONIC CHARGE 2063.0 2073.45604 0.99496
>> :NEC02: NUCLEAR AND ELECTRONIC CHARGE
Thanks Peter and Laurence. The suggestion on core states/Rmt value seem
to solve it. Here are the results of the tests both of you suggested:
> I've two suspicions:
> a) Some problem with the struct file. It could be identical positions of
> one atom, wrong symmetry operations, wrong multiplicit
I've two suspicions:
a) Some problem with the struct file. It could be identical positions of
one atom, wrong symmetry operations, wrong multiplicity,...
Make sure that the analysis from nn, sgroup and symmetry fit to each
other. You may also remove case.vns temporarely to check if the problems
> The only times I have seen things like this is when, for whatever
> reason, the case.clmsum was messed up. I would check that lstart and
> dstart worked OK, and that the output from lapw0 looks reasonable. If
> all else fails, perhaps move to an LAPW basis set until you have at
> least partially
Wow, to me this is a clear red flag -- you have 10 too many electrons.
> All looks fine here too (data taken from the diverging run with LAPW):
>
> :NEC01: NUCLEAR AND ELECTRONIC CHARGE 2063.0 2073.45604 0.99496
> :NEC02: NUCLEAR AND ELECTRONIC CHARGE 2063.0 2063.0 1.
Hmmm. Some other thoughts:
1) Try "x patchsymm". It's an undocumented utility I put in with
pairhess. It will put into case.struct_new a set of atomic positions
averaged over the symmetry with an output in case.outputpatch which
will show any problems. The difference between the new/old positions
Dear wien2k community,
I ran into a case that gave a QTL-B error in the first iteration.
Following the FAQ, I therefore set the default 0.30 linearization energy
to about 0.2 Ry below the :FER that is found in case.scf2, and adjust
the linearization energies of the deeper states to the eigenval
The only times I have seen things like this is when, for whatever
reason, the case.clmsum was messed up. I would check that lstart and
dstart worked OK, and that the output from lapw0 looks reasonable. If
all else fails, perhaps move to an LAPW basis set until you have at
least partially converged
13 matches
Mail list logo
