Thank you Dr. BlahaThis work well.All the best for you.
Sent from Yahoo Mail on Android
On Wed, Nov 15, 2023 at 0:32, Peter Blaha wrote:
Well, at the end it is exactly as I said:
Your manual RMT settings are very bad. One of the rules is, that
smallest and largest RMTs must not be too
Well, at the end it is exactly as I said:
Your manual RMT settings are very bad. One of the rules is, that
smallest and largest RMTs must not be too different.
With your spheres you get "effective" R(Si)Kmax of more than 12 and this
gives numerical linear dependency.
With your struct file:
Dr. Blahasometimes, semicore error appears in iteration3, sometime in 6, and
... (with changing rmts).
I tried with the struct attached here and the default init_lapw. After
finalized initialization, I changed RKm=7 (and Emax=3) in case.in1c attached
here, and run dstart. This time, semicore
Again, your message gets too big. You must delete the older content.
---
grep :DIS in case.scf:
:DIS : CHARGE DISTANCE ( 0.0122755 for atom3 spin 1)
0.0083335
:DIS : CHARGE DISTANCE ( 0.0117894 for atom3 spin 1)
Looking at your original case.in1, something went very unstable and that
led to the crash. I think some more information might help:
1. What functional are you using?
2. What k-mesh?
3. Spin polarized or not?
4. Are you minimizing positions with -min?
5. Did you change anything in case.in0 &
I suppose the modified l2main.F to SRC_lapw2 for WIEN2k 23.2 won't
affect this particular case, but if one wants to try it out to know for
sure, I have posted the patch file for it today at [1] or put the link
in the README at [1] that directs to the mailing list post with the
l2main.F.gz file
I used exactly the struct file you sent (with your RMTs, even if I would
not choose them this way).
init -prec 1n
run_lapw
save rkm6
edit case.in1 to change RKmax
run_lapw
no problems.
I do not understand, how you can get your error: (SELECT E-top/bottom
not found) when you just change
Yes, I use WIEN2k_23.2Let me know how are rmt of atoms in structure file which
you used.
Sent from Yahoo Mail on Android
On Tue, Nov 14, 2023 at 11:31, Peter Blaha wrote:
As I wrote before: I cannot reproduce this. For me it converges fine
even with RKmax=7. No errors. Thus, I don't
As I wrote before: I cannot reproduce this. For me it converges fine
even with RKmax=7. No errors. Thus, I don't know how to help you.
Are you using WIEN2k_23.2 ??
Am 13.11.2023 um 15:39 schrieb hajar.nejatipoor--- via Wien:
Dear Dr. Blaha
I act as you said, but the problem "LAPW2' -
Dear Dr. BlahaI act as you said, but the problem "LAPW2' - semicore
band-ranges too large, ghostbands" exists again!!LO for N-2s orbitals in
case.in1c were removed, but it worked just for rkm=6 (with or without LO for
N).I tried your way with changing rmt of atoms but the problem remained.
I
I tried your struct file, converged with RKM=6, saved, increased RKMax
to 7 and continued with run_lapw.
No problem. As expected with your RMTs rather small change from 6 to 7
and quick convergence.
You must have changed something else, like mixing a density with
different RMTs,
Dear Dr. BlahaThe way you proposed, just worked for RKm=6, and the error below
appeared for the case of RKm=7: 'SELECT' - no energy limits found for atom 1
L= 0
'SELECT' - E-bottom -520.0 E-top -520.0
It is worth to mention that since for Si-muffin tin
First of all, setrmt gives:
1 42.0 2.12 2.12
2 14.0 1.68 1.68
3 7.0 1.61 1.60
4 7.0 1.60 1.60
So the N radii are much larger and Si and Mo smaller.
It might be that the ghostband comes from N-2s, as the small RMT may not
allow for 2 radial functions. You could try to
Dear Wien2k developers and usersI want to converge RKmax for the monolayer
MoSi2N4.For Rkm=6, the scf is converged without problem, but when running the
scf with Rkm=7, the error "'LAPW2' - semicore band-ranges too large,
ghostbands" appears. I tried with changing muffin tin radii, but the
Dear all,
after switching to Wien2k_13, I frequently get the semicore band ranges
too large error, often during relaxation. Though I can understand why
that should not happen, can you explain what could have gone wrong that
it appears and how the source of this error can be traced?
Best regards,
This check was introduced recently to detect ghost bands.
If this problem appears at the very beginning of the SCF iteration
for a new geometry then there is probably no problem of ghost bands.
This is just the starting density which is not good.
To avoid the stop of the calculation, in case.in2
16 matches
Mail list logo
