Re: [Wien] Struct file rounding errors from the output of VASP. Unable to solve after repeated attempts.

[fabien . tran]

Are you answering y to the question "Should x=0.6669 ..."?

On 04.05.2024 12:12, Pranjal Nandi wrote:

Dear Fabien,

Thank you.

But I am getting the following error when I am using x xyz2struct

x xyz2struct
 Hexagonal lattice detected. The possible rounding errors are removed.
Should x=0.6669 for atom 3 be exactly 2/3? (y/n)
At line 299 of file xyz2struct.f (unit = 6, file = 'stdout')
Fortran runtime error: Cannot read from file opened for WRITE

Error termination. Backtrace:
#0  0xf44e6223960 in ???
#1  0xf44e62244d9 in ???
#2  0xf44e622510f in ???
#3  0xf44e647b53c in ???
#4  0x5a790e1d7b79 in ???
#5  0x5a790e1d522e in ???
#6  0xf44e5e29d8f in __libc_start_call_main
at ../sysdeps/nptl/libc_start_call_main.h:58
#7  0xf44e5e29e3f in __libc_start_main_impl
at ../csu/libc-start.c:392
#8  0x5a790e1d5264 in ???
#9  0x in ???

Could you kindly suggest what can be the issue here?

With warm regards,
Pranjal

-Original Message-
From: Wien  On Behalf Of
fabien.t...@vasp.at
Sent: Saturday, May 4, 2024 11:50 AM
To: A Mailing list for WIEN2k users 
Subject: Re: [Wien] Struct file rounding errors from the output of
VASP. Unable to solve after repeated attempts.

Hi,

You can use the program xyz2struct:
mv Contcar_BaTiO3_relaxed.vasp case.xyz
x xyz2struct
mv xyz2struct.struct case.struct

Then you have to execute init_lapw in step-by-step mode (i.e., with -m
flag for recent WIEN2k versions). At the end you should get the same
struct file as the one that is attached.


On 04.05.2024 11:01, Pranjal Nandi wrote:

Dear Community,

I have a hexagonal lattice which I relaxed in VASP and then converted
to cif and then cif2struct.

Then I also changed the coordinates to fraction such as 2/3 and 1/3.

However, still then I am receiving this warnings and suggestions from
sgroup and x symmetry.

SPACE GROUP DOES NOT CONTAIN INVERSION

Angle Gamma is exactly 120. degrees.

If this is supposed to be a hexagonal lattice, STOP and put  H lattice
type

alpha(3) .gt. 91.0; reset to 90.1

0.000u 0.003s 0:00.00 0.0% 0+0k 0+120io 0pf+0w

SPACE GROUP DOES NOT CONTAIN INVERSION

Angle Gamma is exactly 120. degrees.

If this is supposed to be a hexagonal lattice, STOP and put  H lattice
type

alpha(3) .gt. 91.0; reset to 90.1

0.000u 0.003s 0:00.00 0.0% 0+0k 0+120io 0pf+0w

Could someone be kind to explain what parameters in the struct file I
need to change so that the rounding off errors doesn’t happen and by
doing x symmetry and sgroup the symmetry is detected as H?

I am unable to intrepret the issue.

Requesting your assistance.

With warm regards,

Pranjal

Aquest missatge, i els fitxers adjunts que hi pugui haver, pot
contenir informació confidencial o protegida legalment i s’adreça
exclusivament a la persona o entitat destinatària. Si no consteu com a
destinatari final o no teniu l’encàrrec de rebre’l, no esteu
autoritzat a llegir-lo, retenir-lo, modificar-lo, distribuir-lo,
copiar-lo ni a revelar-ne el contingut. Si l’heu rebut per error,
informeu-ne el remitent i elimineu del sistema tant el missatge com
els fitxers adjunts que hi pugui haver.

Este mensaje, y los ficheros adjuntos que pueda incluir, puede
contener información confidencial o legalmente protegida y está
exclusivamente dirigido a la persona o entidad destinataria. Si usted
no consta como destinatario final ni es la persona encargada de
recibirlo, no está autorizado a leerlo, retenerlo, modificarlo,
distribuirlo o copiarlo, ni a revelar su contenido. Si lo ha recibido
por error, informe de ello al remitente y elimine del sistema tanto el
mensaje como los ficheros adjuntos que pueda contener.

This email message and any attachments it carries may contain
confidential or legally protected material and are intended solely for
the individual or organization to whom they are addressed. If you are
not the intended recipient of this message or the person responsible
for processing it, then you are not authorized to read, save, modify,
send, copy or disclose any part of it. If you have received the
message by mistake, please inform the sender of this and eliminate the
message and any attachments it carries from your account.
___
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



Aquest missatge, i els fitxers adjunts que hi pugui haver, pot
contenir informació confidencial o protegida legalment i s’adreça
exclusivament a la persona o entitat destinatària. Si no consteu com a
destinatari final o no teniu l’encàrrec de rebre’l, no esteu
autoritzat a llegir-lo, retenir-lo, modificar-lo, distribuir-lo,
copiar-lo ni a revelar-ne el contingut. Si l’heu rebut per error,
informeu-ne el remitent i elimineu del sistema tant el missatge com
els fitxers adjunts que hi pugui haver.

Este mensaje, y los ficheros adjuntos que pueda 

Re: [Wien] Struct file rounding errors from the output of VASP. Unable to solve after repeated attempts.

[fabien . tran]

Hi,

You can use the program xyz2struct:
mv Contcar_BaTiO3_relaxed.vasp case.xyz
x xyz2struct
mv xyz2struct.struct case.struct

Then you have to execute init_lapw in step-by-step mode (i.e., with -m 
flag for recent WIEN2k versions). At the end you should get the same 
struct file as the one that is attached.



On 04.05.2024 11:01, Pranjal Nandi wrote:

Dear Community,

I have a hexagonal lattice which I relaxed in VASP and then converted
to cif and then cif2struct.

Then I also changed the coordinates to fraction such as 2/3 and 1/3.

However, still then I am receiving this warnings and suggestions from
sgroup and x symmetry.

SPACE GROUP DOES NOT CONTAIN INVERSION

Angle Gamma is exactly 120. degrees.

If this is supposed to be a hexagonal lattice, STOP and put  H
lattice type

alpha(3) .gt. 91.0; reset to 90.1

0.000u 0.003s 0:00.00 0.0% 0+0k 0+120io 0pf+0w

SPACE GROUP DOES NOT CONTAIN INVERSION

Angle Gamma is exactly 120. degrees.

If this is supposed to be a hexagonal lattice, STOP and put  H
lattice type

alpha(3) .gt. 91.0; reset to 90.1

0.000u 0.003s 0:00.00 0.0% 0+0k 0+120io 0pf+0w

Could someone be kind to explain what parameters in the struct file I
need to change so that the rounding off errors doesn’t happen and by
doing x symmetry and sgroup the symmetry is detected as H?

I am unable to intrepret the issue.

Requesting your assistance.

With warm regards,

Pranjal

Aquest missatge, i els fitxers adjunts que hi pugui haver, pot
contenir informació confidencial o protegida legalment i s’adreça
exclusivament a la persona o entitat destinatària. Si no consteu com
a destinatari final o no teniu l’encàrrec de rebre’l, no esteu
autoritzat a llegir-lo, retenir-lo, modificar-lo, distribuir-lo,
copiar-lo ni a revelar-ne el contingut. Si l’heu rebut per error,
informeu-ne el remitent i elimineu del sistema tant el missatge com
els fitxers adjunts que hi pugui haver.

Este mensaje, y los ficheros adjuntos que pueda incluir, puede
contener información confidencial o legalmente protegida y está
exclusivamente dirigido a la persona o entidad destinataria. Si usted
no consta como destinatario final ni es la persona encargada de
recibirlo, no está autorizado a leerlo, retenerlo, modificarlo,
distribuirlo o copiarlo, ni a revelar su contenido. Si lo ha recibido
por error, informe de ello al remitente y elimine del sistema tanto el
mensaje como los ficheros adjuntos que pueda contener.

This email message and any attachments it carries may contain
confidential or legally protected material and are intended solely for
the individual or organization to whom they are addressed. If you are
not the intended recipient of this message or the person responsible
for processing it, then you are not authorized to read, save, modify,
send, copy or disclose any part of it. If you have received the
message by mistake, please inform the sender of this and eliminate the
message and any attachments it carries from your account.
___
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.htmlTITLE  
H9 
 RELA  
 10.728063 10.728063 26.579464 90.00 90.00120.00
ATOM  -1: X=0. Y=0. Z=0.00437000
  MULT= 2  ISPLIT= 4
  -1: X=0. Y=0. Z=0.50437000
Ti1NPT=  781  R0=0.5000 RMT=1.8800   Z: 22.0   
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.6667 Y=0. Z=0.3377
  MULT= 2  ISPLIT= 4
  -2: X=0.6667 Y=0. Z=0.8377
Ti2NPT=  781  R0=0.5000 RMT=1.8800   Z: 22.0   
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.67104000
  MULT= 2  ISPLIT= 4
  -3: X=0. Y=0.6667 Z=0.17104000
Ti3NPT=  781  R0=0.5000 RMT=1.8800   Z: 22.0   
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.16245000 Y=0.32981000 Z=0.07528000
  MULT= 6  ISPLIT= 8
  -4: X=0.67019000 Y=0.83264000 Z=0.07528000
  -4: X=0.16736000 Y=0.83755000 Z=0.07528000
  -4: X=0.67019000 Y=0.83755000 Z=0.57528000
  -4: X=0.16736000 Y=0.32981000 Z=0.57528000
  -4: X=0.16245000 Y=0.83264000 Z=0.57528000
O 4NPT=  781  R0=0.0001 R

Re: [Wien] Error in HF calculation

[fabien . tran]

The file vectorhfdn_old is probably corrupted. Delete it and restart the 
calculation.


On 08.02.2024 05:19, shamik chakrabarti wrote:

Dear Wien2k users,

I have started to run -hf for a 16 atom cell. The
simulation was running smoothly while at some time, power failure
occurred & the server got stopped. After the recovery, while I started
to run -hf again, the following error occurs (as shown in STDOUT)
STOP  LAPW0 END
STOP  LAPW0 END
STOP  LAPW1 END
STOP  LAPW1 END
STOP  LAPW2 END
STOP  LAPW2 END
STOP  CORE  END
STOP  CORE  END
STOP  HFEND
At line 151 of file read_cnk_tmp_.F (unit = 11, file =
'Li10C3B3_771.vectorhfdn_old')
Fortran runtime error: End of file

Error termination. Backtrace:
#0  0x1493c9520d11 in ???
#1  0x1493c9521859 in ???
#2  0x1493c952253f in ???
#3  0x1493c9765c4b in ???
#4  0x1493c97666ef in ???
#5  0x1493c97667d4 in ???
#6  0x1493c9768c3a in ???
#7  0x1493c9769514 in ???
#8  0x55a21007b76f in ???
#9  0x55a210073b38 in ???
#10  0x55a20ffac04e in ???
#11  0x1493c919a082 in __libc_start_main
at ../csu/libc-start.c:308
#12  0x55a20ffac0dd in ???
#13  0x in ???


  stop error


Any response in this regard is highly appreciated.

with regards,. --

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India
___
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

Re: [Wien] Terminal closes automatically and the job terminates.

[fabien . tran]

With bash this should be
run_lapw ... >STDOUT 2>&1 &

On 13.09.2023 19:47, Peter Blaha wrote:

I'm using a tcsh. There you would detach a job from the terminal
using:

run_lapw ... >& STDOUT &

The job will continue, even if the terminal closes. All output and
errors are directed into a file called STDOUT, which you can view
whenever you want.

There must be something similar for the bash shell.

PS: As was mentioned before: Why are you using 500 k-points for a cell
with 300 atoms ??

There is a good reason to upgrade to wien2k_23.2. The new init_lapw
would automatically choose a reasonable number of k-points. Depending
on the selected precision (-prec 0-3(n)) eventually ONE k-point is
enough for the scf cycle.

Also the RKMAX would be set properly, you probably run with a much too
large value.

Am 13.09.2023 um 18:58 schrieb Pranjal Nandi:


Dear Member,

Hello.

My WIEN2k version is 21.1

I am running a simulation on a supercell containing about 300 atoms
which I expect to run for days (2 days maybe).  Using 500 K points.

However, even if I use the nohup command, the terminal automatically
closes after an hour or so and the job also terminates abruptly.

May I please know what could be the possible reasons behind it? In
case additional information is needed, please let me know.

Thank you.

With warm regards,

Pranjal

Aquest missatge, i els fitxers adjunts que hi pugui haver, pot
contenir informació confidencial o protegida legalment i
s’adreça exclusivament a la persona o entitat destinatària. Si
no consteu com a destinatari final o no teniu l’encàrrec de
rebre’l, no esteu autoritzat a llegir-lo, retenir-lo,
modificar-lo, distribuir-lo, copiar-lo ni a revelar-ne el contingut.
Si l’heu rebut per error, informeu-ne el remitent i elimineu del
sistema tant el missatge com els fitxers adjunts que hi pugui haver.

Este mensaje, y los ficheros adjuntos que pueda incluir, puede
contener información confidencial o legalmente protegida y está
exclusivamente dirigido a la persona o entidad destinataria. Si
usted no consta como destinatario final ni es la persona encargada
de recibirlo, no está autorizado a leerlo, retenerlo, modificarlo,
distribuirlo o copiarlo, ni a revelar su contenido. Si lo ha
recibido por error, informe de ello al remitente y elimine del
sistema tanto el mensaje como los ficheros adjuntos que pueda
contener.

This email message and any attachments it carries may contain
confidential or legally protected material and are intended solely
for the individual or organization to whom they are addressed. If
you are not the intended recipient of this message or the person
responsible for processing it, then you are not authorized to read,
save, modify, send, copy or disclose any part of it. If you have
received the message by mistake, please inform the sender of this
and eliminate the message and any attachments it carries from your
account.

___
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-158801165300
Email: peter.bl...@tuwien.ac.at
WWW:   http://www.imc.tuwien.ac.at  WIEN2k: http://www.wien2k.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

Re: [Wien] Optimized lattice constants using pbe+U

[fabien . tran]

As Peter mentioned, U is applied only inside the atomic spheres. In 
general, the details of the implementation of DFT+U depends on the basis 
set, which can lead to disagreements between codes that are more 
important than for plain LDA or GGA (see 
https://doi.org/10.1063/1.4945608).


You wrote that you used the default k-mesh and gmax. You should also 
test these parameters.



On 25.08.2023 18:48, Peter Blaha wrote:

Hard to say without repeating the calculations, but:

a) I see nothing wrong in your calculation setups/procedure
b) I've seen previously VERY wrong PBE+U results using VASP in other
cases. VASP potentials have been optimized for PBE (and probably for
HSE), and those results are usually ok, but I don't know about PBE+U.
c) At the time when the rutile/anatase stability problem came up, I
let a student try if PBE+U could fix it. It did not do it. But this is
long time ago.

Maybe repeat one U value with a significantly larger RMT for Ti. Note
that the Hubbard-U is applied only within the spheres in WIEN2k and
since the Ti-3d states are not too localized, there might be an
effect.

Am 24.08.2023 um 17:55 schrieb Park, Ken:

Dear Wien2k experts,

I have been studying the effect of the Hubbard U on various phases of 
TiO2 using wien2k 23.2. I have observed that some calculated 
properties are different from those reported in literature (mostly 
with pseudopotential) and would like to get your suggestions to see if 
I have made a mistake.


For rutile TiO2 using pbe, my optimized lattice constants are a=4.648 
Å and c=2.966Å, which are close to the published result of 4.650 and 
2.968 [1]. However, after I added U= 6eV and ran the optimization, I 
obtained a=4.655 Å and c=3.000Å, in contrast to a=4.687Å and c=3.042Å 
for U=5 eV in [1].


[1] 
https://pubs.aip.org/aip/jcp/article/135/5/054503/190719/DFT-U-calculations-of-crystal-lattice-electronic 



So I performed a systemic study using U=3, 5, 8, 10 eV as in [1] and 
obtained the following:


U=3    a=4.650    c=2.985    vs U=3
   a=4.671    c=3.012 [1]


U=5    a=4.649    c=2.995     vs 
U=5   a=4.687    c=3.042 [1]


U=8    a=4.652    c=3.011    vs 
U=8   a=4.709    c=3.081 [1]


U=10 a=4.655    c=3.021    vs 
U=10    a=4.725    c=3.108 [1]


The lattice constant a is nearly constant or expanded very little 
despite the increasing U whereas the constant c shows a similar 
increase albeit by smaller amount. In rutile, c is the direction of 
the Ti-Ti short chain.


I have checked the band gaps and they are comparable with the reported 
results.


U=3    2.24 eV vs U=3      2.15 eV [1]

U=5    2.42 eV vs U=5   2.3 eV  
[1]


U=8    2.72 eV vs U=8   2.7 eV [1]

U=10 2.98 eV vs U=10    2.92 eV [1]

For your information, I have copied the input files case.inorb and 
case.indm and the top portion of the structure file.


   1  1  0 nmod, natorb, ipr

PRATT  1.0    BROYD/PRATT, mixing

   1 1 2  iatom nlorb, lorb

   1  nsic 0..AMF, 1..SIC, 2..HFM

    0.44 0.00    U J (Ry)   Note: you can also use U_eff = U-J and 
J=0


-12.  Emin cutoff energy

1   number of atoms for which density matrix is 
calculated


1  1  2  index of 1st atom, number of L's, L1

0 0   r-index, (l,s)index

TiO2

P    2

  RELA

   8.788126  8.788126  5.669865 90.00 90.00 90.00

ATOM  -1: X=0. Y=0. Z=0.

   MULT= 2  ISPLIT= 8

   -1: X=0.5000 Y=0.5000 Z=0.5000

Ti     NPT=  781  R0=0.5000 RMT=    1.7800   Z:  22.0

  0.7071068 0.7071068 0.000

     -0.7071068 0.7071068 0.000

  0.000 0.000 1.000

ATOM  -2: X=0.30509790 Y=0.30509790 Z=0.

   MULT= 4  ISPLIT= 8

   -2: X=0.69490210 Y=0.69490210 Z=0.

   -2: X=0.19490210 Y=0.80509790 Z=0.5000

   -2: X=0.80509790 Y=0.19490210 Z=0.5000

O  NPT=  781  R0=0.0001 RMT=    1.6100   Z:   8.0

  0.000-0.7071068 0.7071068

  0.000 0.7071068 0.7071068

     -1.000 0.000 0.000

   16  NUMBER OF SYMMETRY OPERATIONS

I optimized the structure with ‘runsp_lapw -p -orb -min -ec 0.1 
-cc 0.0001 -fc 1’ (or smaller fc) using rkmax 9 (or 10 to check for 
convergence) and default values such as k-mesh and gmax. I a

Re: [Wien] Clean_lapw before increasing number of k points in HSE06 calculation

[fabien . tran]

clean_lapw should not be executed if the option -newklist is used for 
the second calculation. Otherwise, yes.


In any case, save_lapw should be executed.

-newklist is recommended to reduce the number of iterations.

On 08.08.2023 18:22, shamik chakrabarti wrote:

Dear Wien2k users,

 I have run a HSE06 calculation with 8 k points.
Now I want to run the same calculation by using 12 k points . Should I
need to run clean_lapw before increasing the number of k points?

 Looking forward to hearing from you.

with regards,

--

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India
___
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

Re: [Wien] Exaggerated lattice parameter c in MoSe2 as obtained using rev-vdW-DF2

[fabien . tran]

Information can be found in
https://doi.org/10.1103/PhysRevMaterials.3.063602
https://doi.org/10.1103/PhysRevMaterials.2.034005
https://doi.org/10.1002/adts.202200055
and in many others.

On 04.08.2023 12:33, shamik chakrabarti wrote:

Dear Wien2k users,

  I have used rev-vdW-DF2 to simulate lattice
parameters of MoSe2. I have obtained well ,matched values for a & b
(3.2826 Ang) where c has been found to be largely overestimated. We
have found c = 14.7804 Ang while the experimental lattice parameter is
12.927 Ang. I have used Rmt*Kmax=9, Gmax=25 & 32 k-points.

Should I need to do a trial & error to see which nlvdw functional is
more appropriate for estimating the c lattice parameter more
accurately than achieved with  rev-vdW-DF2.

Looking forward to your comments & suggestions.

with regards,

--

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India
___
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

Re: [Wien] Exc for Chalcogenides

[fabien . tran]

In general, both SCAN and HSE06 are not supposed to describe properly 
van der Waals interactions. You can probably find a certain number of 
DFT papers on chalcogenides providing more detailed answers.



On 29.07.2023 10:31, shamik chakrabarti wrote:

Dear Wien2k users,

 We know XC_SCAN is a very useful potential for
calculating total energy / electronic structure for chalcogenides.
However, whether HSE06 would be equally useful?
If yes, then how? as we know that HSE06 considers exact exchange but
do not include the Vanderwall Interaction.

Looking forward to your response.

with regards,
--

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India
___
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

Re: [Wien] calculation with lmbj potential

[fabien . tran]

Hi,

In principle, mBJ can not be applied to systems with vacuum or an 
interface (see section "Modified Becke-Johnson potential (mBJ) for band 
gaps" in the user's guide). An alternative is to use lmBJ as you did, 
but convergence was not possible. Another possibility is to use mBJ, but 
by fixing the value of grad(rho)/rho to some (maybe arbitrary) value 
(see explanations in the UG).


How bad is the convergence with PBE+nlvdw? Are you also trying to relax 
the structure? Can you show the input files case.in0 and case.innlvdw?



On 26.07.2023 18:35, Burhan Ahmed wrote:

I check the possible ways of converging my system.

* The system converges with PBE+SO
* The system converges with TB-mBJ+SO

But

* The system doesn’t converges lmBJ+SO
* The system doesn’t converges with PBE+nlvdw

It seems whenever I try to incorporate the van der waals interactions,
the system becomes unstable.

Karnel Type I choose is 1 and the rest default parameters are used.

I am still searching for the possible solution. Hoping for suggestions
from the experts.

Regards

Burhan Ahmed

Research Scholar, AUS

From: Laurence Marks
Sent: Monday, July 24, 2023 3:44 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] calculation with lmbj potential

You should look at the BVS, i.e. "grep Bond *tnn" and compare it to
what you have for bulk. You will see that you surface has bad values,
so will be unstable. You need to do a lot more thinking and analysis
(weeks) to find a chemically reasonable surface.

---
Professor Laurence Marks (Laurie)
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu [1]
"Research is to see what everybody else has seen, and to think what
nobody else has thought" Albert Szent-Györgyi

On Mon, Jul 24, 2023, 05:28 Peter Blaha 
wrote:

Yes, R cells are first converted into H (making it already 3 times
larger than the primitive R cell).

The "accepting repeat atoms at z=0" makes the non-stoichiometry. It
leads to 2 identical surfaces and inversion symmetry (cheaper calc),
but
non-stoiciometry.
It is not always clear what the best model for a surface is. Yours is
Te
terminated, but maybe another termination is more favorable (Bi, or
maybe another Te-layer ?)

Am 24.07.2023 um 10:51 schrieb Burhan Ahmed:

The 6ql slab is created with 1x1x2 supercell with vacuum in Z

direction

and accepting repeat atoms at z=0 (using x supercell program). At

first

the x supercell convert rhombohedral cell into hexagonal and then

from

hexagonal cell I have created the 1x1x2 supercell and then I took

the

structure suggested by sgroup.

Yes sorry for that I have used MSR1a method for the relaxation.

The force convergence is set to 1 Ry.

On Mon, 24 Jul, 2023, 2:06 pm Peter Blaha, 


> wrote:

I'm not sure how you get a non-stoichimetric cell with a

multiplicative

number of unit cells, unless you said you want to repeat the

atom at

z=0.
Of course, without this extra layer, you may not have inversion

and get

2 different surface terminations in one calculation. This is the

usual

problem of slabs.
Also symmetry will be reduced and "multiplicity" errors occur.

But

both,
nn and sgroup create new struct files where this has been

corrected.


If possible, I would also go to a smaller number of layers.


Am 24.07.2023 um 10:13 schrieb Burhan Ahmed:
 > That is very true. I made the slab using the tutorial

available

in the
 > wien2k user manual by executing x-supercell program. What I

found is

 > that the 6ql supercell consist of an extra Te atom. But

whenever

I try
 > to remove this atom I got multiplicity error. Sir, what is

best

possible
 > way of making slab with vacuum or surfaces??
 >
 > Thanks
 >
 > Regards
 >
 > Burhan Ahmed
 >
 > *Research Scholar, AUS *
 >
 > *From: *Laurence Marks >
 > *Sent: *Saturday, July 22, 2023 6:30 PM
 > *To: *A Mailing list for WIEN2k users
 > >
 > *Subject: *Re: [Wien] calculation with lmbj potential
 >
 > Others will probably give you suggestions about converging

mBJ. Some

 > deeper comments.
 >
 > The most common reason that calculations behave badly is user

error.

 > Sometimes this is doing the initialization wrong, often it is
creating
 > an inappropriate model. Just because one can use x supercell

or

related
 > codes to create atomic positions does /not/ make them

sensible.

 >
 > Your slab has a composition Bi12 Te19, i.e. it is Te rich.

You

therefore
 > have a reduced, n-type semiconductor with a small gap (about

0.1eV)

 > which will behave badly. If you look at your BVS you will see
that atom
 > Te7 i

Re: [Wien] calculation with lmbj potential

[fabien . tran]

It seems that this calculation was never going to converge. Try to run 
lmBJ-SOC just after GGA-PBE-SOC (and save_lapw) in the same directory.


Is lmBJ without SOC also showing such problems?

On 24.07.2023 10:04, Burhan Ahmed wrote:

The results from the last 20 iterations (for lmbj calculation)

Analysis of parameter:
:ENE :DIS :GAP
in bi2te3lmbj.scf (showing last 20 / 1 lines)

--- ENE ---
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -775750.11941651
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -775750.11305258
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -775750.10571778
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -775750.09359536
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -775750.08522256
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -775750.07976176
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -775750.07273400
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -775750.06627481
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -775750.05653160
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -775750.05078986
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -775750.04165986
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -775750.02824173
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -775750.02513981
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -775750.01487899
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -775750.00743085
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -775749.99627176
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -775749.99306205
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -775749.98317825
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -775749.97811958
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -775749.96939695
--- DIS ---
:DIS  :  CHARGE DISTANCE  (  4.2460241 for atom3 spin 1)  
2.0217470
:DIS  :  CHARGE DISTANCE  (  4.2354501 for atom3 spin 1)  
2.0167505
:DIS  :  CHARGE DISTANCE  (  4.2249023 for atom3 spin 1)  
2.0117662
:DIS  :  CHARGE DISTANCE  (  4.2143828 for atom3 spin 1)  
2.0067942
:DIS  :  CHARGE DISTANCE  (  4.2038864 for atom3 spin 1)  
2.0018343
:DIS  :  CHARGE DISTANCE  (  4.1934158 for atom3 spin 1)  
1.9968867
:DIS  :  CHARGE DISTANCE  (  4.1829711 for atom3 spin 1)  
1.9919508
:DIS  :  CHARGE DISTANCE  (  4.1725544 for atom3 spin 1)  
1.9870274
:DIS  :  CHARGE DISTANCE  (  4.1621656 for atom3 spin 1)  
1.9821164
:DIS  :  CHARGE DISTANCE  (  4.1518018 for atom3 spin 1)  
1.9772172
:DIS  :  CHARGE DISTANCE  (  4.1414653 for atom3 spin 1)  
1.9723300
:DIS  :  CHARGE DISTANCE  (  4.1311557 for atom3 spin 1)  
1.9674546
:DIS  :  CHARGE DISTANCE  (  4.1208686 for atom3 spin 1)  
1.9625908
:DIS  :  CHARGE DISTANCE  (  4.1106085 for atom3 spin 1)  
1.9577392
:DIS  :  CHARGE DISTANCE  (  4.1003736 for atom3 spin 1)  
1.9528994
:DIS  :  CHARGE DISTANCE  (  4.0901658 for atom3 spin 1)  
1.9480720
:DIS  :  CHARGE DISTANCE  (  4.0799795 for atom3 spin 1)  
1.9432557
:DIS  :  CHARGE DISTANCE  (  4.0698205 for atom3 spin 1)  
1.9384514
:DIS  :  CHARGE DISTANCE  (  4.0596869 for atom3 spin 1)  
1.9336590

:DIS  :  CHARGE DISTANCE  (  4.0495779 for atom3 spin 1)
1.9288781
#
Yes I have converged the calculation using PBE-GGA and PBE-GGA with
SO. And in both the cases I have found the metallic nature of crystal
(using grep :GAP) and also in band structure the VB crosses the Fermi
level.
##
No, I didn't use the previous electron and kinetic energy density for
the lmbj calculation. What I did is created a new directory and I did
the fresh calculation.


On Mon, Jul 24, 2023 at 1:22 PM  wrote:


Could you show how the total energy and distance charge evolve during
the iterations of the lmBJ-SOC calculation (grep for :ENE and DIS in
case.scf)?

Before using lmBJ-SOC, did you succeed to converge a calculation on 
your

system using another method, like GGA-PBE or lmBJ without SOC? If yes,
have you tried to start the lmBJ-SOC calculation by using the electron
density (case.clmsum) and kinetic-energy density (case.tausum) 
obtained

from such a previous calculation that converged?


On 22.07.2023 05:47, Burhan Ahmed wrote:
> Dear experts, I am doing an scf calculation taking lmbj potential. My
> system is a slab of 6ql with a vacuum of 40 ang along c-axix. Whenever
> I try to run the scf calculation including SOC, after 999 iteration
> the scf is still not converged. I have analyzed the scf file, it shows
> the fluctuating nature. At first the selected Rmt was 2.5 then I
> reduces it to 2.34 and again convergence failed after 999 cycle. I
> have included -hdlo and -lvns 8 switch in init_lapw as it shows heavy
> atom. I am attaching the case.struct file. Hoping for any
> suggestion/solution.
>
> Regards
>
> Burhan Ahmed
>
> Research Scholar, AUS
> __

Re: [Wien] calculation with lmbj potential

[fabien . tran]

Could you show how the total energy and distance charge evolve during 
the iterations of the lmBJ-SOC calculation (grep for :ENE and DIS in 
case.scf)?


Before using lmBJ-SOC, did you succeed to converge a calculation on your 
system using another method, like GGA-PBE or lmBJ without SOC? If yes, 
have you tried to start the lmBJ-SOC calculation by using the electron 
density (case.clmsum) and kinetic-energy density (case.tausum) obtained 
from such a previous calculation that converged?



On 22.07.2023 05:47, Burhan Ahmed wrote:

Dear experts, I am doing an scf calculation taking lmbj potential. My
system is a slab of 6ql with a vacuum of 40 ang along c-axix. Whenever
I try to run the scf calculation including SOC, after 999 iteration
the scf is still not converged. I have analyzed the scf file, it shows
the fluctuating nature. At first the selected Rmt was 2.5 then I
reduces it to 2.34 and again convergence failed after 999 cycle. I
have included -hdlo and -lvns 8 switch in init_lapw as it shows heavy
atom. I am attaching the case.struct file. Hoping for any
suggestion/solution.

Regards

Burhan Ahmed

Research Scholar, AUS
___
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

Re: [Wien] GHOST BANDS error

[fabien . tran]

Hi,

As mentioned by Peter Blaha, this is not possible to do a calculation 
with a hybrid functional using XC_HYB_LDA_*, XC_HYB_GGA_* or 
XC_HYB_MGGA_* from Libxc. Actually, without entering into detail, this 
is not possible to use Libxc at all for a hybrid calculation (the 
results would be wrong).


The only hybrid functionals that can be used are listed in the user's 
guide under "The available functionals" in section "Unscreened and 
screened hybrid functionals".



On 08.07.2023 13:39, Peter Blaha wrote:

As was mentioned before, you can't use the XC_HYB_GGA_XC_* switches.

In addition: The manual says for   NBAND:  use "at least" NE+1. Then
it should run through.

But this does not mean that such a calculation is good. You should use
more bands for the second variation HF step, depending on your case.

You have above EF  5 empty Ti-d bands and a Ba-s band. So the minimum
for NBAND is NE+6, larger values are better.
Am 08.07.2023 um 09:06 schrieb Natalia Andreeva:


Dear Professor Blaha,

I use wien21.
I calculate the BaTiO3 structure, atom 1 is Ba, RMT(Ba) = 2.44;
RMT(Ti) = 1.72; RMT(O) = 1.55.
First I run the SCF calculation on WC, it converges successfully.
Results of scf calculation for WC potential:
Insulator, EF-inconsistency corrected
:GAP (global)   :  0.144257 Ry = 1.963 eV (accurate value if
proper k-mesh)
Bandranges (emin - emax) and occupancy:
:BAN00010:  10   -0.230168   -0.162160  2.
:BAN00011:  11   -0.225681   -0.146894  2.
:BAN00012:  120.2157620.365039  2.
:BAN00013:  130.2481280.370283  2.
:BAN00014:  140.2662080.370564  2.
:BAN00015:  150.3183150.438250  2.
:BAN00016:  160.3479630.440022  2.
:BAN00017:  170.3630370.457065  2.
:BAN00018:  180.4274220.529925  2.
:BAN00019:  190.4617750.531282  2.
:BAN00020:  200.4727090.539353  2.
:BAN00021:  210.6836100.849512  0.
:BAN00022:  220.7016650.850244  0.
:BAN00023:  230.7027230.850771  0.
:BAN00024:  240.8528481.043061  0.
:BAN00025:  250.8621161.102879  0.
Energy to separate low and high energystates:0.16576
:NOE  : NUMBER OF ELECTRONS  =   40.000
:FER  : F E R M I - ENERGY(TETRAH.M.)=   0.5393529588
:GMA  : POTENTIAL AND CHARGE CUT-OFF  12.00 Ry**.5
:POS001: ATOM   -1 X,Y,Z = 0.0 0.0 0.0  MULT= 1  ZZ=
56.000  Ba
lmax 10

This is a hybrid calculation, I use XC_HYB_GGA_XC_B1WC in case.in0,
after which I run init_hf_lapw, select nband = 21 (since after
calculating on WC nb_occ = 20). When I delete a line for l = 1 from
in1, an error still appears.

Thank you in advance,
With Best Regard,
Natalia Andreeva

On Fri, Jul 7, 2023 at 6:15 PM Peter Blaha
 wrote:

I need some more information:

Are you using wien23 or an earlier version ?

What is your system (struct file), in particular what is atom 1; its
RMT, ...

Such a large EF is rather unusual (except for 5f systems) and for
sure the resulting E-parameters as you showed below must lead to
ghostbands. Usually it is good to remove the LO for this atom and
l-value, at least temporarily, but you must check at what energy
would you expect the semicore state and you must not miss it, if it
is a real low energy state. 

Is this actually a hybrid calculation ? Does it happen in the first
iteration ? Did you start a hybrid calc. from a converged PBE
calculation ? 

Am 07.07.2023 um 13:48 schrieb Natalia Andreeva:

Dear Professor Blaha,

I tried to run calculations for hybrid functionality from libxc, but
I get a GHOST BANDS error. The case.scf2 file states that for atom 1
with l=1, the energy parameters need to be changed.

:WARN : QTL-B value eq. 32.08 in Band of energy 1.68736 ATOM= 1 L= 1
:WARN : You should change the E-parameter for this atom and L-value
in case.in1 (or try the -in1new switch)
The Fermi level in scf2 is
:FER : F E R M I - ENERGY(TETRAH.M.)= 1.8321578843
I tried setting it to 1.632 instead of the default 0.3 in case.in1,
but that didn't fix it.
Then I tried to remove the values that have similar energy values in
case.scf1 from the case.in1 file (reducing the number of n choices),
but this did not lead to a positive result.
:E1_0001: E( 1)= 0.7000
APW+lo
:E1_0001: E( 1)= 0.4094 E(BOTTOM)= 0.409 E(TOP)= -200.000 3 -1 222
LOCAL ORBITAL
When trying to change the energy parameters and set the in1new flag,
an nband error appeared.

Thank you in advance,

Best Regards,
Natalia Andreeva.

___
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-158801165300
Email:

Re: [Wien] error in nlvdw

[fabien . tran]

You have to delete case.inm_vresp and case.vresp*. These files are not 
used for the functional that you have chosen and may perturb lapw0.


On 27.06.2023 07:08, shamik chakrabarti wrote:

Dear Prof. Blaha,

I have used XC as XC_GGA_X_B86_R EC_LDA VC_LDA in case.in0. When I am
running from w2web by keeping the switch nlvdw on, its running while
when I tried to run from terminal by using the command "runsp_lapw
-nlvdw -fc 1.0 -ec 0.0001 -cc 0.0001 -min" its showing the above
mentioned  error. Please suggest me the needful. .

with regards,

On Mon, 26 Jun 2023 at 22:29, shamik chakrabarti
 wrote:


XC = XC_GGA_X_B86_R EC_LDA VC_LDA

On Mon, 26 Jun 2023 at 22:00, Peter Blaha 
wrote:

Why do you have case.vrespup/dn/sum  ??

Do you have a case.inm_vresp file ? This is not recommended anymore.


What is your XC in case.in0 ?

Am 26.06.2023 um 18:04 schrieb shamik chakrabarti:

Dear Wien2k users,

I have tried to optimize structural
coordinates of a layered structure by using the command in the
terminal runsp_lapw -nlvdw -fc 1.0 -ec 0.0001 -cc 0.0001 -min.
However an error appear in the first cycle;

changing nlvdw.in2
changing nlvdw.in2_ls
changing nlvdw.in2_st
changing nlvdw.in2_sy
STOP  NLVDW END
At line 809 of file lapw0.F (unit = 29, file = 'nlvdw.vrespup')
Fortran runtime error: End of file

Error termination. Backtrace:
#0  0x14d488623ad0 in ???
#1  0x14d488624649 in ???
#2  0x14d48862527f in ???
#3  0x14d4888784ab in ???
#4  0x14d4888796f4 in ???
#5  0x14d488879bac in ???
#6  0x14d48887bc27 in ???
#7  0x55604a62a19b in ???
#8  0x55604a5c806e in ???
#9  0x14d488229d8f in __libc_start_call_main
at ../sysdeps/nptl/libc_start_call_main.h:58
#10  0x14d488229e3f in __libc_start_main_impl
at ../csu/libc-start.c:392
#11  0x55604a5c80f4 in ???
#12  0x in ???
grep: No match.
grep: No match.
grep: No match.
grep: No match.
grep: No match.
grep: No match.
grep: No match.
grep: No match.
grep: No match.
grep: No match.
grep: No match.


stop error


Looking for your suggestions.

with regards,
--

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India

___
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-158801165300
Email: peter.bl...@tuwien.ac.at
WWW:   http://www.imc.tuwien.ac.at  WIEN2k: http://www.wien2k.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

--

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India

--

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India
___
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

Re: [Wien] hf error -monolayer

[fabien . tran]

And since you used the -redklist option, the files case.klist_fbz, 
case.klist_ibz, case.kgen_ibz and case.outputkgenhf should also be 
present. Is it the case?


As Peter mentioned, check if case.inhf is ok. In particular, the number 
of bands "nbands" needs to be set large enough (see Sec. 7.7.2 in the 
UG).


On 21.06.2023 22:50, Brik Hamida wrote:

Dear Fabien

Thank you for your reply.
Indeed the two files are generared.
I executed run_kgenhf_lapw -hf  -redklist with  :  k-mesh (eg. 4x4x4)
and commensurate reduced k-mesh (eg. 2x2x2).

case.klist :
 1 0 0 0 4  1.0 -7.0  1.5
   0 k, div: (  4  4  4)
 2 0 0 1 4  2.0
 3 0 0 2 4  1.0
 4 0 1 0 4  6.0
 5 0 1 1 4 12.0
 6 0 1 2 4  6.0
 7 0 2 0 4  3.0
 8 0 2 1 4  6.0
 9 0 2 2 4  3.0
10 1 1 0 4  6.0
11 1 1 1 4 12.0
12 1 1 2 4  6.0
END

case.kgen:
1272  2.60416667E-03   101 1
 4 1 2 4 4 4
 1 2 4 5 4 1
 2 5 5 8 1 4
 4 5 4 1 4 5
 5 4 2 3 5 5
 4 2 3 5 6 4
 2 3 6 6 4 2
 4 4 5 8 2 4
 5 5 8 2 5 5
 6 4 2 5 6 6
 4 3 5 5 6 8
 3 5 6 6 8 4
 4 510 4 4 4
 511 4 4 410
11 4 4 5 510
 8 4 5 511 8
 4 5 710 4 4
 5 711 4 4 5
 810 8 4 5 8
11 4 4 51011
 8 4 7 810 4
 4 7 811 8 4
 71011 4 4 8
1011 8 5 5 6
11 4 5 5 612
 4 5 51011 4
 5 51112 4 5
 6 611 8 5 6
 612 8 5 6 8
11 4 5 6 812
 4 5 6 911 8
 5 6 912 4 5
 61112 4 5 7
 810 8 5 7 8
11 4 5 71011
 8 5 8 911 4
 5 8 912 8 5
 81011 8 5 8
1112 4 5 911
12 4 6 61112
 4 6 8 911 8
 6 8 912 4 6
 81112 8 6 9
1112 4 7 810
10 4 7 81011
 4 7 81111 8
 7101011 4 7
101111 4 8 9
1111 4 8 911
12 4 8 91212
 4 8101011 8
 8101111 8 8
111112 4 811
1212 4 91111
12 8 9111212
 410101011 4
10101111 410
111111 41111
1112 4111112
12 4111212   

Re: [Wien] hf error -monolayer

[fabien . tran]

Not enough information is provided. In particular, were the various 
files case.klist* and case.kgen* properly generated with the command 
"run_kgenhf_lapw -redklist"?



On 21.06.2023 13:47, Brik Hamida wrote:

Dear

I have done hf-SFC calculation for BULK semiconductor  and it is well
done.
Then , I followed the same hf -calculation steps for MONOLAYER
semiconductor but unfortunately  I have an error in hf ( hf error
file) :

 start (21 جوان, 2023 CET 12:28:26 م) with lapw0
(40/99 to go)

cycle 1 (21 جوان, 2023 CET 12:28:26 م)
(40/99 to go)


  lapw0 -grr (12:28:26) 6.3u 0.0s 0:06.38 99.8% 0+0k 0+1io

0pf+0w

  lapw0  (12:28:32) 4.5u 0.0s 0:04.61 100.0% 0+0k 0+2704io

0pf+0w

  lapw1  (12:28:37) 41.2u 0.5s 0:41.74 100.0% 0+0k 0+72976io

0pf+0w

  lapw2  (12:29:19) 1.1u 0.0s 0:01.16 100.0% 0+0k 0+3864io

0pf+0w

  lcore(12:29:20) 0.0u 0.0s 0:00.05 100.0% 0+0k 0+2984io 0pf+0w
  hf   -mode1   -redklist (12:29:20) 0.0u 0.0s 0:00.09 88.8%

0+0k 0+24io 0pf+0w
error: command   /home/hmd/wien18/hf hf.def   failed


  stop error


Please can someone tell me how I can solve  this problem? Thanks in
advance .
Best regards
___
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

Re: [Wien] Band gap not matching with materials project data

[fabien . tran]

In case.scf you have to consider the global band gap, ":GAP (global)". 
With you struct file this gap is 3.17 eV (still fare from 0.96 eV). The 
two other values of the band gap (6.93 eV and 10.37 eV) in case.scf are 
for spin-up and spin-down channels.


On 07.06.2023 11:08, shamik chakrabarti wrote:

Dear Wien2k users,

 I have tried to optimize the crystal structure of
Alpha-N2 by using data from "
https://materialsproject.org/materials/mp-12103/#electronic_Structure";
However, after optimization (or even with the unoptimized cell) we are
getting vast different electronic band gap.
The structure on
"https://materialsproject.org/materials/mp-12103/#electronic_Structure";
tells band gap as 0.96 eV while our optimized structure ( or even with
the unoptimized structure) is giving the band gap as ~ 10.553 eV.
However the magnetic moment is coming the same (~0.6 muB) for both the
cases. I am attaching the optimized struct file herewith this mail.

Looking forward to your response in this regards.

with regards,

--

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India
___
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

Re: [Wien] Query about clean_lapw

[fabien . tran]

Executing clean_lapw is still preferable to avoid a case.scf file that 
contains the info about this 1st wrong iteration.


On 02.06.2023 18:18, Peter Blaha wrote:

Try it out.

Am 02.06.2023 um 14:21 schrieb shamik chakrabarti:

Dear Wien2k users,

                           Initially I have forgotten to add -hf in a 
calculation initialized for running -hf for one cycle. However, I have 
stopped the calculation after one cycle which contains initialization 
of -hf which produces lapw0 -grr during one iteration. After that I 
have run clean_lapw & then start with the attached -hf flag. My query 
is whether clean_lapw ensures that I do not have any error for 
continuing with -hf or I may need to start a fresh calculation in a 
fresh directory?


Looking forward to hearing from you.

with regards,

-- Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India

___
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

Re: [Wien] compiling the WIEN2k 23.1 version

[fabien . tran]

Do not forget to upgrade to WIEN2k_23.2, in particular for systems with 
atoms having a cubic point group.


On 14.03.2023 18:07, delamora wrote:

Thanks Prof. Marks,

 I ran the simple Na BCC and I got

  Cholesky INFO =   87

 Then Lu Hex
  Cholesky INFO =  136

 also Cu FCC

 Cholesky INFO =   28

 So there is something wrong. Before I could run Na and Cu without
problem.

 I am not mixing 17.1 with 23.1, I just want to fix this problem
before I go forward.

 Pablo

-

De: Wien  en nombre de
Laurence Marks 
Enviado: lunes, 13 de marzo de 2023 10:46 p. m.
Para: A Mailing list for WIEN2k users

Asunto: Re: [Wien] compiling the WIEN2k 23.1 version

This is 95% not an indication of something wrong with your computer.
The error is indicating that the 87th row/column of your Hamiltonian
is too similar to another, so the Cholesky decomposition is failing.
This most often occurs if you have a mistake in your case.in1 file,
where some of the linearization energies are too close. If you have a
bad potential (density) I think it can also occur.

However, without more information it is hard to guess more. Perhaps
save the version that went wrong and recreate it. It may not be safe
to mix an old 17.1 version and 23.1, as some formats have changed.

--
Professor Laurence Marks
Department of Materials Science and Engineering, Northwestern
University
www.numis.northwestern.edu [3]
"Research is to see what everybody else has seen, and to think what
nobody else has thought" Albert Szent-Györgyi

On Mon, Mar 13, 2023, 23:33 delamora  wrote:


Prof Blaha,
Thank for your reply
When I ran the "siteconfig" it would run without stoping not
allowing me to compile the program, but now it does stop and it
allows me to compile

But there is something wrong in my computer in the earlier 17.1
version

I try to run a system and it stops just after LAPW0;
--

[pablo@delamora Na-prueb]$ run
LAPW0 END
SECLR4 - Error
grep: lapw2*.error: No such file or directory


stop error

[pablo@delamora Na-prueb]$ more lapw1.error
Cholesky INFO =   87
'SECLR4' - POTRF (Scalapack/LAPACK) failed.
[pablo@delamora Na-prueb]$

--
So what are these errors? It seems that

Scalapack/LAPACK
has been corrupted

Pablo

-

De: Wien  en nombre de
Peter Blaha 
Enviado: martes, 7 de marzo de 2023 06:13 a. m.
Para: wien@zeus.theochem.tuwien.ac.at

Asunto: Re: [Wien] compiling the WIEN2k 23.1 version


I downloaded the WIEN2k 23.1 version
I followed the instructions

..

./expand_lapw

.siteconfig_lapw -update ../WIEN2k-21.1/

but I did not compile it
so I restarted the procedure from the begining and when I came to

this

last command

.siteconfig_lapw -update ../WIEN2k-21.1/

it was executed in one step, but I could not compile the program
So my question is how I compile it


?
You should come into the main menue of siteconfig. Then just press
R  (compile/recompile).

Make sure that   ../WIEN2k-21.1   still contains proper WIEN2k_*
configuration files.



Pablo

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien [1]
SEARCH the MAILING-LIST at:



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

[2]

--


--

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

[2]
___
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

[2]



Links:
--
[1] http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[2] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[3] http://www.numis.northwestern.edu
___
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

Re: [Wien] Whether Hartree-Fock exchange Alpha is a tunable parameter?

[fabien . tran]

Yes, alpha is quite often considered as a tunable parameter. A certain 
number of papers on that topic have been published, e.g.,

https://aip.scitation.org/doi/10.1063/1.4722993

More papers can be found with google (https://www.google.com) with 
keywords like "hybrid functionals" and "fraction of Hartree-Fock".


On 31.01.2023 10:29, shamik chakrabarti wrote:

Dear Wien2k users,

 Whether Hartree-Fock exchange Alpha is a
tunable parameter? Can we change the parameter to see that at which
value of Alpha, the experimental result matches with simulation?
Especially when with Alpha=0.25 the calculation diverges!

Looking forward to hearing from you.

with regards

--

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India
___
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

Re: [Wien] ELF

[fabien . tran]

It is on my to-do list to reimplement ELF in VASP in a more proper way. 
In any case, it seems that ELF was buggy in a certain number of codes 
(WIEN2k, VASP, Quantum Espresso).


On 04.11.2022 22:06, Kateryna Foyevtsova wrote:

Hello,

since I see that VASP results are being discussed here, I'd like to
bring your attention to my communication with the VASP developers in
April this year:

https://www.vasp.at/forum/viewtopic.php?f=3&t=18484

where they admitted that "the current implementation depends strongly
on the choice of the POTCAR. You can test this by using the GW POTCAR
and will find contributions from Ni 3d electrons. We believe that with
this pseudo-potential dependent ELF is not a good measure for
electronic localisation and thus want to replace this (very old)
implementation in a future release."

which means that ELF calculated in the current version (and all
earlier versions, apparently) of VASP can have errors and should not
be used as a gold standard. I think they still have not fixed that bug
according to

https://www.vasp.at/forum/viewtopic.php?f=4&t=18628&p=22510&hilit=elf#p22510

Best,
Kateryna


On 2022-11-04 13:11, reyhaneh ebrahimi wrote:

[CAUTION: Non-UBC Email]

Dear Prof. Blaha
Thank you for your valuable answer to my Email.
I put my ELF graph, your ELF results, and Jiawang  and Olivier' graph
for SnSe on one page to have a better comparison, see
"https://www.mediafire.com/file/kyfi46ppx6mhtnx/SnSe-final.jpg/file";.
I also specified the plane which I did my ELF calculation on it.
Therefore, as you mentioned in your Email, the existing differences
between my graph, your graph, and Jiawang  and Olivier' graph would be
due to the choice of different planes in these works.
Sincerely yours
Reyhaneh Ebrahimi

On Fri, Nov 4, 2022 at 8:33 AM Peter Blaha 
wrote:


Sorry: the links should be:  SnSe, not SnGe

http://www.wien2k.at/Depository/SnSe-f.png
http://www.wien2k.at/Depository/SnSe-g.jpg
http://www.wien2k.at/Depository/SnSe-t.png

Am 04.11.2022 um 15:27 schrieb Peter Blaha:

Your picture for SnSe is probably in a different plane as compared

to

the 4 pictures in the paper.
I produced 2 elf pictures, which resembles the planes in Fig. 6f

and 6g.


They look as expected. In the interstital identical (see eg. the 2



different blue features in 6f), but inside the spheres quite

different

because of the pseudopotentials.

I guess it is a general feature that inside spheres (and for

heavier

atoms) the PP ELF is nonsense.

You can download them at:

http://www.wien2k.at/Depository/SnGe-f.png
http://www.wien2k.at/Depository/SnGe-g.jpg
http://www.wien2k.at/Depository/SnGe-t.png


Am 04.11.2022 um 00:13 schrieb reyhaneh ebrahimi:

Dear Prof. Blaha
I apologize. Let me make my previous Email a little more

complete. As

you mentioned in your Email, for SnS the sources of differences
between the results of ELF using WIEN2k code and VASP code is due

to

the difference between all-electron and pseudopotentials

calculations

in these two codes. However, I am still not sure that the

differences

between my results for the ELF of SnSe and Jiawang and Olivier's

paper

are normal or not. I would be glad if you let me know your

opinion

about this subject.
Sincerely yours
Reyhaneh Ebrahimi

On Thu, Nov 3, 2022 at 1:13 PM Peter Blaha


> wrote:

Good to hear that this has been resolved.

PS: I just did a SnSe calc. and compared with the VASP paper.
Similarly,
very good agreement in the interstitial, while inside the

atomic

cores
there is the expected difference between all-electron and
pseudopotentials.

Am 03.11.2022 um 21:06 schrieb Kateryna Foyevtsova:

Dear Prof. Blaha,

I think I know what's going on with ELF. Wien2k gets it

correctly, but

Quantum Espresso has a bug which shows up in nspin=1

calculations. In

the attached figure I compare the wien2k result with two

QE

calculations: (1) one with nspin=1 switch and (2) one with

nspin=2

switch. In both cases I am looking at the same

non-magnetic

solution

that has the same energy in the two QE calculations.

Now you see that the difference between QE nspin=1 and

nspin=2 is

dramatic whereas there should be none.

The wien2k result looks very similar to the QE nspin=2

result

in the

interstitial region at 0.5,0.5,0.0, marked with a big

purple "X".

There

are differences close to atomic nuclei but this is

expected given

that

we are comparing an all-electron and a pseudo-potenial

code.


Thank you very much for helping me resolve this issue.

Best,
Kateryna

On 2022-11-02 12:21, Peter Blaha wrote:

[CAUTION: Non-UBC Email]

My result looks like the attached picture. I do get 0.8

in the

core

region of Ni, but not larger than that. It is probably

similar

than

yours.
I have no idea why it is different from QE, except maybe

that

these

are pseudopotential calc.

As I said before, you should compare other compounds, and

also

compare

with literature ELF calculations.



Am 01.11.2022 um 

Re: [Wien] [EXTERNAL] Re: ELF

[fabien . tran]

Hello,

Before the bug fix, create_elf_lapw and create_rho.f were producing a 
wrong ELF function in the non-spin-polarized case. However, with the bug 
fix sent previously this is now in the spin-polarized case that ELF is 
wrong. We will fix the problem for both cases and probably send the 
corrections in the mailing list.


On 03.11.2022 21:53, Zhu, Jianxin via Wien wrote:

Dear Peter and Kateryna,

Thanks for sorting this out.

Peter, the fixed bug in create_rho.f is a separate issue, right?

Best,

Jianxin

On 11/3/22, 2:13 PM, "Wien on behalf of Peter Blaha"
 wrote:

Good to hear that this has been resolved.

PS: I just did a SnSe calc. and compared with the VASP paper. 
Similarly,
very good agreement in the interstitial, while inside the atomic 
cores
there is the expected difference between all-electron and 
pseudopotentials.


Am 03.11.2022 um 21:06 schrieb Kateryna Foyevtsova:
> Dear Prof. Blaha,
>
> I think I know what's going on with ELF. Wien2k gets it 
correctly, but
> Quantum Espresso has a bug which shows up in nspin=1 
calculations. In

> the attached figure I compare the wien2k result with two QE
> calculations: (1) one with nspin=1 switch and (2) one with 
nspin=2
> switch. In both cases I am looking at the same non-magnetic 
solution

> that has the same energy in the two QE calculations.
>
> Now you see that the difference between QE nspin=1 and nspin=2 is
> dramatic whereas there should be none.
>
> The wien2k result looks very similar to the QE nspin=2 result in 
the
> interstitial region at 0.5,0.5,0.0, marked with a big purple "X". 
There
> are differences close to atomic nuclei but this is expected given 
that

> we are comparing an all-electron and a pseudo-potenial code.
>
> Thank you very much for helping me resolve this issue.
>
> Best,
> Kateryna
>
> On 2022-11-02 12:21, Peter Blaha wrote:
>> [CAUTION: Non-UBC Email]
>>
>> My result looks like the attached picture. I do get 0.8 in the 
core
>> region of Ni, but not larger than that. It is probably similar 
than

>> yours.
>> I have no idea why it is different from QE, except maybe that 
these

>> are pseudopotential calc.
>>
>> As I said before, you should compare other compounds, and also 
compare

>> with literature ELF calculations.
>>
>>
>>
>> Am 01.11.2022 um 21:16 schrieb Kateryna Foyevtsova:
>>> Dear Prof. Blaha,
>>>
>>> thank you for looking into this issue. I've tried the modified
>>> create_rho.f and calculated the ELF of NdNiO2 again using 
create_elf.
>>> I am getting a better agreement with QE, but it is not perfect 
as you
>>> noted it too. My calculation was well converged and I used the 
same
>>> k-grid and RKmax=7. The bandstructures from QE and wien2k agree 
very

>>> well.
>>>
>>> I attach my comparison as a png file. I wonder whether you have 
any
>>> idea about the possible reasons for the differences in ELF that 
the
>>> two codes give? For example, at 0.5,0.5,0 the wien2k value is 
~0.22

>>> and the QE value is ~0.43.
>>>
>>> Thank you,
>>> Kateryna
>>>
>>> On 2022-10-28 04:43, Peter Blaha wrote:
 [CAUTION: Non-UBC Email]

 Dear Kateryna ,

 In fact, I found a big difference between create_elf   and
 x lapw0 (with VX_ELF); x lapw5 -exchange

 I traced it back to normalization errors in tau_w and tau_tf, 
which

 missed a factor of 2.

 The attachedcreate_rho.f  fixes the problem. It should be 
copied

 into SRC_trig; make

 Then you can usecreate_elf   again.

 PS: I would always compare the ELF created with both methods 
as
 indicated above. Depending on the numerics, one or the other 
method
 may give smoother plots, but in any case, they should be very 
similar.


 PPS: The agreement to QE-ELF seems reasonable (but not 
perfect), but

 I've not converged my calculations.

 Thanks for the report
 Peter Blaha


> I attach a pdf showing the differences. Also attached are my 
wien2k

> >struct file and quantum espresso input file.

> Both calculations were done without spin polarization and 
using PBE.


> To me, the differences are big enough to question whether it 
is
> >meaningful to use ELF at all if it depends on all-electron 
vs
> >pseudopotential so strongly. Unless I am missing something 
or

> doing >something wrong.

> Thank you,
> Kateryna

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

https://urldefense.com/v3/__http://zeus.theochem.tuwien.ac.at/mail

Re: [Wien] Spin-polarized state not really spin-polarized

[fabien . tran]

I don't think that it is worth using the FSM method. The calculation 
started with non-zero moments (FM state) which at the end disappeared, 
which is already an indication (at least with PBE). In addition, 
magnetism in solids is usually expected when there are transition-metal 
atoms, which is not the case here. As Xavier mentioned, SOC should be 
considered for such heavy atoms.



On 30.10.2022 16:30, pboulet wrote:

All right, so here are the MMTOT data:

Starting point of SCF: 123.85779
Converged: 0.05631

And MMI ones:
Starting point:

:MMINT:  MAGNETIC MOMENT IN INTERSTITIAL  =   71.11022
:MMI001: MAGNETIC MOMENT IN SPHERE   1=1.03742
:MMI002: MAGNETIC MOMENT IN SPHERE   2=1.03736
:MMI003: MAGNETIC MOMENT IN SPHERE   3=0.62202
:MMI004: MAGNETIC MOMENT IN SPHERE   4=0.62205
:MMI005: MAGNETIC MOMENT IN SPHERE   5=1.03746
:MMI006: MAGNETIC MOMENT IN SPHERE   6=0.62203
:MMI007: MAGNETIC MOMENT IN SPHERE   7=0.62196
:MMI008: MAGNETIC MOMENT IN SPHERE   8=1.03238
:MMI009: MAGNETIC MOMENT IN SPHERE   9=0.62236
:MMI010: MAGNETIC MOMENT IN SPHERE  10=0.29692

Converged:

:MMINT:  MAGNETIC MOMENT IN INTERSTITIAL  =0.04102
:MMI001: MAGNETIC MOMENT IN SPHERE   1=0.0
:MMI002: MAGNETIC MOMENT IN SPHERE   2=   -0.00015
:MMI003: MAGNETIC MOMENT IN SPHERE   3=0.00028
:MMI004: MAGNETIC MOMENT IN SPHERE   4=0.00029
:MMI005: MAGNETIC MOMENT IN SPHERE   5=   -0.3
:MMI006: MAGNETIC MOMENT IN SPHERE   6=0.00030
:MMI007: MAGNETIC MOMENT IN SPHERE   7=0.00027
:MMI008: MAGNETIC MOMENT IN SPHERE   8=0.00104
:MMI009: MAGNETIC MOMENT IN SPHERE   9=0.00038
:MMI010: MAGNETIC MOMENT IN SPHERE  10=0.00128

Obviously the system converges towards a non-spin polarized state.

From the literature, there has been some experimental investigation
on, e.g., Pb(1-x)Tl(x)Te (x=0.001-0.02). One can read: [..] Various
mechanisms** which can lead to observable anomalies, including
Kondo-like behavior of a non-magnetic degenerate two-level system are
discussed.

So maybe the structure is non-magnetic.

** related to thermoelectric power

Now let’s say I want to make sure this is a non-magnetic compound by
enforcing a magnetic state (in which case the total energy should be
higher than for the non-magnetic state), I should run runfsm_lapw and
change case.inst to enforce a spin polarization right at the
beginning, shouldn’t I?

Pascal


Le 30 oct. 2022 à 14:04, fabien.t...@vasp.at a écrit :

Dear Pascal,

Depending on the system it may be possible to stabilize more than
one magnetic state. In such cases, the magnetic state obtained at
the end of the calculation typically depends on the initial magnetic
state when starting the calculation. What was the initial magnetic
state in your calculation? Grep for :MMTOT (total moment in cell) or
:MMI (moment on atoms) in case.scf to see how these quantities
evolved during the SCF procedure. Is Pb31TlTe32 supposed to be
magnetic according to experiment?

On 30.10.2022 13:07, pboulet wrote:


Dear all,
I am investigating Pb31TlTe32 in which Tl is the only element that
bring an odd number of electrons.
I have set up a spin-polarized calculation with init_lapw, but not
with an anti-ferromagnetic state.
As a starting point, I do not include spin-orbit and I use PBE.
NOE=959 in the structure.
After converging the SCF, I end up with the following (to me
strange)
occupation states:
For spin up:
:BAN00479: 4790.2723370.309267  1.
:BAN00480: 4800.2836050.328642  0.50431432
:BAN00481: 4810.3719270.455285  0.
For spin down:
:BAN00479: 4790.2724050.309306  1.
:BAN00480: 4800.2837200.328787  0.49568569
:BAN00481: 4810.3720180.455369  0.
I rather expected to have 480 spin up occupied states with 1
electron
and 479 spin down occupied states with 1 electron, but I have
something like a closed-shell spin polarized state.
Is it what we should expect?
If not, could you please explain me what happens and eventually
how to
remedy this to have a ‘real’ spin polarized state?
Thank you
Pascal
Pascal Boulet
—
_Professor in computational materials chemistry - DEPARTMENT OF
CHEMISTRY_
University of Aix-Marseille - Avenue Escadrille Normandie Niemen -
F-13013 Marseille - FRANCE
Tél: +33(0)4 13 55 18 10 - Fax : +33(0)4 13 55 18 50
Email : pascal.bou...@univ-amu.fr
___
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

Pascal Boulet
—
_Professor i

Re: [Wien] Spin-polarized state not really spin-polarized

[fabien . tran]

Dear Pascal,

Depending on the system it may be possible to stabilize more than one 
magnetic state. In such cases, the magnetic state obtained at the end of 
the calculation typically depends on the initial magnetic state when 
starting the calculation. What was the initial magnetic state in your 
calculation? Grep for :MMTOT (total moment in cell) or :MMI (moment on 
atoms) in case.scf to see how these quantities evolved during the SCF 
procedure. Is Pb31TlTe32 supposed to be magnetic according to 
experiment?


On 30.10.2022 13:07, pboulet wrote:

Dear all,

I am investigating Pb31TlTe32 in which Tl is the only element that
bring an odd number of electrons.
I have set up a spin-polarized calculation with init_lapw, but not
with an anti-ferromagnetic state.
As a starting point, I do not include spin-orbit and I use PBE.

NOE=959 in the structure.

After converging the SCF, I end up with the following (to me strange)
occupation states:
For spin up:

:BAN00479: 4790.2723370.309267  1.
:BAN00480: 4800.2836050.328642  0.50431432
:BAN00481: 4810.3719270.455285  0.

For spin down:

:BAN00479: 4790.2724050.309306  1.
:BAN00480: 4800.2837200.328787  0.49568569
:BAN00481: 4810.3720180.455369  0.

I rather expected to have 480 spin up occupied states with 1 electron
and 479 spin down occupied states with 1 electron, but I have
something like a closed-shell spin polarized state.

Is it what we should expect?

If not, could you please explain me what happens and eventually how to
remedy this to have a ‘real’ spin polarized state?

Thank you
Pascal

Pascal Boulet
—
_Professor in computational materials chemistry - DEPARTMENT OF
CHEMISTRY_

University of Aix-Marseille - Avenue Escadrille Normandie Niemen -
F-13013 Marseille - FRANCE
Tél: +33(0)4 13 55 18 10 - Fax : +33(0)4 13 55 18 50
Email : pascal.bou...@univ-amu.fr
___
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

Re: [Wien] Number of orbitals in spin-polarized hybrid calculation

[fabien . tran]

Both in spin-polarized and non-spin-polarized calculations, nband is the 
number of orbitals per spin.


On 29.10.2022 19:24, Peter Blaha wrote:

It is number of orbitals per spin.

Am 29.10.2022 um 19:07 schrieb pboulet:

Dear all,

I have a question regarding the number of orbitals to set in the 
case.inhf file when one wants to run a spin-polarized calculation: is 
it the total number of orbitals (up+down) or the number of orbitals 
per spin?


Thank you
Best regards,
Pascal



Pascal Boulet
—
/Professor in computational materials chemistry - DEPARTMENT OF 
CHEMISTRY/
University of Aix-Marseille - Avenue Escadrille Normandie Niemen - 
F-13013 Marseille - FRANCE

Tél: +33(0)4 13 55 18 10 - Fax : +33(0)4 13 55 18 50
Email : pascal.bou...@univ-amu.fr 





___
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

Re: [Wien] Whether magnetic moment per atom can be trusted in mbj

[fabien . tran]

About magnetism with mBJ:
https://journals.aps.org/prb/abstract/10.1103/PhysRevB.83.195134
https://journals.aps.org/prb/abstract/10.1103/PhysRevB.87.045103
https://journals.aps.org/prb/abstract/10.1103/PhysRevB.102.024407

On 21.09.2022 19:16, shamik chakrabarti wrote:

Dear Wien2k users,

TB-mbj is used for simulating more accurate
band gap in comparison to that obtained in GGA+U approach. I think as
the DOS is more accurate, magnetic moment per atom should also be
trusted. Is it so?

This question arise as I have obtained high spin configuration using
GGA+U while obtain low spin configuration using TB-mbj. Any comment on
that?

Looking forward to your reply in this regard.

with regards,

--

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India
___
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

Re: [Wien] Getting Identical Band Structure for Spin Up and Down When Turn On SOC

[fabien . tran]

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg06561.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg03239.html

On 06.09.2022 18:06, Xudong Huai wrote:

Dear WIEN2k users,

 I am running a PBE+SP+SOC calculation on MnSi.

 The OS is Rocky Linux 8.6. WIEN2k was compiled with
intel-oneapi-compilers 2022.1.0, the MPI version is intel-oneapi-mpi
2021.6.0, the math libraries are intel-oneapi-mkl 2022.1.0, fftw is
3.3.10.
I want to get the spin-polarized band structures.

There is no error or abnormal running of the calculation, but the
result shows identical band structures for spin-up and spin-down
(while the density of states plots are different).

Is this a common problem? And how should we fix it?

 Looking forward to your reply in this regard.

Xudong Huai
___
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

Re: [Wien] Are MGGA potentials implimented in Libxc (for Wien2k)?

[fabien . tran]

This type is not yet available in WIEN2k. The forces would be easier to 
implement, but with probably numerical difficulties because of the high 
derivatives of rho.


On 29.06.2022 22:30, Laurence Marks wrote:

Not even SCANL?

On Wed, Jun 29, 2022 at 3:20 PM  wrote:


https://doi.org/10.1103/PhysRevB.105.195138
No forces at the moment and probably not easy to have them.

On 29.06.2022 22:14, Laurence Marks wrote:

I am ever hopeful! While the energy is useful, really want to have

it

be self-consistent with forces.

--

Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu [1] [1]
"Research is to see what everybody else has seen, and to think

what

nobody else has thought", Albert Szent-Györgyi

Links:
--
[1] http://www.numis.northwestern.edu
___
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

--

Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu [1]
"Research is to see what everybody else has seen, and to think what
nobody else has thought", Albert Szent-Györgyi

Links:
--
[1] http://www.numis.northwestern.edu
___
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

Re: [Wien] Are MGGA potentials implimented in Libxc (for Wien2k)?

[fabien . tran]

https://doi.org/10.1103/PhysRevB.105.195138
No forces at the moment and probably not easy to have them.

On 29.06.2022 22:14, Laurence Marks wrote:

I am ever hopeful! While the energy is useful, really want to have it
be self-consistent with forces.

--

Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu [1]
"Research is to see what everybody else has seen, and to think what
nobody else has thought", Albert Szent-Györgyi

Links:
--
[1] http://www.numis.northwestern.edu
___
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

Re: [Wien] MMINT

[fabien . tran]

Please have a look at Sec. III and Table II in 
https://publik.tuwien.ac.at/files/publik_289949.pdf


On 25.06.2022 08:45, reyhaneh ebrahimi wrote:

Dear WIEN2k users;

Would you please let me know why for an antiferromagnetic system, as
stated in
“https://www.mailarchive.com/wien@zeus.theochem.tuwien.ac.at/msg11651.html”,
we compare MMI00X with the experimental data? Although we know that
MMINIT is always zero for an antiferromagnetic system, but this does
not mean that the contribution of the magnetic moment of an atom in
the interstitial region is zero. Zero MMINT may be due to the
cancellation of MMINIT of an atom with up spin states and another atom
with down spin states. Therefore, an atom may have the non-zero MMINT
in the interstitial region. In this case, MMINT should be summed with
the MMI00X and then compared with experimental data. For example,
MMTOT is always zero for antiferromagnetic systems, but this does not
mean that the magnetic moment of an atom is zero.

Thank you very much;

Sincerely yours
___
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

Re: [Wien] MMINT

[fabien . tran]

In https://publik.tuwien.ac.at/files/publik_289949.pdf
we used the AIM method to calculate the magnetic moment and on page 9 we 
wrote:
"The contribution from the interstitial region is one order of magnitude 
smaller and has opposite sign (negative), which is due to reverse 
polarization of the 4s electrons [84,85]."


On 23.06.2022 16:50, Laurence Marks wrote:

I do not think that there is a unique definition of interstitial
magnetic moments for each atom -- in APW+lo methods the interstitial
states extend over the whole cell.

The best I can think of is to use the Bader charge, i.e. use "x aim"
and "x aim -dn", take the difference (to spin resolve) then compare to
the :MM for the relevant atom.

(N.B., "x aim -up" does not look right.)

WRT your other questions, the sign of the spin without -so or a
magnetic field is not well defined, you can multiply all by -1 and
nothing in the density/energy will change.

The interstitial components do not have to have the same sign, and
often do not. Sometimes one spin state is more delocalized, hence more
in the interstitial.

--
Professor Laurence Marks
Department of Materials Science and Engineering, Northwestern
University
www.numis.northwestern.edu [1]
"Research is to see what everybody else has seen, and to think what
nobody else has thought" Albert Szent-Györgyi

On Thu, Jun 23, 2022, 9:26 AM shahrbano rahimi
 wrote:


Dear WIEN developers and users:

Please let me know:
How I can find the interstitial magnetic moment (MMINT) per atom in
a ferromagnetic system with two kinds of magnetic atoms? What is the
sign of interstitial magnetic moment (MMINT) per atom? Is it similar
to the sign of the MMI of that atom?
Best Regards,
Shahrbano Rahimi
___
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


Links:
--
[1] http://www.numis.northwestern.edu
___
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

Re: [Wien] Structure optimization with TEMP

[fabien . tran]

Yes, this should be the most simple procedure to follow: first optimize 
the geometry with PBE and then use HSE06 with TEMP.


Besides, with PBE you can check what is the influence of using TETRA or 
TEMP on the final property that you want to calculate.


On 21.06.2022 14:39, shamik chakrabarti wrote:

Dear Dr. Bhamu & Prof. Tran

   I am getting convergence as long as I am using
spin polarization with TETRA is case.in2c. However, with the optimized
structure (as obtained using SP & TETRA) when I apply HSE06 I am not
getting convergence & I need to shift to TEMP. Whether these will give
the correct solution: (1) str optimization with TETRA & (2) apply TEMP
while using HSE06 for simulation of total energy.

with regards,

On Tue, 21 Jun 2022 at 17:54,  wrote:


For a metal the total energies obtained with TETRA and TEMP will be
different.

If there is no way to achieve convergence with TETRA, then all
calculations should be done with TEMP.

On 21.06.2022 14:11, shamik chakrabarti wrote:

Dear Wien2k users,

We know the total energy/unit cell will be
different for two cases with TETRA or TEMP. However, a converged
structure obtained using TETRA will be same as obtained with TEMP

or

different?

with regards,

--

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India
___
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

--

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India
___
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

Re: [Wien] Structure optimization with TEMP

[fabien . tran]

For a metal the total energies obtained with TETRA and TEMP will be 
different.


If there is no way to achieve convergence with TETRA, then all 
calculations should be done with TEMP.


On 21.06.2022 14:11, shamik chakrabarti wrote:

Dear Wien2k users,

   We know the total energy/unit cell will be
different for two cases with TETRA or TEMP. However, a converged
structure obtained using TETRA will be same as obtained with TEMP or
different?

with regards,

--

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India
___
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

Re: [Wien] Query regarding clean_lapw

[fabien . tran]

Not only the last 72th iteration, but all 72 iterations. I want to see 
how :ENE and :DIS behave.


On 15.06.2022 11:09, shamik chakrabarti wrote:

ENE and :DIS of the 72 iterations

Analysis of parameter:
:ENE :DIS
in GN_Li_TEMP_TETRA.scf (showing last 1 / 1 lines)

--- ENE ---
:ENE  : ** TOTAL ENERGY IN Ry = -505.54045526
--- DIS ---
:DIS  :  CHARGE DISTANCE   ( 0.0999309 for atom6 spin 2)
0.1108338

regards,

On Wed, 15 Jun 2022 at 14:36,  wrote:


Can you show :ENE and :DIS of the 72 iterations.

On 15.06.2022 10:55, shamik chakrabarti wrote:

Dear Prof. Blaha & Tran,

Following your advice I have done the
followings;
(1) Use HSE06 with alpha=0.25, TEMP in case.in2c & got converged
solution.
(2) After convergence I have changed TEMP ino TETRA (without
clean_lapw) & the DIS: & ENE obtained for the 5 consecutive cycles

are

as follows,

--- ENE ---
:ENE  : ** TOTAL ENERGY IN Ry = -505.54688505
:ENE  : ** TOTAL ENERGY IN Ry = -505.54426530
:ENE  : ** TOTAL ENERGY IN Ry = -505.53129501
:ENE  : ** TOTAL ENERGY IN Ry = -505.53562517
:ENE  : ** TOTAL ENERGY IN Ry = -505.53523118
--- DIS ---
:DIS  :  CHARGE DISTANCE   ( 0.0791378 for atom6 spin 2)
0.1295270
:DIS  :  CHARGE DISTANCE   ( 0.0929466 for atom6 spin 2)
0.1395017
:DIS  :  CHARGE DISTANCE   ( 0.0952392 for atom6 spin 2)
0.1425026
:DIS  :  CHARGE DISTANCE   ( 0.0985462 for atom6 spin 2)
0.1349318
:DIS  :  CHARGE DISTANCE   ( 0.0985828 for atom6 spin 2)
0.1188199

The simulation has completed 72 iterations with charge convergence

&

energy convergence as follows;
CHARGE convergence:  0 0.01 .0885828
:ENERGY convergence:  0 0.0001 .00216508

Do you think it is going in the proper direction & I should wait?

with regards,

On Mon, 13 Jun 2022 at 18:01, Peter Blaha



wrote:


Be careful and check if your calculations with   PRATT 0.05   are
really
converged and check :ENE AND :DIS

With small PRATT mixing some pseudo-convergence can happen and in
general I'd recommend PRATT mixing only for nasty cases and a

couple

of
steps, before switching back to MSR1.

Am 13.06.2022 um 14:26 schrieb fabien.t...@vasp.at:

In general, the total energies that are compared need to be

obtained

with the same setting. So, all the total energies have to be

obtained

with either TETRA or TEMP.

You can try to restart with TETRA the calculation that you

converged

with TEMP (clean_lapw should not be executed after the TEMP
calculation in order to have the case.vector for restarting with
TETRA). Maybe the TETRA calculation will this time converge.

Otherwise, you would need to run the other calculations also

with

TEMP.


On 12.06.2022 10:14, shamik chakrabarti wrote:

Dear Prof. Tran,

I have obtained convergence by introducing the
following parameters; alpha=0.25, mixing scheme = PRATT, mixing
parameter=0.05, TETRA instead of TEMP in case.in2.
Now, I want to compare the energy before lithiation & after
lithiation. I have obtained the energy before lithiation using

the

parameter, alpha =0.25, mixing scheme = Msr1, mixing

parameter=0.2,

TEMP in case.in2

Do you think that these two scenarios are comparable? or I may

need to

invoke the same parameters in the system before lithiation?

with regards,

On Sat, 11 Jun 2022 at 13:35, shamik chakrabarti
 wrote:


Dear Prof. Tran,

Yes the system is a metal. Do you think using
PRATT will be reasonable as Prof. Blaha once said that he

would

not

play with the PRATT mixing?

with regards,

On Sat, 11 Jun 2022 at 00:40,  wrote:


If the calculation really did not seem to converge (:ENE was
oscillating
or :DIS was staying at some high value for ever) then yes it

may

be
better to delete the case.vector files with clean_lapw and
regenerate
case.clmsum in some way (with dstart or with some functional,

PBE

or
PBE+U).

I can not remember the details of your system and convergence
problems
(was it a metal?), but this has already happened that I could
converge
only by using PRATT with a very small mixing factor (0.05) in
case.inm.
Using TEMP instead of TETRA in case.in2 may be worth to try.

On 09.06.2022 10:15, shamik chakrabarti wrote:

Dear Wien2k users & Prof. Tran,

As I am not getting

convergence

with HSE06, I want to try reducing the Alpha from 0.25 to

0.05

using

your earlier advice. My query is:
whenever I need to change Alpha, should I need to do

clean_lapw

every

time?

Looking forward to your advice in this regard.

with regards,

--

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India
___
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] Query regarding clean_lapw

[fabien . tran]

Can you show :ENE and :DIS of the 72 iterations.

On 15.06.2022 10:55, shamik chakrabarti wrote:

Dear Prof. Blaha & Tran,

   Following your advice I have done the
followings;
(1) Use HSE06 with alpha=0.25, TEMP in case.in2c & got converged
solution.
(2) After convergence I have changed TEMP ino TETRA (without
clean_lapw) & the DIS: & ENE obtained for the 5 consecutive cycles are
as follows,

--- ENE ---
:ENE  : ** TOTAL ENERGY IN Ry = -505.54688505
:ENE  : ** TOTAL ENERGY IN Ry = -505.54426530
:ENE  : ** TOTAL ENERGY IN Ry = -505.53129501
:ENE  : ** TOTAL ENERGY IN Ry = -505.53562517
:ENE  : ** TOTAL ENERGY IN Ry = -505.53523118
--- DIS ---
:DIS  :  CHARGE DISTANCE   ( 0.0791378 for atom6 spin 2)
0.1295270
:DIS  :  CHARGE DISTANCE   ( 0.0929466 for atom6 spin 2)
0.1395017
:DIS  :  CHARGE DISTANCE   ( 0.0952392 for atom6 spin 2)
0.1425026
:DIS  :  CHARGE DISTANCE   ( 0.0985462 for atom6 spin 2)
0.1349318
:DIS  :  CHARGE DISTANCE   ( 0.0985828 for atom6 spin 2)
0.1188199

The simulation has completed 72 iterations with charge convergence &
energy convergence as follows;
CHARGE convergence:  0 0.01 .0885828
:ENERGY convergence:  0 0.0001 .00216508

Do you think it is going in the proper direction & I should wait?

with regards,

On Mon, 13 Jun 2022 at 18:01, Peter Blaha 
wrote:


Be careful and check if your calculations with   PRATT 0.05   are
really
converged and check :ENE AND :DIS

With small PRATT mixing some pseudo-convergence can happen and in
general I'd recommend PRATT mixing only for nasty cases and a couple
of
steps, before switching back to MSR1.

Am 13.06.2022 um 14:26 schrieb fabien.t...@vasp.at:

In general, the total energies that are compared need to be

obtained

with the same setting. So, all the total energies have to be

obtained

with either TETRA or TEMP.

You can try to restart with TETRA the calculation that you

converged

with TEMP (clean_lapw should not be executed after the TEMP
calculation in order to have the case.vector for restarting with
TETRA). Maybe the TETRA calculation will this time converge.

Otherwise, you would need to run the other calculations also with

TEMP.


On 12.06.2022 10:14, shamik chakrabarti wrote:

Dear Prof. Tran,

I have obtained convergence by introducing the
following parameters; alpha=0.25, mixing scheme = PRATT, mixing
parameter=0.05, TETRA instead of TEMP in case.in2.
Now, I want to compare the energy before lithiation & after
lithiation. I have obtained the energy before lithiation using

the

parameter, alpha =0.25, mixing scheme = Msr1, mixing

parameter=0.2,

TEMP in case.in2

Do you think that these two scenarios are comparable? or I may

need to

invoke the same parameters in the system before lithiation?

with regards,

On Sat, 11 Jun 2022 at 13:35, shamik chakrabarti
 wrote:


Dear Prof. Tran,

Yes the system is a metal. Do you think using
PRATT will be reasonable as Prof. Blaha once said that he would

not

play with the PRATT mixing?

with regards,

On Sat, 11 Jun 2022 at 00:40,  wrote:


If the calculation really did not seem to converge (:ENE was
oscillating
or :DIS was staying at some high value for ever) then yes it

may

be
better to delete the case.vector files with clean_lapw and
regenerate
case.clmsum in some way (with dstart or with some functional,

PBE

or
PBE+U).

I can not remember the details of your system and convergence
problems
(was it a metal?), but this has already happened that I could
converge
only by using PRATT with a very small mixing factor (0.05) in
case.inm.
Using TEMP instead of TETRA in case.in2 may be worth to try.

On 09.06.2022 10:15, shamik chakrabarti wrote:

Dear Wien2k users & Prof. Tran,

As I am not getting

convergence

with HSE06, I want to try reducing the Alpha from 0.25 to 0.05

using

your earlier advice. My query is:
whenever I need to change Alpha, should I need to do

clean_lapw

every

time?

Looking forward to your advice in this regard.

with regards,

--

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India
___
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


--

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India


--

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Tec

Re: [Wien] Query regarding clean_lapw

[fabien . tran]

In general, the total energies that are compared need to be obtained 
with the same setting. So, all the total energies have to be obtained 
with either TETRA or TEMP.


You can try to restart with TETRA the calculation that you converged 
with TEMP (clean_lapw should not be executed after the TEMP calculation 
in order to have the case.vector for restarting with TETRA). Maybe the 
TETRA calculation will this time converge.


Otherwise, you would need to run the other calculations also with TEMP.

On 12.06.2022 10:14, shamik chakrabarti wrote:

Dear Prof. Tran,

   I have obtained convergence by introducing the
following parameters; alpha=0.25, mixing scheme = PRATT, mixing
parameter=0.05, TETRA instead of TEMP in case.in2.
Now, I want to compare the energy before lithiation & after
lithiation. I have obtained the energy before lithiation using the
parameter, alpha =0.25, mixing scheme = Msr1, mixing parameter=0.2,
TEMP in case.in2

Do you think that these two scenarios are comparable? or I may need to
invoke the same parameters in the system before lithiation?

with regards,

On Sat, 11 Jun 2022 at 13:35, shamik chakrabarti
 wrote:


Dear Prof. Tran,

Yes the system is a metal. Do you think using
PRATT will be reasonable as Prof. Blaha once said that he would not
play with the PRATT mixing?

with regards,

On Sat, 11 Jun 2022 at 00:40,  wrote:


If the calculation really did not seem to converge (:ENE was
oscillating
or :DIS was staying at some high value for ever) then yes it may
be
better to delete the case.vector files with clean_lapw and
regenerate
case.clmsum in some way (with dstart or with some functional, PBE
or
PBE+U).

I can not remember the details of your system and convergence
problems
(was it a metal?), but this has already happened that I could
converge
only by using PRATT with a very small mixing factor (0.05) in
case.inm.
Using TEMP instead of TETRA in case.in2 may be worth to try.

On 09.06.2022 10:15, shamik chakrabarti wrote:

Dear Wien2k users & Prof. Tran,

As I am not getting

convergence

with HSE06, I want to try reducing the Alpha from 0.25 to 0.05

using

your earlier advice. My query is:
whenever I need to change Alpha, should I need to do clean_lapw

every

time?

Looking forward to your advice in this regard.

with regards,

--

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India
___
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


--

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India


--

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India
___
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

Re: [Wien] Query regarding clean_lapw

[fabien . tran]

If the calculation really did not seem to converge (:ENE was oscillating 
or :DIS was staying at some high value for ever) then yes it may be 
better to delete the case.vector files with clean_lapw and regenerate 
case.clmsum in some way (with dstart or with some functional, PBE or 
PBE+U).


I can not remember the details of your system and convergence problems 
(was it a metal?), but this has already happened that I could converge 
only by using PRATT with a very small mixing factor (0.05) in case.inm. 
Using TEMP instead of TETRA in case.in2 may be worth to try.


On 09.06.2022 10:15, shamik chakrabarti wrote:

Dear Wien2k users & Prof. Tran,

As I am not getting convergence
with HSE06, I want to try reducing the Alpha from 0.25 to 0.05 using
your earlier advice. My query is:
whenever I need to change Alpha, should I need to do clean_lapw every
time?

Looking forward to your advice in this regard.

with regards,

--

Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India
___
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