Re: [Wien] Error in bandstructure using x spaghetti

[Peter Blaha]

It is obvious that the error occurs while reading the input file *.insp

Most likely you did not put the correct Fermi energy into this file. By 
default there is a   x.  laceholder and this has to be replaced by 
your EF (which you can find in your scf file (grep :FER case.scf).


Regards

Am 15.11.2023 um 08:12 schrieb 夏宇阳:

Hi,
I am facing a error in the bandstructure with the commandline x spaghetti.My compiler is 
gfortran and openblas in Ubuntu.Program input is: ""

At line 37 of file inview.f (unit = 5, file = 'TiC_2.insp')
Fortran runtime error: Bad real number in item 2 of list input

Error termination. Backtrace:
#0  0x14c33ec23960 in ???
#1  0x14c33ec244d9 in ???
#2  0x14c33ec2510f in ???
#3  0x14c33ee701b6 in ???
#4  0x14c33ee715fd in ???
#5  0x14c33ee722aa in ???
#6  0x55d306f3fc93 in ???
#7  0x55d306f43ef2 in ???
#8  0x55d306f3731e in ???
#9  0x14c33e829d8f in __libc_start_call_main
at ../sysdeps/nptl/libc_start_call_main.h:58
#10  0x14c33e829e3f in __libc_start_main_impl
at ../csu/libc-start.c:392
#11  0x55d306f37344 in ???
#12  0x in ???
0.083u 0.015s 0:00.09 100.0%0+0k 0+16io 0pf+0w
error: command   /home/xyy/wien2k/spaghetti spaghetti.def   failed

Could you help me to solve it? Thank you very much!
Best wishes!


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html


--
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300
Email: peter.bl...@tuwien.ac.atWIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at
-
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] Error in bandstructure using x spaghetti

[夏宇阳]

Hi,
I am facing a error in the bandstructure with the commandline x spaghetti.My 
compiler is gfortran and openblas in Ubuntu.Program input is: ""

At line 37 of file inview.f (unit = 5, file = 'TiC_2.insp')
Fortran runtime error: Bad real number in item 2 of list input

Error termination. Backtrace:
#0  0x14c33ec23960 in ???
#1  0x14c33ec244d9 in ???
#2  0x14c33ec2510f in ???
#3  0x14c33ee701b6 in ???
#4  0x14c33ee715fd in ???
#5  0x14c33ee722aa in ???
#6  0x55d306f3fc93 in ???
#7  0x55d306f43ef2 in ???
#8  0x55d306f3731e in ???
#9  0x14c33e829d8f in __libc_start_call_main
at ../sysdeps/nptl/libc_start_call_main.h:58
#10  0x14c33e829e3f in __libc_start_main_impl
at ../csu/libc-start.c:392
#11  0x55d306f37344 in ???
#12  0x in ???
0.083u 0.015s 0:00.09 100.0%0+0k 0+16io 0pf+0w
error: command   /home/xyy/wien2k/spaghetti spaghetti.def   failed

Could you help me to solve it? Thank you very much!
Best wishes!


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] Parallel LAPW1 job suspended without any error message

[heungsikim]

Dear Wien2k users,

I’ve recently encountered a strange situation in parallel execution of Wien2k 
(version 19). Normally I run wien2k jobs using OpenMP and they works without 
any trouble. But recently there has been a project that I need to run wien2k 
using k-point parallelization, and I am having a trouble that I couldn’t solve.

Issue:

• When running wien2k using k-point parallelization (with the -p option in 
run_lapw and .machines file), the job suspends at the lapw1 stage and does not 
produce any lapw1 output (such as case.vector_* files) or error messages.
• Terminating the job and running the command “x lapw1 -p” reproduces the 
symptom. Checking active processes in the compute node while the “x lapw1 -p” 
command is on does now show any lapw1 jobs running, except the signature of 
suspended lapw1para script.
• Removing the -p option and running in serial or using OpenMP multithreads 
work totally OK.

Further info. on my system:

• Wien2k version: 19.1 (also unofficially tried with version 23, the same 
problem persists)
• System: Ubuntu 20.04 LTS
• Compiler, math library: Intel oneapi 2023 version, with intel icc, ifort, 
mpiifort, and MKL (lapack, blacs, scalapack).
• FFTW: FFTW3, compiled using intel compilers from source (ver. 3.3.8)
• MPI: Intel MPI included in the Intel oneapi package, and with MPI_REMOTE = 0
• Tried both using / not using mpi parallelization. The same lapw1 
suspension persists.

My .machines file looks like below (for a 4 core test job):

granularity:1
1:localhost
1:localhost
1:localhost
1:localhost
extrafine:1


I checked that, after running x lapw1 -p, a list of case.klist_* files and 
lapw1_*.def files are created in the working directory (and also “.machine* 
files). Running each of k-divided case using lapw1 (for example, using commands 
like “lapw1 lapw1_1.def”) works fine and creates case.vector_* files correctly. 
Strangely, actual "x lapw1 -p" (or “lapw1para_lapw lapw1.def”) does not enter 
the lapw1-running stage and suspends somewhere before that.

Because this suspension does not create any error or other messages, I have no 
idea on how to solve this issue. Currently what I tried are as follows:

• Recompiling wien2k without any mpi-related options (which means, even with 
setting MPI_REMOTE to be 1)
• Tuning DELAY and SLEEPY in lapw1para
• Running the parallel job on a local storage (not on a NFS storage)
• As mentioned above, using newer wien2k version 23 (just as a test purpose! I 
am not producing any scientific results with that)
• Removing fftw3. But this should not matter, because lapw1 does not seem to 
use fftw

which all were not successful in rectifying the issue.

I tried searching the previous wien2k mailing list, I might missed, but I 
couldn’t find any issue similar to mine. Any of your comments will be highly 
appreciated!

Best regards,
Heung-Sik

---
Heung-Sik Kim
Assistant Professor
Department of Physics
Kangwon National University
email: heungsi...@kangwon.ac.kr
https://sites.google.com/view/heungsikim/
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] semicore band ranges too large error: for MoSi2N4

[Peter Blaha]

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: RMT(N)=1.2  (Si)=2.1
init
set RKmax=7
run
> gives the semicore error you describe due to some ghostbands.

init
run
save  rkm6
set RKmax=7
run
---> runs through and converges.

However, increasing RKmax to 8 gives ghost bands again.

-

setrmt
cp case.struct_setrmt case.struct  ( similar RMTs for Si and N, around 1.6)
init -ecut -8   (to avoid core leakage)
set rkmax=7
run
---> converges without problems. One can increase Rkmax further to 8 and 
even 9.


--

PS: These ghostbands are located in the interstital, give no qtl-b 
errors. Once such a state is taken into the density, you get these 
"select"-errors.


Am 14.11.2023 um 19:19 schrieb hajar.nejatipoor--- via Wien:

Dr. Blaha
sometimes, *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 error was appeared in 
the *first* iteration!

I have been confused why?
(I see that default init_lapw for above setting (RKm=7 and Emax=3)) 
contains 24 kpoints. and error is appeared.
(In another scf with above struct (RKm=7 and Emax=1.5), default number 
of kpoints was 7! ). and scf ended successfully.


May this error be dependent on the number of k-point and the number of 
cores in .machines file?

.machines file in two calculations contained 7 cores.
On Tuesday, November 14, 2023 at 03:08:50 PM GMT+3:30, Peter Blaha 
 wrote:



Again, your message gets too big. You must delete the older content.
---

grep :DIS in case.scf:

:DIS  :  CHARGE DISTANCE      (  0.0122755 for atom    3 spin 1)
0.0083335
:DIS  :  CHARGE DISTANCE      (  0.0117894 for atom    3 spin 1)
0.0077543
:DIS  :  CHARGE DISTANCE      (  0.0405700 for atom    1 spin 1)
0.0200036
:DIS  :  CHARGE DISTANCE      (  0.2010006 for atom    1 spin 1)
0.0741310
:DIS  :  CHARGE DISTANCE      (  0.0164221 for atom    1 spin 1)
0.0107305
:DIS  :  CHARGE DISTANCE      (  0.1052329 for atom    1 spin 1)
0.0370176
:DIS  :  CHARGE DISTANCE      (  0.0075476 for atom    1 spin 1)
0.0021153
:DIS  :  CHARGE DISTANCE      (  0.0848258 for atom    1 spin 1)
0.0300654
:DIS  :  CHARGE DISTANCE      (  0.0018758 for atom    1 spin 1)
0.0007564
:DIS  :  CHARGE DISTANCE      (  0.0008796 for atom    3 spin 1)
0.0006306
:DIS  :  CHARGE DISTANCE      (  0.0013281 for atom    3 spin 1)
0.0008331

after iteration 3, the semicore error is appeared for rkm=7.
--

Nobody knows what you were sending. Is this from the RKM=6 calculation ?

You have done a scf with RKmax=6.  This should be saved.

Then you have an empty scffile, and you should increase RKmax to 7 and
run the scf.
If the error occurs after iteration 3, we expect to see exactly 3 lines.

???
Did you ever save the rkm6 results ?

restore them in a new directory, increase rkmax and then run_lapw.
When it crashes, show us :dis.


--
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300
Email: peter.bl...@tuwien.ac.at 
WIEN2k: http://www.wien2k.at 

WWW: http://www.imc.tuwien.ac.at 
-
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at 
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien 

SEARCH the MAILING-LIST at: 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html 



___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html


--
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300
Email: peter.bl...@tuwien.ac.atWIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at
-
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at

Re: [Wien] semicore band ranges too large error: for MoSi2N4

[hajar.nejatipoor--- via Wien]

 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 error was appeared in the first 
iteration!I have been confused why?(I see that default init_lapw for above 
setting (RKm=7 and Emax=3)) contains 24 kpoints. and error is appeared.(In 
another scf with above struct (RKm=7 and Emax=1.5), default number of kpoints 
was 7! ). and scf ended successfully.
May this error be dependent on the number of k-point and the number of cores in 
.machines file?
.machines file in two calculations contained 7 cores.
On Tuesday, November 14, 2023 at 03:08:50 PM GMT+3:30, Peter Blaha 
 wrote:  
 
 Again, your message gets too big. You must delete the older content.
---

grep :DIS in case.scf:

:DIS  :  CHARGE DISTANCE      (  0.0122755 for atom    3 spin 1) 
0.0083335
:DIS  :  CHARGE DISTANCE      (  0.0117894 for atom    3 spin 1) 
0.0077543
:DIS  :  CHARGE DISTANCE      (  0.0405700 for atom    1 spin 1) 
0.0200036
:DIS  :  CHARGE DISTANCE      (  0.2010006 for atom    1 spin 1) 
0.0741310
:DIS  :  CHARGE DISTANCE      (  0.0164221 for atom    1 spin 1) 
0.0107305
:DIS  :  CHARGE DISTANCE      (  0.1052329 for atom    1 spin 1) 
0.0370176
:DIS  :  CHARGE DISTANCE      (  0.0075476 for atom    1 spin 1) 
0.0021153
:DIS  :  CHARGE DISTANCE      (  0.0848258 for atom    1 spin 1) 
0.0300654
:DIS  :  CHARGE DISTANCE      (  0.0018758 for atom    1 spin 1) 
0.0007564
:DIS  :  CHARGE DISTANCE      (  0.0008796 for atom    3 spin 1) 
0.0006306
:DIS  :  CHARGE DISTANCE      (  0.0013281 for atom    3 spin 1) 
0.0008331

after iteration 3, the semicore error is appeared for rkm=7.
--

Nobody knows what you were sending. Is this from the RKM=6 calculation ?

You have done a scf with RKmax=6.  This should be saved.

Then you have an empty scffile, and you should increase RKmax to 7 and 
run the scf.
If the error occurs after iteration 3, we expect to see exactly 3 lines.

???
Did you ever save the rkm6 results ?

restore them in a new directory, increase rkmax and then run_lapw.
When it crashes, show us :dis.

-- 
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300
Email: peter.bl...@tuwien.ac.at    WIEN2k: http://www.wien2k.at
WWW:  http://www.imc.tuwien.ac.at
-
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
  

mosi2n4.in1c
Description: Binary data


mosi2n4.struct
Description: Binary data
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] wien2k workshop

[Peter Blaha]

Dear wien2k users,

This is just a reminder that the deadline for "financial support" ends

18.November 2023 !!!

Of course the registration keeps open for those who do not need extra 
support.


For more info follow the workshop links on www.wien2k.at

Peter Blaha
--
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300
Email: peter.bl...@tuwien.ac.atWIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at
-
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] Speed of cluster nodes

[Peter Blaha]

Am 14.11.2023 um 14:24 schrieb pluto via Wien:

Dear Prof. Blaha,

Reducing the energy window in case.inso seems to work, but there are 
some minor issues. I would like to clarify them.


Normally I run the sequence:

x lapw1 -band -up -p
x lapw1 -band -dn -p
x lapwso -up -p
x qtl -up -p -band -so
x qtl -dn -p -band -so

When I limit the range a lot in case.inso before starting this sequence, 
I don't have Fermi energy in the case.scf2up/dn (I paste such "bad" file 
below). This then leads to an error when running "x qtl".


This sequence is ok. Note, the  x qtl step will automatically 
recalculate  x lapw2 -fermi -so ..., so you get a new case.scf2up/dn file.

When you get  as EF, something must be wrong.

When you reduce Emin in case.inso, you also have to adjust properly the 
number of electrons NOE in case.in2c (Check from the band ranges in 
case.output2 of a "normal" calculation how many bands you will cut away 
and reduce NOE accordingly). In any case, EF will be wrong since your 
k-mesh is not a regular one.

And of course Emax must still be large enough to cover all electrons ...



It seems there is no error when first running "x lapw1 up/dn" and "x 
lapwso" with the default case.inso, then limiting the range in 
case.inso, and then re-running only "x lapwso".




When you rerun   x lapwso with modified inso file, all previous data 
from the lapwso step are overwritten. What you describe is not possible.




PS: "x qtl" needs case.in1c for running correctly. So, if that file does 
not exist then I simply make a copy of the case.in1. Is that OK?


Yes.







    TEMP.-SMEARING WITH    0.00200 Ry
   -S / Kb   =  -6.57973595
   -(T*S)/2  =  -0.00328987
   Chem Pot  = 
  Bandranges (emin - emax) and occupancy:
     Energy to separate low and high energystates:    0.39949


:NOE  : NUMBER OF ELECTRONS  = 1440.000

:FER  : F E R M I - ENERGY(FERMI-SM.)= **
:GMA  : POTENTIAL AND CHARGE CUT-OFF  16.00 Ry**.5








On 2023-11-11 18:20, Peter Blaha wrote:

For your problem, you just need to reduce the Energy window in
case.inso when you do the fine k-mesh (no scf with this k-mesh).
Make sure, your emin does not cut bands, but falls in a "gap".

Usually, all k-points take the same time (within 10 % or so).
It looks more as if one node is (temporarely) overloaded or has
network (disk) problems.
Try to check it by logging into this node and use eg. "top".


Am 10.11.2023 um 18:53 schrieb pluto via Wien:

Dear Prof. Blaha, dear All,

Thank you for you comment. When changing numbers as you suggested the 
convergence over few cycles didn't look very good. So I decided to 
redo the calculation with init_lapw -prec 1 -ecut 0.999, I think this 
is safer and I hope the files will be smaller. Once this is done, I 
will try to reduce emax in case.inso.


The origin of the problem is that I would like to make a kx-ky mesh 
for the slab, this means maybe 2000-3000 kpoints to see bands as 
surfaces nicely. Then the output files become very large, and 
case.qtl files are large too (I typically do a SOC and FM 
calculation). One can limit the energy range in case.inq to e.g. from 
-1 to 1, but this sometimes (for unknown reasons) leads to some 
counting issues of the bands, i.e. different k-points have different 
bands order. This might be related to the lower energy cutting though 
a band, but some time ago I tried different ranges in case.inq and it 
was not very helpful (but I need to try more). Anyway, not a big 
deal, in the end this can be sorted out in many ways. In general most 
of the time I only need bands from say -10 to 10 eV around the Fermi 
level, so in general it is good to learn how to calculate only that, 
perhaps increasing the calculation speed and reducing the output file 
sizes.


Another question: I often run on the older cluster. All nodes should 
be the same and I distribute k-points uniformly (e.g. 8 k-points per 
node). I noticed that sometimes some nodes are calculating much 
slower (e.g. lapw1 or lapwso) than other nodes. Is that normal? I 
would expect maybe small fluctuations due to the particular CPU 
cooling efficiency etc., but nothing dramatic. Or perhaps sometimes 
some k-points need more time?


Best,
Lukasz


On 2023-11-07 18:42, Peter Blaha wrote:

I'm not quite sure what you mean.

restore your saved calculation and:
i)  Reduce emax in case.inso
This reduces the size of case.vectorso, but has no influence on the
scf. (One iteration is enough).
ii) reduce Ecut in case.in1.  However, this will make your spinorbit
calculation much less accurate. You need to run the scf, but it should
converge quicker .

Am 07.11.2023 um 18:26 schrieb pluto via Wien:

Dear All,

I have a larger FM-SOC calculation converged (and saved) with the 
default Ecut.


I would like to converge with smaller Ecut (say 1 Ry), to have the 
output files smaller.


Is there a good way to do this, using the 

Re: [Wien] Speed of cluster nodes

[pluto via Wien]

Dear Prof. Blaha,

Reducing the energy window in case.inso seems to work, but there are 
some minor issues. I would like to clarify them.


Normally I run the sequence:

x lapw1 -band -up -p
x lapw1 -band -dn -p
x lapwso -up -p
x qtl -up -p -band -so
x qtl -dn -p -band -so

When I limit the range a lot in case.inso before starting this sequence, 
I don't have Fermi energy in the case.scf2up/dn (I paste such "bad" file 
below). This then leads to an error when running "x qtl".


It seems there is no error when first running "x lapw1 up/dn" and "x 
lapwso" with the default case.inso, then limiting the range in 
case.inso, and then re-running only "x lapwso".


Maybe you could comment what would be the correct sequence here.

Best,
Lukasz

PS: "x qtl" needs case.in1c for running correctly. So, if that file does 
not exist then I simply make a copy of the case.in1. Is that OK?






   TEMP.-SMEARING WITH0.00200 Ry
  -S / Kb   =  -6.57973595
  -(T*S)/2  =  -0.00328987
  Chem Pot  = 
 Bandranges (emin - emax) and occupancy:
Energy to separate low and high energystates:0.39949


:NOE  : NUMBER OF ELECTRONS  = 1440.000

:FER  : F E R M I - ENERGY(FERMI-SM.)= **
:GMA  : POTENTIAL AND CHARGE CUT-OFF  16.00 Ry**.5








On 2023-11-11 18:20, Peter Blaha wrote:

For your problem, you just need to reduce the Energy window in
case.inso when you do the fine k-mesh (no scf with this k-mesh).
Make sure, your emin does not cut bands, but falls in a "gap".

Usually, all k-points take the same time (within 10 % or so).
It looks more as if one node is (temporarely) overloaded or has
network (disk) problems.
Try to check it by logging into this node and use eg. "top".


Am 10.11.2023 um 18:53 schrieb pluto via Wien:

Dear Prof. Blaha, dear All,

Thank you for you comment. When changing numbers as you suggested the 
convergence over few cycles didn't look very good. So I decided to 
redo the calculation with init_lapw -prec 1 -ecut 0.999, I think this 
is safer and I hope the files will be smaller. Once this is done, I 
will try to reduce emax in case.inso.


The origin of the problem is that I would like to make a kx-ky mesh 
for the slab, this means maybe 2000-3000 kpoints to see bands as 
surfaces nicely. Then the output files become very large, and case.qtl 
files are large too (I typically do a SOC and FM calculation). One can 
limit the energy range in case.inq to e.g. from -1 to 1, but this 
sometimes (for unknown reasons) leads to some counting issues of the 
bands, i.e. different k-points have different bands order. This might 
be related to the lower energy cutting though a band, but some time 
ago I tried different ranges in case.inq and it was not very helpful 
(but I need to try more). Anyway, not a big deal, in the end this can 
be sorted out in many ways. In general most of the time I only need 
bands from say -10 to 10 eV around the Fermi level, so in general it 
is good to learn how to calculate only that, perhaps increasing the 
calculation speed and reducing the output file sizes.


Another question: I often run on the older cluster. All nodes should 
be the same and I distribute k-points uniformly (e.g. 8 k-points per 
node). I noticed that sometimes some nodes are calculating much slower 
(e.g. lapw1 or lapwso) than other nodes. Is that normal? I would 
expect maybe small fluctuations due to the particular CPU cooling 
efficiency etc., but nothing dramatic. Or perhaps sometimes some 
k-points need more time?


Best,
Lukasz


On 2023-11-07 18:42, Peter Blaha wrote:

I'm not quite sure what you mean.

restore your saved calculation and:
i)  Reduce emax in case.inso
This reduces the size of case.vectorso, but has no influence on the
scf. (One iteration is enough).
ii) reduce Ecut in case.in1.  However, this will make your spinorbit
calculation much less accurate. You need to run the scf, but it 
should

converge quicker .

Am 07.11.2023 um 18:26 schrieb pluto via Wien:

Dear All,

I have a larger FM-SOC calculation converged (and saved) with the 
default Ecut.


I would like to converge with smaller Ecut (say 1 Ry), to have the 
output files smaller.


Is there a good way to do this, using the converged one as a 
starting point, to avoid the lenghty convergence?


Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at: 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at

Re: [Wien] semicore band ranges too large error: for MoSi2N4

[Peter Blaha]

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) 
0.0077543
:DIS  :  CHARGE DISTANCE  (  0.0405700 for atom1 spin 1) 
0.0200036
:DIS  :  CHARGE DISTANCE  (  0.2010006 for atom1 spin 1) 
0.0741310
:DIS  :  CHARGE DISTANCE  (  0.0164221 for atom1 spin 1) 
0.0107305
:DIS  :  CHARGE DISTANCE  (  0.1052329 for atom1 spin 1) 
0.0370176
:DIS  :  CHARGE DISTANCE  (  0.0075476 for atom1 spin 1) 
0.0021153
:DIS  :  CHARGE DISTANCE  (  0.0848258 for atom1 spin 1) 
0.0300654
:DIS  :  CHARGE DISTANCE  (  0.0018758 for atom1 spin 1) 
0.0007564
:DIS  :  CHARGE DISTANCE  (  0.0008796 for atom3 spin 1) 
0.0006306
:DIS  :  CHARGE DISTANCE  (  0.0013281 for atom3 spin 1) 
0.0008331


after iteration 3, the semicore error is appeared for rkm=7.
--

Nobody knows what you were sending. Is this from the RKM=6 calculation ?

You have done a scf with RKmax=6.   This should be saved.

Then you have an empty scffile, and you should increase RKmax to 7 and 
run the scf.

If the error occurs after iteration 3, we expect to see exactly 3 lines.

???
Did you ever save the rkm6 results ?

restore them in a new directory, increase rkmax and then run_lapw.
When it crashes, show us :dis.

--
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300
Email: peter.bl...@tuwien.ac.atWIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at
-
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] semicore band ranges too large error: for MoSi2N4

[Laurence Marks]

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 & case.in2 or are you using the
defaults?
6. Did you do "grep :NEC *scf" to check that you have the number of
electrons about right?

--
Emeritus Professor Laurence Marks (Laurie)
Northwestern University
www.numis.northwestern.edu
https://scholar.google.com/citations?user=zmHhI9gJ=en
"Research is to see what everybody else has seen, and to think what nobody
else has thought" Albert Szent-Györgyi

On Tue, Nov 14, 2023, 03:18 hajar.nejatipoor--- via Wien <
wien@zeus.theochem.tuwien.ac.at> wrote:

> Yes, I use WIEN2k_23.2
> Let 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 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' - 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 tried a normal scf with RKm=7, from the beginning, at a different
> > directory, but nothing was changed. Just, crashing LAPW2 is postponed in
> > some more cycles.
> > On Sunday, November 12, 2023 at 08:42:25 PM GMT+3:30, Peter Blaha
> >  wrote:
> >
> >
> > 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,  
> >
> >
> > Am 12.11.2023 um 07:30 schrieb hajar.nejatipoor--- via Wien:
> >  > Dear Dr. Blaha
> >  > The 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 radius 1.68, there
> >  > is a huge charge leak out, I set the muffin tin raddii as:
> >  >
> >  >1  42.0  2.12  2.2
> >  >2  14.0  1.68  2.1
> >  >3  7.0  1.61  1.2
> >  >4  7.0  1.60  1.2
> >  >
> >  > On Saturday, November 11, 2023 at 10:43:42 PM GMT+3:30, Peter Blaha
> >  > mailto:peter.bl...@tuwien.ac.at>> wrote:
> >  >
> >  >
> >  > 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 remove the LO for N-s
> >  > (only keep:
> >  >0.302  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
> >  > APW/LAPW)
> >  >0  -1.070.0010 CONT 1
> >  >10.300. CONT 1
> >  > for the N atoms (maybe use instead a HDLO).
> >  >
> >  >
> >  > Am 11.11.2023 um 19:26 schrieb hajar.nejatipoor--- via Wien:
> >  >  > MoSi2N4
> >  >  > H   LATTICE,NONEQUIV.ATOMS:  4 187_P-6m2
> >  >  > MODE OF CALC=RELA unit=bohr
> >  >  >5.502431  5.502431 38.534460 90.00 90.00120.00
> >  >  > ATOM  -1: X=0. Y=0. Z=0.
> >  >  >MULT= 1  ISPLIT= 4
> >  >  > Mo1NPT=  781  R0=0.1000 RMT=2.2000   Z: 42.000
> >  >  > LOCAL ROT MATRIX:1.000 0.000 0.000
> >  >  >   0.000 1.000 0.000
> >  >  >   0.000 0.000 1.000
> >  >  > ATOM  -2: X=0. Y=0.3334 Z=0.14710600
> >  >  >MULT= 2  ISPLIT= 4
> >  >  >-2: X=0.6668 Y=0.3334 Z=0.85289400
> >  >  > Si1NPT=  781  R0=0.0001 RMT=2.1000   Z: 14.000
> >  >  > LOCAL ROT MATRIX:1.000 0.000 0.000
> >  >  >   0.000 1.000 0.000
> >  >  >   0.000 0.000 1.000
> >  >  > ATOM  -3: X=0. Y=0.6667 Z=0.82807700
> >  >  >MULT= 2  ISPLIT= 4
> >  >  >-3: X=0.3334 Y=0.6667 Z=0.17192300
> >  >  > N 1NPT=  781  R0=0.0001 RMT=1.2000   Z:  7.000
> >  >  > LOCAL ROT 

Re: [Wien] semicore band ranges too large error: for MoSi2N4

[Gavin Abo]

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 if preferred instead.


I think I got a WIEN2k 23.2 patch file at [1] for those reported so far 
except for fixes to the ELF [2] and NMR [3] that looked planned for a 
future WIEN2k release.


[1] https://github.com/gsabo/WIEN2k-Patches/tree/master/23.2
[2] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg22070.html
[3] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg22468.html


Kind Regards,

Gavin
WIEN2k user

On 11/14/2023 1:00 AM, 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 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' - 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 tried a normal scf with RKm=7, from the beginning, at a different 
directory, but nothing was changed. Just, crashing LAPW2 is postponed 
in some more cycles.
On Sunday, November 12, 2023 at 08:42:25 PM GMT+3:30, Peter Blaha 
 wrote:



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,  


Am 12.11.2023 um 07:30 schrieb hajar.nejatipoor--- via Wien:
 > Dear Dr. Blaha
 > The 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 radius 1.68, 
there

 > is a huge charge leak out, I set the muffin tin raddii as:
 >
 >    1  42.0  2.12  2.2
 >    2  14.0  1.68  2.1
 >    3  7.0  1.61  1.2
 >    4  7.0  1.60  1.2
 >
 > On Saturday, November 11, 2023 at 10:43:42 PM GMT+3:30, Peter Blaha
 > mailto:peter.bl...@tuwien.ac.at>> wrote:
 >
 >
 > 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 remove the LO for N-s
 > (only keep:
 >    0.30    2  0      (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
 > APW/LAPW)
 >    0  -1.07    0.0010 CONT 1
 >    1    0.30    0. CONT 1
 > for the N atoms (maybe use instead a HDLO).
 >
 >
 > Am 11.11.2023 um 19:26 schrieb hajar.nejatipoor--- via Wien:
 >  > MoSi2N4
 >  > H   LATTICE,NONEQUIV.ATOMS:  4 187_P-6m2
 >  > MODE OF CALC=RELA unit=bohr
 >  >    5.502431  5.502431 38.534460 90.00 90.00120.00
 >  > ATOM  -1: X=0. Y=0. Z=0.
 >  >            MULT= 1          ISPLIT= 4
 >  > Mo1        NPT=  781  R0=0.1000 RMT=    2.2000  Z: 42.000
 >  > LOCAL ROT MATRIX:    1.000 0.000 0.000
 >  >                       0.000 1.000 0.000
 >  >                       0.000 0.000 1.000
 >  > ATOM  -2: X=0. Y=0.3334 Z=0.14710600
 >  >            MULT= 2          ISPLIT= 4
 >  >        -2: X=0.6668 Y=0.3334 Z=0.85289400
 >  > Si1        NPT=  781  R0=0.0001 RMT=    2.1000  Z: 14.000
 >  > LOCAL ROT MATRIX:    1.000 0.000 0.000
 >  >                       0.000 1.000 0.000
 >  >                       0.000 0.000 1.000
 >  > ATOM  -3: X=0. Y=0.6667 Z=0.82807700
 >  >            MULT= 2          ISPLIT= 4
 >  >        -3: X=0.3334 Y=0.6667 Z=0.17192300
 >  > N 1        NPT=  781  R0=0.0001 RMT=    1.2000  Z:  7.000
 >  > LOCAL ROT MATRIX:    1.000 0.000 0.000
 >  >                       0.000 1.000 0.000
 >  >                       0.000 0.000 1.000
 >  > ATOM  -4: X=0. Y=0.3334 Z=0.93855400
 >  >            MULT= 2          ISPLIT= 4
 >  >        -4: X=0.6668 Y=0.3334 Z=0.06144600
 >  > N 2        NPT=  781  R0=0.0001 RMT=    1.2000  Z:  7.000
 >  > LOCAL ROT MATRIX:    1.000 0.000 0.000
 >  >                       0.000 1.000 0.000
 >  >                       0.000 0.000 1.000
 >
 > --
 > 
--

 > Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
 > 

Re: [Wien] semicore band ranges too large error: for MoSi2N4

[Peter Blaha]

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 RKMAX. RKmax has nothing to do with 
finding E-parameters.


Does it happen immediately after increasing RKmax ? or after a few 
iterations. How is :DIS in this case ?


Am 14.11.2023 um 10:17 schrieb hajar.nejatipoor--- via Wien:

Yes, I use WIEN2k_23.2
Let 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 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' - 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 tried a normal scf with RKm=7, from the beginning, at a different
 > directory, but nothing was changed. Just, crashing LAPW2 is
postponed in
 > some more cycles.
 > On Sunday, November 12, 2023 at 08:42:25 PM GMT+3:30, Peter Blaha
 > mailto:peter.bl...@tuwien.ac.at>> wrote:
 >
 >
 > 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,  
 >
 >
 > Am 12.11.2023 um 07:30 schrieb hajar.nejatipoor--- via Wien:
 >  > Dear Dr. Blaha
 >  > The 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 radius
1.68, there
 >  > is a huge charge leak out, I set the muffin tin raddii as:
 >  >
 >  >    1  42.0  2.12  2.2
 >  >    2  14.0  1.68  2.1
 >  >    3  7.0  1.61  1.2
 >  >    4  7.0  1.60  1.2
 >  >
 >  > On Saturday, November 11, 2023 at 10:43:42 PM GMT+3:30, Peter
Blaha
 >  > mailto:peter.bl...@tuwien.ac.at>
> wrote:
 >  >
 >  >
 >  > 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 remove the LO
for N-s
 >  > (only keep:
 >  >    0.30    2  0      (GLOBAL E-PARAMETER WITH n OTHER CHOICES,
global
 >  > APW/LAPW)
 >  >    0  -1.07    0.0010 CONT 1
 >  >    1    0.30    0. CONT 1
 >  > for the N atoms (maybe use instead a HDLO).
 >  >
 >  >
 >  > Am 11.11.2023 um 19:26 schrieb hajar.nejatipoor--- via Wien:
 >  >  > MoSi2N4
 >  >  > H   LATTICE,NONEQUIV.ATOMS:  4 187_P-6m2
 >  >  > MODE OF CALC=RELA unit=bohr
 >  >  >    5.502431  5.502431 38.534460 90.00 90.00120.00
 >  >  > ATOM  -1: X=0. Y=0. Z=0.
 >  >  >            MULT= 1          ISPLIT= 4
 >  >  > Mo1        NPT=  781  R0=0.1000 RMT=    2.2000   Z: 42.000
 >  >  > LOCAL ROT MATRIX:    1.000 0.000 0.000
 >  >  >                       0.000 1.000 0.000
 >  >  >                       0.000 0.000 1.000
 >  >  > ATOM  -2: X=0. Y=0.3334 Z=0.14710600
 >  >  >            MULT= 2          ISPLIT= 4
 >  >  >        -2: X=0.6668 Y=0.3334 Z=0.85289400
 >  >  > Si1        NPT=  781  R0=0.0001 RMT=    2.1000   Z: 14.000
 >  >  > LOCAL ROT MATRIX:    1.000 0.000 0.000
 >  >  >                       0.000 1.000 0.000
 >  >  >                       0.000 0.000 1.000
 >  >  > ATOM  -3: X=0. Y=0.6667 Z=0.82807700
 >  >  >            MULT= 2          ISPLIT= 4
 >  >  >        -3: X=0.3334 Y=0.6667 Z=0.17192300
 >  >  

Re: [Wien] semicore band ranges too large error: for MoSi2N4

[hajar.nejatipoor--- via Wien]

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 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' - 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 tried a normal scf with RKm=7, from the beginning, at a different 
> directory, but nothing was changed. Just, crashing LAPW2 is postponed in 
> some more cycles.
> On Sunday, November 12, 2023 at 08:42:25 PM GMT+3:30, Peter Blaha 
>  wrote:
> 
> 
> 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,  
> 
> 
> Am 12.11.2023 um 07:30 schrieb hajar.nejatipoor--- via Wien:
>  > Dear Dr. Blaha
>  > The 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 radius 1.68, there
>  > is a huge charge leak out, I set the muffin tin raddii as:
>  >
>  >    1  42.0  2.12  2.2
>  >    2  14.0  1.68  2.1
>  >    3  7.0  1.61  1.2
>  >    4  7.0  1.60  1.2
>  >
>  > On Saturday, November 11, 2023 at 10:43:42 PM GMT+3:30, Peter Blaha
>  > mailto:peter.bl...@tuwien.ac.at>> wrote:
>  >
>  >
>  > 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 remove the LO for N-s
>  > (only keep:
>  >    0.30    2  0      (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
>  > APW/LAPW)
>  >    0  -1.07    0.0010 CONT 1
>  >    1    0.30    0. CONT 1
>  > for the N atoms (maybe use instead a HDLO).
>  >
>  >
>  > Am 11.11.2023 um 19:26 schrieb hajar.nejatipoor--- via Wien:
>  >  > MoSi2N4
>  >  > H   LATTICE,NONEQUIV.ATOMS:  4 187_P-6m2
>  >  > MODE OF CALC=RELA unit=bohr
>  >  >    5.502431  5.502431 38.534460 90.00 90.00120.00
>  >  > ATOM  -1: X=0. Y=0. Z=0.
>  >  >            MULT= 1          ISPLIT= 4
>  >  > Mo1        NPT=  781  R0=0.1000 RMT=    2.2000   Z: 42.000
>  >  > LOCAL ROT MATRIX:    1.000 0.000 0.000
>  >  >                       0.000 1.000 0.000
>  >  >                       0.000 0.000 1.000
>  >  > ATOM  -2: X=0. Y=0.3334 Z=0.14710600
>  >  >            MULT= 2          ISPLIT= 4
>  >  >        -2: X=0.6668 Y=0.3334 Z=0.85289400
>  >  > Si1        NPT=  781  R0=0.0001 RMT=    2.1000   Z: 14.000
>  >  > LOCAL ROT MATRIX:    1.000 0.000 0.000
>  >  >                       0.000 1.000 0.000
>  >  >                       0.000 0.000 1.000
>  >  > ATOM  -3: X=0. Y=0.6667 Z=0.82807700
>  >  >            MULT= 2          ISPLIT= 4
>  >  >        -3: X=0.3334 Y=0.6667 Z=0.17192300
>  >  > N 1        NPT=  781  R0=0.0001 RMT=    1.2000   Z:  7.000
>  >  > LOCAL ROT MATRIX:    1.000 0.000 0.000
>  >  >                       0.000 1.000 0.000
>  >  >                       0.000 0.000 1.000
>  >  > ATOM  -4: X=0. Y=0.3334 Z=0.93855400
>  >  >            MULT= 2          ISPLIT= 4
>  >  >        -4: X=0.6668 Y=0.3334 Z=0.06144600
>  >  > N 2        NPT=  781  R0=0.0001 RMT=    1.2000   Z:  7.000
>  >  > LOCAL ROT MATRIX:    1.000 0.000 0.000
>  >  >                       0.000 1.000 0.000
>  >  >                       0.000 0.000 1.000
>  >
>  > --
>  > 
> --
>  > Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
>  > Phone: +43-1-58801-165300
>  > Email: peter.bl...@tuwien.ac.at  
> 
>  > WIEN2k: http://www.wien2k.at  
> >
>  > WWW: http://www.imc.tuwien.ac.at  
> >
>  >
>  > 

Re: [Wien] semicore band ranges too large error: for MoSi2N4

[Peter Blaha]

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' - 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 tried a normal scf with RKm=7, from the beginning, at a different 
directory, but nothing was changed. Just, crashing LAPW2 is postponed in 
some more cycles.
On Sunday, November 12, 2023 at 08:42:25 PM GMT+3:30, Peter Blaha 
 wrote:



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,  


Am 12.11.2023 um 07:30 schrieb hajar.nejatipoor--- via Wien:
 > Dear Dr. Blaha
 > The 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 radius 1.68, there
 > is a huge charge leak out, I set the muffin tin raddii as:
 >
 >    1  42.0  2.12  2.2
 >    2  14.0  1.68  2.1
 >    3  7.0  1.61  1.2
 >    4  7.0  1.60  1.2
 >
 > On Saturday, November 11, 2023 at 10:43:42 PM GMT+3:30, Peter Blaha
 > mailto:peter.bl...@tuwien.ac.at>> wrote:
 >
 >
 > 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 remove the LO for N-s
 > (only keep:
 >    0.30    2  0      (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
 > APW/LAPW)
 >    0  -1.07    0.0010 CONT 1
 >    1    0.30    0. CONT 1
 > for the N atoms (maybe use instead a HDLO).
 >
 >
 > Am 11.11.2023 um 19:26 schrieb hajar.nejatipoor--- via Wien:
 >  > MoSi2N4
 >  > H   LATTICE,NONEQUIV.ATOMS:  4 187_P-6m2
 >  > MODE OF CALC=RELA unit=bohr
 >  >    5.502431  5.502431 38.534460 90.00 90.00120.00
 >  > ATOM  -1: X=0. Y=0. Z=0.
 >  >            MULT= 1          ISPLIT= 4
 >  > Mo1        NPT=  781  R0=0.1000 RMT=    2.2000   Z: 42.000
 >  > LOCAL ROT MATRIX:    1.000 0.000 0.000
 >  >                       0.000 1.000 0.000
 >  >                       0.000 0.000 1.000
 >  > ATOM  -2: X=0. Y=0.3334 Z=0.14710600
 >  >            MULT= 2          ISPLIT= 4
 >  >        -2: X=0.6668 Y=0.3334 Z=0.85289400
 >  > Si1        NPT=  781  R0=0.0001 RMT=    2.1000   Z: 14.000
 >  > LOCAL ROT MATRIX:    1.000 0.000 0.000
 >  >                       0.000 1.000 0.000
 >  >                       0.000 0.000 1.000
 >  > ATOM  -3: X=0. Y=0.6667 Z=0.82807700
 >  >            MULT= 2          ISPLIT= 4
 >  >        -3: X=0.3334 Y=0.6667 Z=0.17192300
 >  > N 1        NPT=  781  R0=0.0001 RMT=    1.2000   Z:  7.000
 >  > LOCAL ROT MATRIX:    1.000 0.000 0.000
 >  >                       0.000 1.000 0.000
 >  >                       0.000 0.000 1.000
 >  > ATOM  -4: X=0. Y=0.3334 Z=0.93855400
 >  >            MULT= 2          ISPLIT= 4
 >  >        -4: X=0.6668 Y=0.3334 Z=0.06144600
 >  > N 2        NPT=  781  R0=0.0001 RMT=    1.2000   Z:  7.000
 >  > LOCAL ROT MATRIX:    1.000 0.000 0.000
 >  >                       0.000 1.000 0.000
 >  >                       0.000 0.000 1.000
 >
 > --
 > 
--

 > Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
 > Phone: +43-1-58801-165300
 > Email: peter.bl...@tuwien.ac.at  

 > WIEN2k: http://www.wien2k.at  
>
 > WWW: http://www.imc.tuwien.ac.at  
>

 >
 > -
 > ___
 > Wien mailing list
 > Wien@zeus.theochem.tuwien.ac.at 
 

 > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien 

 >