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 

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 

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 

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

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=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=18628=22510=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 21:16 

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

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 

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.

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
Depart

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

Re: [Wien] A basic question regarding using GGA+U approach

[Tran, Fabien]

Besides mBJ, self-consistent meta-GGA are not yet in the released WIEN2k 
versions.


From: Wien  on behalf of Peter Blaha 

Sent: Friday, February 11, 2022 8:50 AM
To: wien@zeus.theochem.tuwien.ac.at
Subject: Re: [Wien] A basic question regarding using GGA+U approach

Hmm.

Depending on the metal, a hybrid DFT calculation for the metal is as
problematic (or even more) that a LDA+U calculation.
It overestimates itinerant magnetic moments and in addition also affects
the "free-electron" like 4s electrons ...

Formation energies (voltages) with correlated electrons are always
"tricky". I think Ceder has published a lot of such calculations on
voltages including various more or less empirical "tricks".

Eventually, you may try a meta-GGA ., but this is probably also not
very good.

Best regards
Peter Blaha

Am 2/11/22 um 08:19 schrieb xavier rocquefelte:
> Dear Shamik,
>
> To my point of view using the strategy (1) is not correct. I understand
> that B will require a different treatment in ABS2 and pure B phases.
>
> You certainly has no other choice than using hybrid functional for all
> calculations ... and then you will be able to compare to the results of
> strategy (2).
>
> Best Regards
>
> Xavier
>
>
>
> On 11/02/2022 06:40, shamik chakrabarti wrote:
>> Dear Wien2k users,
>>
>>I have studied the intercalation of A in
>> BS2 to form ABS2. In this calculation, I have used Hubbard U for B in
>> BS2, and in ABS2 & I got reasonable voltage.
>> However, now I want to study the voltage corresponding to the
>> conversion reaction; ABS2 + A =2A2S +B. In this case, B is a metal &
>> hence to simulate the voltage
>> (1) Should I need to consider the energy value corresponding to GGA+U
>> approach applied to ABS2 or,
>> (2) Should I need to consider the energy value corresponding to GGA
>> approach applied to ABS2
>>
>> As A & A2S & B have been simulated using GGA.
>>
>> 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
>
> --
> 
> Professeur des Universités de Rennes 1
> Institut des Sciences Chimiques de Rennes (ISCR)
> Univ Rennes - CNRS - UMR6226, France
> https://iscr.univ-rennes1.fr/xavier-rocquefelte
> 
>
>
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:  
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

--
Peter Blaha, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300  Email: peter.bl...@tuwien.ac.at
WWW: http://www.imc.tuwien.ac  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] A basic question regarding using GGA+U approach

[Tran, Fabien]

There are certainly works reporting calculations on similar systems and for 
similar purpose as yours.
Just read a few of them to figure out which approach may be appropriate.


From: Wien  on behalf of shamik 
chakrabarti 
Sent: Friday, February 11, 2022 8:34 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] A basic question regarding using GGA+U approach

Dear Prof. Xavier,
 .  .  .  .  .  .  .  .  .  Thank you for your reply. I will follow your advice 
& go for hybrid calculation for all.

With regards,

On Fri, Feb 11, 2022, 12:49 xavier rocquefelte 
mailto:xavier.rocquefe...@univ-rennes1.fr>> 
wrote:

Dear Shamik,

To my point of view using the strategy (1) is not correct. I understand that B 
will require a different treatment in ABS2 and pure B phases.

You certainly has no other choice than using hybrid functional for all 
calculations ... and then you will be able to compare to the results of 
strategy (2).

Best Regards

Xavier



On 11/02/2022 06:40, shamik chakrabarti wrote:
Dear Wien2k users,

   I have studied the intercalation of A in BS2 to form 
ABS2. In this calculation, I have used Hubbard U for B in BS2, and in ABS2 & I 
got reasonable voltage.
However, now I want to study the voltage corresponding to the conversion 
reaction; ABS2 + A =2A2S +B. In this case, B is a metal & hence to simulate the 
voltage
(1) Should I need to consider the energy value corresponding to GGA+U approach 
applied to ABS2 or,
(2) Should I need to consider the energy value corresponding to GGA approach 
applied to ABS2

As A & A2S & B have been simulated using GGA.

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


--

Professeur des Universités de Rennes 1
Institut des Sciences Chimiques de Rennes (ISCR)
Univ Rennes - CNRS - UMR6226, France
https://iscr.univ-rennes1.fr/xavier-rocquefelte


___
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] Non-self consistent energy (not just W2k)

[Tran, Fabien]

Same with VASP (diamond with PBE):
  free energyTOTEN  =-1.21275660 eV
  free energyTOTEN  =   -18.71976229 eV
  free energyTOTEN  =   -18.82704051 eV
  free energyTOTEN  =   -18.82722009 eV
  free energyTOTEN  =   -18.82722027 eV
  free energyTOTEN  =   -18.34948885 eV
  free energyTOTEN  =   -18.18874460 eV
  free energyTOTEN  =   -18.19001031 eV
  free energyTOTEN  =   -18.19002618 eV
  free energyTOTEN  =   -18.19003899 eV
  free energyTOTEN  =   -18.19003886 eV
  free energyTOTEN  =   -18.19003886 eV


From: Wien  on behalf of Peter Blaha 

Sent: Monday, January 31, 2022 4:53 PM
To: wien@zeus.theochem.tuwien.ac.at
Subject: Re: [Wien] Non-self consistent energy (not just W2k)

In WIEN2k the total energy does not go to a minimum during scf, but even more 
negative values can occur during scf.

It would be interesting to know if this is the same in other codes or not.

grep :ene 5_default.scf
:ENE  : ** TOTAL ENERGY IN Ry =   -14900.61390837 <
:ENE  : ** TOTAL ENERGY IN Ry =   -14900.50214748
:ENE  : ** TOTAL ENERGY IN Ry =   -14900.50211022
:ENE  : ** TOTAL ENERGY IN Ry =   -14900.50200377
:ENE  : ** TOTAL ENERGY IN Ry =   -14900.50748913
:ENE  : ** TOTAL ENERGY IN Ry =   -14900.51004385
:ENE  : ** TOTAL ENERGY IN Ry =   -14900.51010217
:ENE  : ** TOTAL ENERGY IN Ry =   -14900.51073277
:ENE  : ** TOTAL ENERGY IN Ry =   -14900.51072611
:ENE  : ** TOTAL ENERGY IN Ry =   -14900.51066136
:ENE  : ** TOTAL ENERGY IN Ry =   -14900.51216359 <
:ENE  : ** TOTAL ENERGY IN Ry =   -14900.51034576
:ENE  : ** TOTAL ENERGY IN Ry =   -14900.50887600
:ENE  : ** TOTAL ENERGY IN Ry =   -14900.50840575
:ENE  : ** TOTAL ENERGY IN Ry =   -14900.50840424
:ENE  : ** TOTAL ENERGY IN Ry =   -14900.50840424 <


Am 31.01.2022 um 15:23 schrieb Laurence Marks:
In Wien2k the total energy is calculated in part from the current density, in 
part from the density of the orbitals that solve the KS equation. As such it is 
not a true variational energy except when the density is converged. [1]

For other dft codes (not wavefunction codes [2]), is it the same, e.g. Vasp, 
QE, ab-init? Responses welcome, either via the list of directly.

[1] There are technically ways one could calculate some form of variational 
energy, but it would require extra steps and to my knowledge has never looked 
useful so is not in the code.
[2] In wavefunction codes where one varies the occupancy the energy is 
typically variational I think.

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



___
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

Re: [Wien] Converging full hybrid calculation

[Tran, Fabien]

For magnetic systems the option -diaghf is not recommended; this would be a bad 
approximation.


From: Wien  on behalf of shamik 
chakrabarti 
Sent: Thursday, January 20, 2022 6:51 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Converging full hybrid calculation

Dear Prof. Tran,

My system is an antiferromagnetic semiconductor & I am 
interested in calculating voltage (obtained from ENE) & DOS. Please advice.

with regards,

On Thu, 20 Jan 2022 at 23:10, Tran, Fabien 
mailto:fabien.t...@tuwien.ac.at>> wrote:
If your system has a band gap and is nonmagnetic, and you are interested in the 
electronic structure (band structure, DOS)
then you may consider to use the option -diaghf (see user's guide for details), 
which consists of doing just one iteration on
top of a PBE calculation.


From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>
 on behalf of shamik chakrabarti 
mailto:shamik15041...@gmail.com>>
Sent: Thursday, January 20, 2022 12:13 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Converging full hybrid calculation

Dear Prof. Tran,

With alpha=0.05 we are getting maximum convergence up 
to 0.01, however, if I switch alpha=0.25 we are again getting back to the cc of 
0.1. My query is, should we consider that a maximum charge convergence of 0.1 
to 0.01 is actually achievable with full hybrid? we are getting electrochemical 
voltage well-matched with the experient with cc 0.1 to 0.01. However, whether 
DOS will be reliable?

Looking forward to your advice.

with regards,



On Tue, 18 Jan 2022 at 11:20, shamik chakrabarti 
mailto:shamik15041...@gmail.com><mailto:shamik15041...@gmail.com<mailto:shamik15041...@gmail.com>>>
 wrote:
Dear Prof. Tran,

  I have started the simulation by following your advice.

with regards,

On Tue, 18 Jan 2022 at 02:06, Tran, Fabien 
mailto:fabien.t...@tuwien.ac.at><mailto:fabien.t...@tuwien.ac.at<mailto:fabien.t...@tuwien.ac.at>>>
 wrote:
Actually, it is better to start the calculation with alpha=0.05 just after a 
PBE calculation:
1) PBE calculation
2) save_lapw PBE
3) init_hf_lapw (choose alpha=0.05 in case.inhf)
4) run_lapw -hf ...


From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at><mailto:wien-boun...@zeus.theochem.tuwien.ac.at<mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>>
 on behalf of shamik chakrabarti 
mailto:shamik15041...@gmail.com><mailto:shamik15041...@gmail.com<mailto:shamik15041...@gmail.com>>>
Sent: Monday, January 17, 2022 12:36 PM
To: A Mailing list for WIEN2k users
Subject: [Wien] Converging full hybrid calculation

Dear All,
   For converging full hybrid calculation I have done the following;

(1) Initially the simulation was running with alpha=0.25. As this parameter is 
not leading to the convergence, I have stopped it.
(2) I have executed clean_lapw to remove case.vectorhf from earlier calculation
(3) Set alpha=0.05 & started the simulation

Although I have reached the energy convergence criteria 0.0001, the charge 
convergence is oscillating around 0.01. Should I decrease alpha, even more, to 
get the charge convergence & eventually get back to alpha=0.25 at the end after 
getting the required convergence?

with regards,
[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]


--
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<mailto:Wien@zeus.theochem.tuwien.ac.at><mailto:Wien@zeus.theochem.tuwien.ac.at<mailto: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<mailto: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

Re: [Wien] Converging full hybrid calculation

[Tran, Fabien]

If your system has a band gap and is nonmagnetic, and you are interested in the 
electronic structure (band structure, DOS)
then you may consider to use the option -diaghf (see user's guide for details), 
which consists of doing just one iteration on
top of a PBE calculation.


From: Wien  on behalf of shamik 
chakrabarti 
Sent: Thursday, January 20, 2022 12:13 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Converging full hybrid calculation

Dear Prof. Tran,

With alpha=0.05 we are getting maximum convergence up 
to 0.01, however, if I switch alpha=0.25 we are again getting back to the cc of 
0.1. My query is, should we consider that a maximum charge convergence of 0.1 
to 0.01 is actually achievable with full hybrid? we are getting electrochemical 
voltage well-matched with the experient with cc 0.1 to 0.01. However, whether 
DOS will be reliable?

Looking forward to your advice.

with regards,



On Tue, 18 Jan 2022 at 11:20, shamik chakrabarti 
mailto:shamik15041...@gmail.com>> wrote:
Dear Prof. Tran,

  I have started the simulation by following your advice.

with regards,

On Tue, 18 Jan 2022 at 02:06, Tran, Fabien 
mailto:fabien.t...@tuwien.ac.at>> wrote:
Actually, it is better to start the calculation with alpha=0.05 just after a 
PBE calculation:
1) PBE calculation
2) save_lapw PBE
3) init_hf_lapw (choose alpha=0.05 in case.inhf)
4) run_lapw -hf ...


From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>
 on behalf of shamik chakrabarti 
mailto:shamik15041...@gmail.com>>
Sent: Monday, January 17, 2022 12:36 PM
To: A Mailing list for WIEN2k users
Subject: [Wien] Converging full hybrid calculation

Dear All,
   For converging full hybrid calculation I have done the following;

(1) Initially the simulation was running with alpha=0.25. As this parameter is 
not leading to the convergence, I have stopped it.
(2) I have executed clean_lapw to remove case.vectorhf from earlier calculation
(3) Set alpha=0.05 & started the simulation

Although I have reached the energy convergence criteria 0.0001, the charge 
convergence is oscillating around 0.01. Should I decrease alpha, even more, to 
get the charge convergence & eventually get back to alpha=0.25 at the end after 
getting the required convergence?

with regards,
[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]


--
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<mailto: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

Re: [Wien] Converging full hybrid calculation

[Tran, Fabien]

Actually, it is better to start the calculation with alpha=0.05 just after a 
PBE calculation:
1) PBE calculation
2) save_lapw PBE
3) init_hf_lapw (choose alpha=0.05 in case.inhf)
4) run_lapw -hf ...


From: Wien  on behalf of shamik 
chakrabarti 
Sent: Monday, January 17, 2022 12:36 PM
To: A Mailing list for WIEN2k users
Subject: [Wien] Converging full hybrid calculation

Dear All,
   For converging full hybrid calculation I have done the following;

(1) Initially the simulation was running with alpha=0.25. As this parameter is 
not leading to the convergence, I have stopped it.
(2) I have executed clean_lapw to remove case.vectorhf from earlier calculation
(3) Set alpha=0.05 & started the simulation

Although I have reached the energy convergence criteria 0.0001, the charge 
convergence is oscillating around 0.01. Should I decrease alpha, even more, to 
get the charge convergence & eventually get back to alpha=0.25 at the end after 
getting the required convergence?

with regards,
[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]


--
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] Is MBJ applicable for half metals?

[Tran, Fabien]

If you search for "half-metal" and "mbj" with google, a certain number of 
papers will be listed.


From: Wien  on behalf of shamik 
chakrabarti 
Sent: Friday, January 14, 2022 12:50 PM
To: A Mailing list for WIEN2k users
Subject: [Wien] Is MBJ applicable for half metals?

Dear Wien2k users & experts,

  Is MBJ applicable for half-metal?  For some systems, I 
have obtained half-metallic states with the GGA+U approach & they convert into 
metal after using MBJ.

Looking forward to your response 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] Oscillating convergence

[Tran, Fabien]

I forgot to mention that before restarting the HSE calculation you should have 
executed
clean_lapw to delete the possibly present case.vectorhf or case.vectorhf_from 
the old HSE
calculation. They may perturb the convergemce.


From: Wien  on behalf of shamik 
chakrabarti 
Sent: Wednesday, January 12, 2022 9:52 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Oscillating convergence

Dear Prof. Blaha & Prof. Tran,

 I have started Full HYbrid with 
alpha = 0.05 from scratch ( I have restored the GGA calculation in a new folder 
& started the Hybrid after that). Let see what will happen.
Thanks for your advice.

with regards,

On Wed, 12 Jan 2022 at 14:02, shamik chakrabarti 
mailto:shamik15041...@gmail.com>> wrote:
But with GGA+U the simulated voltage is not matching with experiment...

On Wed, 12 Jan 2022 at 14:00, Peter Blaha 
mailto:pbl...@theochem.tuwien.ac.at>> wrote:
If your present calculation "diverged", I'd restore the GGA+U calculation.

Am 12.01.2022 um 09:19 schrieb shamik chakrabarti:
> Dear Prof. Blaha,
> By grid to 0.01, I mean the mixing parameter in
> case.inm ( I change 0.2 to 0.01). For a trial can I check by reducing
> the alpha from 0.25 to 0.05 in case.inhf now? Or I need to start with
> 0.05 as alpha from the scratch?
>
> Looking forward to your reply.
>
> with regards,
>
>
> On Wed, 12 Jan 2022 at 13:38, Peter Blaha 
> mailto:pbl...@theochem.tuwien.ac.at>
> <mailto:pbl...@theochem.tuwien.ac.at<mailto:pbl...@theochem.tuwien.ac.at>>> 
> wrote:
>
> I'm not too surprised. In HSE there is not only a dependency on the
> density (which is "mixed") but also on the wave functions. This HF
> potential due to them is "mixed" with 100 %.
>
> Maybe it helps when using a small alpha at the beginning (0.05 instead
> of 0.25) for the amount of HF (case.inhf), later on increase it when
> reasonably converged.
>
> PS: I would probably not play with PRATT (except you can clearly
> decrease :DIS significantly without oszillations) and I don't know what
> you mean with:  "grid to 0.01" ???
>
> Am 12.01.2022 um 08:51 schrieb shamik chakrabarti:
>  > Dear Wien2k users,
>  >
>  >I have started a simulation of ABCO4 oxide
>  > material with 64 atomic unit cell using HSE06. However, the energy &
>  > charge convergence is oscillating between 0.08-0.008 and 0.5 -
> 0.2 for
>  > around 100 cycles. The same structure was converged using GGA+U.
> I have
>  > used 1 k-point & also change the grid to 0.01 & used PRATT for
> several
>  > cycles now. What could be the remedy?
>  >
>  > (1) Is it that we need to use more than 1 k-point for convergence
>  > (2) There is something wrong with the structure (However the same
>  > structure is converged with GGA+U)
>  >
>  > 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<mailto:Wien@zeus.theochem.tuwien.ac.at>
> 
> <mailto:Wien@zeus.theochem.tuwien.ac.at<mailto:Wien@zeus.theochem.tuwien.ac.at>>
>  > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> <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
> <http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html>
>
> --
> --
> Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
> Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
> Email: bl...@theochem.tuwien.ac.at<mailto:bl...@theochem.tuwien.ac.at>
> <mailto:bl...@theochem.tuwien.ac.at<mailto:bl...@theochem.tuwien.ac.at>>  
>   WIEN2k: http://www.wien2k.at
> <http://www.wien2k.at>
> WWW: http://www.imc.tuwien.ac.at <http://www.imc.tuwien.ac.at>
> -
> ___
> Wien mai

Re: [Wien] Oscillating convergence

[Tran, Fabien]

Do first a GGA PBE calculation, save it, and then the HSE calculation with 
alpha=0.05 and with the default case.inm (MSR1).


From: Wien  on behalf of shamik 
chakrabarti 
Sent: Wednesday, January 12, 2022 9:19 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Oscillating convergence

Dear Prof. Blaha,

   By  grid to 0.01, I mean the mixing parameter in 
case.inm ( I change 0.2 to 0.01). For a trial can I check by reducing the alpha 
from 0.25 to 0.05 in case.inhf now? Or I need to start with 0.05 as alpha from 
the scratch?

Looking forward to your reply.

with regards,



On Wed, 12 Jan 2022 at 13:38, Peter Blaha 
mailto:pbl...@theochem.tuwien.ac.at>> wrote:
I'm not too surprised. In HSE there is not only a dependency on the
density (which is "mixed") but also on the wave functions. This HF
potential due to them is "mixed" with 100 %.

Maybe it helps when using a small alpha at the beginning (0.05 instead
of 0.25) for the amount of HF (case.inhf), later on increase it when
reasonably converged.

PS: I would probably not play with PRATT (except you can clearly
decrease :DIS significantly without oszillations) and I don't know what
you mean with:  "grid to 0.01" ???

Am 12.01.2022 um 08:51 schrieb shamik chakrabarti:
> Dear Wien2k users,
>
>I have started a simulation of ABCO4 oxide
> material with 64 atomic unit cell using HSE06. However, the energy &
> charge convergence is oscillating between 0.08-0.008 and 0.5 - 0.2 for
> around 100 cycles. The same structure was converged using GGA+U. I have
> used 1 k-point & also change the grid to 0.01 & used PRATT for several
> cycles now. What could be the remedy?
>
> (1) Is it that we need to use more than 1 k-point for convergence
> (2) There is something wrong with the structure (However the same
> structure is converged with GGA+U)
>
> 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

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


--
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] qtl-cfp

[Tran, Fabien]

For some very brief explanations:
https://en.wikipedia.org/wiki/Term_symbol
https://pubs.acs.org/doi/abs/10.1021/ed075p1339


From: Wien  on behalf of Fecher, 
Gerhard 
Sent: Saturday, January 1, 2022 5:20 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] qtl-cfp

You still do not distinguish between single particle orbital angular momentum l 
(lower case) and many particle orbital angular momentum L (upper case).
You have to understand first the difference.
I suggest that you read and understand the textbook "The Theory of Atomic 
Structure and Spectra" by Robert D. Cowan or something that is similar 
comprehensive.


Happy New Year
Gerhard

DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
"I think the problem, to be quite honest with you,
is that you have never actually known what the question is."


Dr. Gerhard H. Fecher
Institut of Physics
Johannes Gutenberg - University
55099 Mainz

Von: Wien [wien-boun...@zeus.theochem.tuwien.ac.at] im Auftrag von reyhaneh 
ebrahimi [reyhanehebrahim...@gmail.com]
Gesendet: Freitag, 31. Dezember 2021 21:29
An: A Mailing list for WIEN2k users
Betreff: [Wien] qtl-cfp

Dear all Wien2k users,
 I used the "qtl" program (considering Qsplit=0 and Qsplit=1) for GdAl2 
compound to plot the density of states of f5/2 and f7/2 electrons in the 4f 
orbital of Gd ions in this compound. I considered spin-polarization and 
spin-orbit coupling and executed my calculation using PBE+U (U=5eV).
Due to the electronic configuration of Gd3 ions ([Xe] 4f7 5d1 6s2 ), we know 
that this compound is a typical pure spin system. In the other words, according 
to the Hund’s rules it has only the spin magnetic moment S = 7/2 (orbital 
moment L = 0). Therefore, about this matter that J=L+s & L-s, J should be 
equals to 7/2 in this compound. About the crystal field theory, we expected 
that it can not be seen the splitting of f5/2 and f7/2 in the density of states 
in the 4f orbital of Gd ions, as can be seen in this link: "  
https://www.mediafire.com/view/vklrkmb4cc2c5c7/crystal.jpeg/file  ". But when 
we used the "qtl" program, for Qsplit=0, we have DOSs for both f5/2 and f7/2, 
as can be seen from this link:  " 
https://www.mediafire.com/view/94j0289p08sz69c/qtl.jpg/file ". Would you please 
help me to know why the splitting of f5/2 and f7/2 electrons in the 4f orbital 
of Gd ions  in my graph accoured ?

Also when we used Qsplit=1, this program produce DOSs  for (l, ml) with l=3, as 
can be seen from this link: " 
https://www.mediafire.com/view/b6yja78pohfjn39/l%252Cml.jpg/file " While about 
the electronic configuration of Gd3+,  L should be equal to Zero not 3. Would 
you please, help me to know the difference between L which is considered in 
"qtl" program and L which is computed using Hund's rules and considered in the 
cfp program ?

Thank you very much
Sincerely yours
Reyhaneh
___
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] Continuing confusion in dos...

[Tran, Fabien]

Is the calculation converged or not, the message "energy in SCF NOT CONVERGED" 
is always
printed when only 1 or 2 iterations are done. Just check that :DIS after the 
single iteration is
reasonably small. What is the value?.

Your two DOS look different, but this may (mainly?) be due to the different 
used broadenings.


From: Wien  on behalf of shamik 
chakrabarti 
Sent: Monday, November 29, 2021 6:47 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Continuing confusion in dos...

Dear Dr. Tran,

 I have applied 4k points using the procedure as you have 
suggested. However, for one iteration with 4k points, it is coming as "the 
energy in scf is not converged". Also, the DOS looks different from 1 k points. 
I am attaching two plots here. Is it that, to get the correct DOS we have to 
run more than one iteration until the energy is converged?

Looking forward to your suggestions in this regard.

with regards,

On Sun, 28 Nov 2021 at 19:12, Tran, Fabien 
mailto:fabien.t...@tuwien.ac.at>> wrote:
The DOS will be ok.

From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>
 on behalf of shamik chakrabarti 
mailto:shamik15041...@gmail.com>>
Sent: Sunday, November 28, 2021 2:39 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Continuing confusion in dos...

Dear Dr. Tran,

   I have another confusion. In userguide it is written that  "Note 
that when -newklist is used, the total energy (:ENE in case.scf) at the 1st 
iteration is wrong"...whether that means that we can not use the value of total 
energy from this calculation, however, we can get the DOS?

with regards,

On Sun, 28 Nov 2021 at 16:18, shamik chakrabarti 
mailto:shamik15041...@gmail.com><mailto:shamik15041...@gmail.com<mailto:shamik15041...@gmail.com>>>
 wrote:
Thank you, Dr. Tran :)

On Sun, 28 Nov 2021 at 16:07, Tran, Fabien 
mailto:fabien.t...@tuwien.ac.at><mailto:fabien.t...@tuwien.ac.at<mailto:fabien.t...@tuwien.ac.at>>>
 wrote:
Just replace the old one (in $WIENROOT) by the new one. No need to recompile. 
csh/tcsh/bash scripts do not need to be compiled.


From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at><mailto:wien-boun...@zeus.theochem.tuwien.ac.at<mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>>
 on behalf of shamik chakrabarti 
mailto:shamik15041...@gmail.com><mailto:shamik15041...@gmail.com<mailto:shamik15041...@gmail.com>>>
Sent: Sunday, November 28, 2021 11:32 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Continuing confusion in dos...

How to use this script? should I copy this script in some folder (which 
folder?) in the parent directory of wien2k & recompile...I am using wien2k 19.1

On Sun, 28 Nov 2021 at 15:43, Tran, Fabien 
mailto:fabien.t...@tuwien.ac.at><mailto:fabien.t...@tuwien.ac.at<mailto:fabien.t...@tuwien.ac.at>><mailto:fabien.t...@tuwien.ac.at<mailto:fabien.t...@tuwien.ac.at><mailto:fabien.t...@tuwien.ac.at<mailto:fabien.t...@tuwien.ac.at>>>>
 wrote:
That means that this option for run_kgenhf_lapw was not yet available for the 
WIEN2k release you are using. I attached the updated run_kgenhf_lapw script.

For the DOS, you need to figure out if you really need a better k-mesh. If yes, 
then search for information about how to choose a proper one.



From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at><mailto:wien-boun...@zeus.theochem.tuwien.ac.at<mailto:wien-boun...@zeus.theochem.tuwien.ac.at>><mailto:wien-boun...@zeus.theochem.tuwien.ac.at<mailto:wien-boun...@zeus.theochem.tuwien.ac.at><mailto:wien-boun...@zeus.theochem.tuwien.ac.at<mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>>>
 on behalf of shamik chakrabarti 
mailto:shamik15041...@gmail.com><mailto:shamik15041...@gmail.com<mailto:shamik15041...@gmail.com>><mailto:shamik15041...@gmail.com<mailto:shamik15041...@gmail.com><mailto:shamik15041...@gmail.com<mailto:shamik15041...@gmail.com>>>>
Sent: Sunday, November 28, 2021 10:57 AM
To: A Mailing list for WIEN2k users
Subject: [Wien] Continuing confusion in dos...

Dear Dr. Tran,

  I have tried with the command " run_kgenhf_lapw 
-newklist" in terminal...however, it says that the option .-newklist does not 
exist.

 Hence, I have done the followings
(1) Init_hf_lapw
(2) Did not change anything in case.inhf
(3) I have put nx=2, ny=2, nz=1 & for the reduced klist, again nx=2, ny=2, nz=1
(4) Eventually run " run(sp) lapw -hf -redklist -i 1
Is it correct?

looking forward to your reply.

with regards,

--
Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technolog

Re: [Wien] Continuing confusion in dos...

[Tran, Fabien]

The DOS will be ok.

From: Wien  on behalf of shamik 
chakrabarti 
Sent: Sunday, November 28, 2021 2:39 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Continuing confusion in dos...

Dear Dr. Tran,

   I have another confusion. In userguide it is written that  "Note 
that when -newklist is used, the total energy (:ENE in case.scf) at the 1st 
iteration is wrong"...whether that means that we can not use the value of total 
energy from this calculation, however, we can get the DOS?

with regards,

On Sun, 28 Nov 2021 at 16:18, shamik chakrabarti 
mailto:shamik15041...@gmail.com>> wrote:
Thank you, Dr. Tran :)

On Sun, 28 Nov 2021 at 16:07, Tran, Fabien 
mailto:fabien.t...@tuwien.ac.at>> wrote:
Just replace the old one (in $WIENROOT) by the new one. No need to recompile. 
csh/tcsh/bash scripts do not need to be compiled.


From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>
 on behalf of shamik chakrabarti 
mailto:shamik15041...@gmail.com>>
Sent: Sunday, November 28, 2021 11:32 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Continuing confusion in dos...

How to use this script? should I copy this script in some folder (which 
folder?) in the parent directory of wien2k & recompile...I am using wien2k 19.1

On Sun, 28 Nov 2021 at 15:43, Tran, Fabien 
mailto:fabien.t...@tuwien.ac.at><mailto:fabien.t...@tuwien.ac.at<mailto:fabien.t...@tuwien.ac.at>>>
 wrote:
That means that this option for run_kgenhf_lapw was not yet available for the 
WIEN2k release you are using. I attached the updated run_kgenhf_lapw script.

For the DOS, you need to figure out if you really need a better k-mesh. If yes, 
then search for information about how to choose a proper one.



From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at><mailto:wien-boun...@zeus.theochem.tuwien.ac.at<mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>>
 on behalf of shamik chakrabarti 
mailto:shamik15041...@gmail.com><mailto:shamik15041...@gmail.com<mailto:shamik15041...@gmail.com>>>
Sent: Sunday, November 28, 2021 10:57 AM
To: A Mailing list for WIEN2k users
Subject: [Wien] Continuing confusion in dos...

Dear Dr. Tran,

  I have tried with the command " run_kgenhf_lapw 
-newklist" in terminal...however, it says that the option .-newklist does not 
exist.

 Hence, I have done the followings
(1) Init_hf_lapw
(2) Did not change anything in case.inhf
(3) I have put nx=2, ny=2, nz=1 & for the reduced klist, again nx=2, ny=2, nz=1
(4) Eventually run " run(sp) lapw -hf -redklist -i 1
Is it correct?

looking forward to your reply.

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<mailto:Wien@zeus.theochem.tuwien.ac.at><mailto:Wien@zeus.theochem.tuwien.ac.at<mailto: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<mailto: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

Re: [Wien] Continuing confusion in dos...

[Tran, Fabien]

Just replace the old one (in $WIENROOT) by the new one. No need to recompile. 
csh/tcsh/bash scripts do not need to be compiled.


From: Wien  on behalf of shamik 
chakrabarti 
Sent: Sunday, November 28, 2021 11:32 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Continuing confusion in dos...

How to use this script? should I copy this script in some folder (which 
folder?) in the parent directory of wien2k & recompile...I am using wien2k 19.1

On Sun, 28 Nov 2021 at 15:43, Tran, Fabien 
mailto:fabien.t...@tuwien.ac.at>> wrote:
That means that this option for run_kgenhf_lapw was not yet available for the 
WIEN2k release you are using. I attached the updated run_kgenhf_lapw script.

For the DOS, you need to figure out if you really need a better k-mesh. If yes, 
then search for information about how to choose a proper one.



From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>
 on behalf of shamik chakrabarti 
mailto:shamik15041...@gmail.com>>
Sent: Sunday, November 28, 2021 10:57 AM
To: A Mailing list for WIEN2k users
Subject: [Wien] Continuing confusion in dos...

Dear Dr. Tran,

  I have tried with the command " run_kgenhf_lapw 
-newklist" in terminal...however, it says that the option .-newklist does not 
exist.

 Hence, I have done the followings
(1) Init_hf_lapw
(2) Did not change anything in case.inhf
(3) I have put nx=2, ny=2, nz=1 & for the reduced klist, again nx=2, ny=2, nz=1
(4) Eventually run " run(sp) lapw -hf -redklist -i 1
Is it correct?

looking forward to your reply.

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<mailto: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

Re: [Wien] Continuing confusion in dos...

[Tran, Fabien]

That means that this option for run_kgenhf_lapw was not yet available for the 
WIEN2k release you are using. I attached the updated run_kgenhf_lapw script.

For the DOS, you need to figure out if you really need a better k-mesh. If yes, 
then search for information about how to choose a proper one.



From: Wien  on behalf of shamik 
chakrabarti 
Sent: Sunday, November 28, 2021 10:57 AM
To: A Mailing list for WIEN2k users
Subject: [Wien] Continuing confusion in dos...

Dear Dr. Tran,

  I have tried with the command " run_kgenhf_lapw 
-newklist" in terminal...however, it says that the option .-newklist does not 
exist.

 Hence, I have done the followings
(1) Init_hf_lapw
(2) Did not change anything in case.inhf
(3) I have put nx=2, ny=2, nz=1 & for the reduced klist, again nx=2, ny=2, nz=1
(4) Eventually run " run(sp) lapw -hf -redklist -i 1
Is it correct?

looking forward to your reply.

with regards,

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


run_kgenhf_lapw
Description: run_kgenhf_lapw
___
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] Confusion about DOS

[Tran, Fabien]

It would be a wrong procedure. There is no option -hf with lapw1.
"x hf -up" and "x hf -dn" after the two "x lapw1" are missing. 
Also, for a hybrid or Hartree-Fock calculation the scripts run(sp)_lapw do a few
more things (like additional "x lapw2" and some "mv" and "cp") that are 
necessary.

The correct procedure would be:
(1) save_lapw case_1kpoint
(2) run_kgenhf_lapw -newklist (for 4 kpoints)
(3) runsp_lapw -hf -newklist -i 1 (just one iteration)
(4) x lapw2 -hf -qtl -up
(5) x lapw2 -hf -qtl -dn
(6) x tetra -hf -up
(7) x tetra -hf -dn

Anyway, maybe you don't need to replot the DOS with more k-points. Your DOS 
with 1 k-point should be ok
since your cell is large.


From: Wien  on behalf of shamik 
chakrabarti 
Sent: Saturday, November 27, 2021 4:22 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Confusion about DOS

Dear Prof. Blaha,

 I have 56 atoms supercell & it is converged with one k-point. 
In this regard should I do the following;
(1) save_lapw case_1kpoint
(2) run_kgenhf_lapw   for 4 kpoints
(3) x lapw1 -hf -up
(4) x lapw1 -hf -dn
(5) x lapw2 -hf -qtl -up
(6) x lapw2 -hf -qtl -dn
(7) x tetra -hf -up
(8) x tetra -hf -dn

Looking forward to hearing from you.

with regards,


On Sat, 27 Nov 2021 at 20:40, Peter Blaha 
mailto:pbl...@theochem.tuwien.ac.at>> wrote:
> Is this a calculation with just one k-point ?
>
> Yes. It is a calculation with one k point

Then everything is clear.

Obviously, with one k-point in the BZ one cannot use the tetrahedra
method. There are no bands (E as funktion of k), but just one eigenvalue
"per band". In principle, your DOS consists of a number of
delta-functions. So tetra switches automatically to a broadening method
(Gaussian by default) with some broadening (see description of tetra and
case.int<http://case.int> in UG).
With a broadening method of course also your VBM (CBM) will be broadened
and this is what you see in the DOS.

Of course, a single k-point calculation is valid only for very large
supercells

>
>
> look into case.outputt
>
>
> Near Fermi Energy:
> case.outputtup:  0.00086   664.55  40. 0.37   0.0208
> case.outputtdn:  0.00886   851.95  46. 0.28   0.0244
>
>
> These are data without broadening and you should see how many electrons
> (integral of DOS, 3rd column) are up to EF.
>
> In addition, check out the :BAND  ranges in scf2
> You should see a correspondence of those with the DOS (in Ry).
>
> There are 217 bands
>
>   Looking forward to your response.
>
> with regards,
>
>
> Am 27.11.2021 um 14:08 schrieb shamik chakrabarti:
>  > Yes, the gap 2.875 eV is the value found from SCF. I have tried with
>  > broadening 0.001 & also with 0.000...however, it shows no
> improvement.
>  > Is it due to numerical noise & can be neglected?
>  >
>  > On Sat, 27 Nov 2021 at 18:30, Tran, Fabien
> mailto:fabien.t...@tuwien.ac.at> 
> <mailto:fabien.t...@tuwien.ac.at<mailto:fabien.t...@tuwien.ac.at>>
>  > <mailto:fabien.t...@tuwien.ac.at<mailto:fabien.t...@tuwien.ac.at>
> <mailto:fabien.t...@tuwien.ac.at<mailto:fabien.t...@tuwien.ac.at>>>> 
> wrote:
>  >
>  > Is 2.875 eV the value of :GAP in case.scf? If yes, it looks
> like if
>  > the Fermi energy
>  > is not placed correctly on the DOS, because the gap between the
>  > valence and
>  > conduction band seems to be close to 2.875 eV.
>  > Could it be due to the broadening in case.int<http://case.int>
> <http://case.int> <http://case.int <http://case.int>>? Try
>  > to execute tetra with a reduced (or no) broadening.
>  >
>  > 
>  > From: Wien 
> mailto:wien-boun...@zeus.theochem.tuwien.ac.at>
> 
> <mailto:wien-boun...@zeus.theochem.tuwien.ac.at<mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>
>  > 
> <mailto:wien-boun...@zeus.theochem.tuwien.ac.at<mailto:wien-boun...@zeus.theochem.tuwien.ac.at>
> 
> <mailto:wien-boun...@zeus.theochem.tuwien.ac.at<mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>>>
>  on behalf of
>  > shamik chakrabarti 
> mailto:shamik15041...@gmail.com>
> <mailto:shamik15041...@gmail.com<mailto:shamik15041...@gmail.com>>
>  > <mailto:shamik15041...@gmail.com<mailto:shamik15041...@gmail.com>
> <mailto:shamik15041...@gmail.com<mailto:shamik15041...@gmail.com>>>>
>  > 

Re: [Wien] Confusion about DOS

[Tran, Fabien]

Is 2.875 eV the value of :GAP in case.scf? If yes, it looks like if the Fermi 
energy
is not placed correctly on the DOS, because the gap between the valence and
conduction band seems to be close to 2.875 eV.
Could it be due to the broadening in case.int? Try to execute tetra with a 
reduced (or no) broadening.


From: Wien  on behalf of shamik 
chakrabarti 
Sent: Saturday, November 27, 2021 7:54 AM
To: A Mailing list for WIEN2k users
Subject: [Wien] Confusion about DOS

Dear Wien2k users,

   I have plotted DOS for material with converged SCF using 
HSE06. I got a bandgap of 2,875 eV. However, in the plotted DOS it can be seen 
that a small amount of DOS from the valence band is crossing the Fermi energy. 
I have attached the plot to this mail.

Is this crossing can be neglected or I should have to change some other 
parameters like broadening etc.

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] Simulation of DOS for a calculation with -hf

[Tran, Fabien]

Yes. It is written in Sec. 4.5.9 of the user's guide.

From: Wien  on behalf of shamik 
chakrabarti 
Sent: Friday, November 26, 2021 4:14 PM
To: A Mailing list for WIEN2k users
Subject: [Wien] Simulation of DOS for a calculation with -hf

Dear Wien2k users,

I have a converged SCF with full hybridization obtained 
using the command "runsp_lapw -hf -redklist -ec 0.0001 -cc 0.0001"

Now I want to simulate DOS. My query is whether the following steps are correct:

(1) x lapw2 -qtl -hf -up/dn
(2) x tetra -hf -up/dn

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

Re: [Wien] Basic question regarding mixing parameter & force optimization

[Tran, Fabien]

I think that the original question of Shamik concerns PORT, and not MSR1. In 
some cases, in particular with non-standard potentials, I could converge only 
with PORT and with a very small mixing (typically 0.02). Then, I was checking 
what happens if the calculation is restarted (after a save_lapw) with normal 
mixing scheme (MSR1 with 0.20), and in most cases (but not all) it was ok (no 
pseudo-convergence).


From: Wien  on behalf of Laurence 
Marks 
Sent: Wednesday, October 6, 2021 9:48 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Basic question regarding mixing parameter & force 
optimization

On Wed, Oct 6, 2021, 2:20 AM Tran, Fabien 
mailto:fabien.t...@tuwien.ac.at>> wrote:
0.01 should in principle leads to slower convergence, except of course if 0.2 
is too large and does not allow for convergence at all.

Sorry, but this is not how the mixing code works. The input parameter mainly 
controls the maximum unpredicted step, and small values trigger a few internal 
parameters to be more conservative. If you do "grep :MIX *.scf" you can see how 
the GREED is dynamically changing.

The commonly seen statement in dft folklore "reduce the mixing factor if it 
does not converge" is a misunderstanding of the math.

If the convergence can be achieved properly with 0.2 and 0.01, then the results 
should be identical.


From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>
 on behalf of shamik chakrabarti 
mailto:shamik15041...@gmail.com>>
Sent: Wednesday, October 6, 2021 8:29 AM
To: A Mailing list for WIEN2k users
Subject: [Wien] Basic question regarding mixing parameter & force optimization

Dear Wien2k users,

 I have few questions regarding mixing parameters & 
force optimization
(1) If we reduce the mixing parameter from 0.2 to say 0.01, whether the 
convergence will come slowly?
(2) Whether it will be accurate?
(3) If we do not get force convergence with PORT should we go for NEWT/NEW1?

Any response will be eagerly awaited.

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<mailto:Wien@zeus.theochem.tuwien.ac.at>
https://urldefense.com/v3/__http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien__;!!Dq0X2DkFhyF93HkjWTBQKhk!Hu2SdWCMGmWk7-YRYOy96bo0-6RCuS84ucxA-PrBMmDS4R9YUM23AeAocqPdSVzhyvAgUg$
SEARCH the MAILING-LIST at:  
https://urldefense.com/v3/__http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html__;!!Dq0X2DkFhyF93HkjWTBQKhk!Hu2SdWCMGmWk7-YRYOy96bo0-6RCuS84ucxA-PrBMmDS4R9YUM23AeAocqPdSVwsCn6ceg$
 small
___
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] Basic question regarding mixing parameter & force optimization

[Tran, Fabien]

0.01 should in principle leads to slower convergence, except of course if 0.2 
is too large and does not allow for convergence at all.

If the convergence can be achieved properly with 0.2 and 0.01, then the results 
should be identical.


From: Wien  on behalf of shamik 
chakrabarti 
Sent: Wednesday, October 6, 2021 8:29 AM
To: A Mailing list for WIEN2k users
Subject: [Wien] Basic question regarding mixing parameter & force optimization

Dear Wien2k users,

 I have few questions regarding mixing parameters & 
force optimization
(1) If we reduce the mixing parameter from 0.2 to say 0.01, whether the 
convergence will come slowly?
(2) Whether it will be accurate?
(3) If we do not get force convergence with PORT should we go for NEWT/NEW1?

Any response will be eagerly awaited.

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 about HSE06

[Tran, Fabien]

To be sure that the files related to the k-mesh are ok, generate them again 
with the
command "run_kgenhf_lapw". Choose 1 k-point to make the test calculation faster.
The files case.klist_ibz and case.klist_fbz should be the same and list only 
one-k -point.
Importantly,  execute "save_lapw" and "clean_lapw" before starting the 
calculation.


From: Wien  on behalf of shamik 
chakrabarti 
Sent: Friday, October 1, 2021 5:56 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Query about HSE06

case.klist_ibz is showing 8 k points..

On Fri, 1 Oct 2021 at 09:13, shamik chakrabarti 
mailto:shamik15041...@gmail.com>> wrote:
Dear Sir,
   I have set the k points now as below,
   nx =2  ny=2 nz=2
   nx=1  ny=1 nz =1

It shows case.ibz= 1 1 1 (is that mean that 1 k point has been set?)

However with this configuration, it is already 8 hrs have been passed but still 
the first cycle is running

>   hf -dn   -mode1   -redklist   -c   (06:37:58) >   hf -up   -mode1   
> -redklist   -c   (23:36:09) 74387.7u 11868.6s 7:01:48.51 340.8% 0+0k 
> 1958760+330448io 46pf+0w
>   lcore -dn (23:36:07) 2.1u 0.0s 0:02.23 96.8% 0+0k 40+26064io 0pf+0w
>   lcore -up (23:36:05) 1.4u 0.0s 0:01.77 84.7% 0+0k 82840+26064io 1pf+0w
>   lapw2 -dn -c   (23:34:50) 121.8u 72.7s 1:14.66 260.5% 0+0k 
> 364152+125984io 0pf+0w
>   lapw2 -up -c   (23:33:07) 128.4u 77.9s 1:42.97 200.4% 0+0k 40+126008io 
> 0pf+0w
>   lapw2 -dn -hf -redklist -fermi   -c   (23:33:05) 0.9u 0.0s 0:01.12 87.5% 
> 0+0k 0+20496io 0pf+0w
>   lapw2 -up -hf -redklist -fermi   -c   (23:33:03) 0.8u 0.1s 0:01.40 70.0% 
> 0+0k 264+20496io 0pf+0w
>   lapw2 -dn -fermi   -c   (23:33:00) 0.9u 0.0s 0:01.55 68.3% 0+0k 32+22432io 
> 0pf+0w
>   lapw2 -up -fermi   -c   (23:32:56) 1.0u 0.0s 0:01.92 58.8% 0+0k 32+22448io 
> 0pf+0w
>   lapw1  -dn -c (23:09:25) 3272.9u 510.3s 23:10.36 272.1% 0+0k 
> 24+1568984io 0pf+0w
>   lapw1  -up -c (22:44:03) 3283.1u 563.0s 25:21.79 252.7% 0+0k 
> 8+1568992io 0pf+0w
>   lapw1  -dn   -c (22:40:36) 428.6u 72.6s 3:26.81 242.3% 0+0k 8+287456io 
> 0pf+0w
>   lapw1  -up   -c (22:37:12) 418.3u 77.6s 3:23.86 243.2% 0+0k 16+287456io 
> 0pf+0w
>   lapw0   (22:35:38) 193.9u 0.7s 1:33.82 207.5% 0+0k 16+211872io 0pf+0w
>   lapw0 -grr (22:33:21) 243.8u 1.2s 2:17.67 178.0% 0+0k 904+731784io 0pf+0w

cycle 1 (Thu Sep 30 22:33:21 IST 2021) (400/99 to go)

start (Thu Sep 30 22:33:21 IST 2021) with lapw0 (400/99 to go)

My query is whether 1 k point has been set? and also with 1 k point it is still 
computationally expensive?
[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]

--
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

Re: [Wien] Query about HSE06

[Tran, Fabien]

It seems that the hf program can not open a file (STOP OPEN FAILED) and thus 
stops without creating vectorhfup. Then, wien2k stops when lapw2 can not find 
vectorhfup.

For the moment I suggest, to clean the directory with "save_lapw blabla" and 
"clean_lapw", and then execute again runsp_lapw -hf.
If it still does not work, then show the files case.in0, case.in0_grr, 
case.in1(c), case.inc and case.inhf.


From: Wien  on behalf of shamik 
chakrabarti 
Sent: Thursday, September 30, 2021 4:36 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Query about HSE06

The STDOUT shows the following;


hup: Command not found.
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 OPEN FAILED
STOP OPEN FAILED
At line 379 of file l2main_tmp_.F (unit = 10, file = 'LCrT_HSE06_1k.vectorhfup')
Fortran runtime error: End of file

Error termination. Backtrace:
#0  0x15286257492d in ???
#1  0x1528625754c5 in ???
#2  0x152862575cad in ???
#3  0x15286277a35b in ???
#4  0x15286277adaf in ???
#5  0x15286277ae9c in ???
#6  0x15286277d5a8 in ???
#7  0x5639b652399e in ???
#8  0x5639b652c889 in ???
#9  0x5639b64d304e in ???
#10  0x1528621b909a in ???
#11  0x5639b64d30d9 in ???
#12  0x in ???

>   stop error

On Thu, 30 Sept 2021 at 19:59, Tran, Fabien 
mailto:fabien.t...@tuwien.ac.at>> wrote:
The standard output (e.g., STDOUT) if you still have it.


From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>
 on behalf of shamik chakrabarti 
mailto:shamik15041...@gmail.com>>
Sent: Thursday, September 30, 2021 4:16 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Query about HSE06

The error file shows the error "Error in LAPW2" . should I send case.inhf

On Thu, 30 Sept 2021 at 19:44, Tran, Fabien 
mailto:fabien.t...@tuwien.ac.at><mailto:fabien.t...@tuwien.ac.at<mailto:fabien.t...@tuwien.ac.at>>>
 wrote:
It is better to show the standard output and what is written in the non-empty 
error files if any.


From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at><mailto:wien-boun...@zeus.theochem.tuwien.ac.at<mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>>
 on behalf of shamik chakrabarti 
mailto:shamik15041...@gmail.com><mailto:shamik15041...@gmail.com<mailto:shamik15041...@gmail.com>>>
Sent: Thursday, September 30, 2021 4:04 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Query about HSE06

Dear Sir,

 The SCF (with full Hybrid DFT) stops at the first cycle with the 
error
 start (Thu Sep 30 19:20:13 IST 2021) with lapw0 (400/99 to go)

cycle 1 (Thu Sep 30 19:20:13 IST 2021) (400/99 to go)

>   lapw0 -grr (19:20:13) 201.1u 0.9s 1:18.91 256.1% 0+0k 0+731760io 0pf+0w
>   lapw0   (19:21:32) 167.0u 0.6s 0:56.97 294.3% 0+0k 0+211856io 0pf+0w
>   lapw1  -up -c (19:22:29) 277.6u 21.4s 1:19.85 374.5% 0+0k 32+171728io 
> 0pf+0w
>   lapw1  -dn -c (19:23:49) 338.3u 48.0s 2:00.62 320.3% 0+0k 32+171728io 
> 0pf+0w
>   lapw2 -up -fermi   -c   (19:25:50) 0.9u 0.0s 0:01.18 83.8% 0+0k 16+20232io 
> 0pf+0w
>   lapw2 -dn -fermi   -c   (19:25:52) 0.9u 0.0s 0:00.97 103.0% 0+0k 0+20240io 
> 0pf+0w
>   lapw2 -up -c   (19:25:53) 19.0u 7.6s 0:11.34 235.8% 0+0k 8+124800io 
> 0pf+0w
>   lapw2 -dn -c   (19:26:05) 17.9u 8.5s 0:12.02 220.4% 0+0k 0+124792io 
> 0pf+0w
>   lcore -up (19:26:17) 2.3u 0.0s 0:02.82 84.7% 0+0k 32+26072io 0pf+0w
>   lcore -dn (19:26:20) 2.2u 0.0s 0:02.76 82.6% 0+0k 8+26064io 0pf+0w
>   hf -up   -mode1  -c   (19:26:23) 0.0u 0.0s 0:00.05 0.0% 0+0k 2944+8io 
> 7pf+0w
>   hf -dn   -mode1  -c   (19:26:24) 0.0u 0.0s 0:00.02 0.0% 0+0k 0+8io 
> 0pf+0w
>   lapw2 -up -hf-c   (19:26:24) 0.8u 0.0s 0:01.09 87.1% 0+0k 6120+20200io 
> 13pf+0w
error: command   /usr/local/Wien2k/lapw2c uplapw2.def   failed

>   stop error

I am attaching the struct file here with this mail. I am using 1k point 
initially for testing.

Looking forward to your advice.

with regards,.

On Thu, 30 Sept 2021 at 16:43, Peter Blaha 
mailto:pbl...@theochem.tuwien.ac.at><mailto:pbl...@theochem.tuwien.ac.at<mailto:pbl...@theochem.tuwien.ac.at>><mailto:pbl...@theochem.tuwien.ac.at<mailto:pbl...@theochem.tuwien.ac.at><mailto:pbl...@theochem.tuwien.ac.at<mailto:pbl...@theochem.tuwien.ac.at>>>>
 wrote:
And the manual says: use "AT LEAST" nband+1; but the recommendation is
for sure to use some more, eg. 10 % more !!

Am 9/30/21 um 1:09 PM schrieb Tran, Fabien:
> The steps are correct. The number of occupied bands is indicated in case.scf 
> (:BAN).
> nband is a parameter like RKmax that has to be tested for convergence.
>
> ___

Re: [Wien] Query about HSE06

[Tran, Fabien]

The standard output (e.g., STDOUT) if you still have it.


From: Wien  on behalf of shamik 
chakrabarti 
Sent: Thursday, September 30, 2021 4:16 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Query about HSE06

The error file shows the error "Error in LAPW2" . should I send case.inhf

On Thu, 30 Sept 2021 at 19:44, Tran, Fabien 
mailto:fabien.t...@tuwien.ac.at>> wrote:
It is better to show the standard output and what is written in the non-empty 
error files if any.


From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>
 on behalf of shamik chakrabarti 
mailto:shamik15041...@gmail.com>>
Sent: Thursday, September 30, 2021 4:04 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Query about HSE06

Dear Sir,

 The SCF (with full Hybrid DFT) stops at the first cycle with the 
error
 start (Thu Sep 30 19:20:13 IST 2021) with lapw0 (400/99 to go)

cycle 1 (Thu Sep 30 19:20:13 IST 2021) (400/99 to go)

>   lapw0 -grr (19:20:13) 201.1u 0.9s 1:18.91 256.1% 0+0k 0+731760io 0pf+0w
>   lapw0   (19:21:32) 167.0u 0.6s 0:56.97 294.3% 0+0k 0+211856io 0pf+0w
>   lapw1  -up -c (19:22:29) 277.6u 21.4s 1:19.85 374.5% 0+0k 32+171728io 
> 0pf+0w
>   lapw1  -dn -c (19:23:49) 338.3u 48.0s 2:00.62 320.3% 0+0k 32+171728io 
> 0pf+0w
>   lapw2 -up -fermi   -c   (19:25:50) 0.9u 0.0s 0:01.18 83.8% 0+0k 16+20232io 
> 0pf+0w
>   lapw2 -dn -fermi   -c   (19:25:52) 0.9u 0.0s 0:00.97 103.0% 0+0k 0+20240io 
> 0pf+0w
>   lapw2 -up -c   (19:25:53) 19.0u 7.6s 0:11.34 235.8% 0+0k 8+124800io 
> 0pf+0w
>   lapw2 -dn -c   (19:26:05) 17.9u 8.5s 0:12.02 220.4% 0+0k 0+124792io 
> 0pf+0w
>   lcore -up (19:26:17) 2.3u 0.0s 0:02.82 84.7% 0+0k 32+26072io 0pf+0w
>   lcore -dn (19:26:20) 2.2u 0.0s 0:02.76 82.6% 0+0k 8+26064io 0pf+0w
>   hf -up   -mode1  -c   (19:26:23) 0.0u 0.0s 0:00.05 0.0% 0+0k 2944+8io 
> 7pf+0w
>   hf -dn   -mode1  -c   (19:26:24) 0.0u 0.0s 0:00.02 0.0% 0+0k 0+8io 
> 0pf+0w
>   lapw2 -up -hf-c   (19:26:24) 0.8u 0.0s 0:01.09 87.1% 0+0k 6120+20200io 
> 13pf+0w
error: command   /usr/local/Wien2k/lapw2c uplapw2.def   failed

>   stop error

I am attaching the struct file here with this mail. I am using 1k point 
initially for testing.

Looking forward to your advice.

with regards,.

On Thu, 30 Sept 2021 at 16:43, Peter Blaha 
mailto:pbl...@theochem.tuwien.ac.at><mailto:pbl...@theochem.tuwien.ac.at<mailto:pbl...@theochem.tuwien.ac.at>>>
 wrote:
And the manual says: use "AT LEAST" nband+1; but the recommendation is
for sure to use some more, eg. 10 % more !!

Am 9/30/21 um 1:09 PM schrieb Tran, Fabien:
> The steps are correct. The number of occupied bands is indicated in case.scf 
> (:BAN).
> nband is a parameter like RKmax that has to be tested for convergence.
>
> 
> From: Wien 
> mailto:wien-boun...@zeus.theochem.tuwien.ac.at><mailto:wien-boun...@zeus.theochem.tuwien.ac.at<mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>>
>  on behalf of shamik chakrabarti 
> mailto:shamik15041...@gmail.com><mailto:shamik15041...@gmail.com<mailto:shamik15041...@gmail.com>>>
> Sent: Thursday, September 30, 2021 12:56 PM
> To: A Mailing list for WIEN2k users
> Subject: Re: [Wien] Query about HSE06
>
> Dear Prof. Tran,
>
>  I am describing the steps to run HSE06 below. Please correct 
> me if I am wrong.
> (1) Run a spin-polarized SCF with GGA.
> (2) Save_lapw
> (3) init_hf_lapw
> (4) edit case.inhf to put the no. of bands at nband. The value of nband 
> should be the number of occupied bands+1. But how to know the number of 
> occupied bands?
> (5) runsp_lapw -hf
>
> Are these the correct sequence?
>
> with regards,
>
> On Wed, 29 Sept 2021 at 18:49, Tran, Fabien 
> mailto:fabien.t...@tuwien.ac.at><mailto:fabien.t...@tuwien.ac.at<mailto:fabien.t...@tuwien.ac.at>><mailto:fabien.t...@tuwien.ac.at<mailto:fabien.t...@tuwien.ac.at><mailto:fabien.t...@tuwien.ac.at<mailto:fabien.t...@tuwien.ac.at>>>>
>  wrote:
> Hybrid functionals can be used to calculate the shape of the unit cell 
> (lattice
> constants and angles), but not the position of atoms (the forces are not
> implemented for hybrids).
>
> How to prepare and run a calculation with hybrids is explained in sections
> 4.5.9 and 7.7 of the user's guide.
>
> 
> From: Tran, Fabien
> Sent: Wednesday, September 29, 2021 3:10 PM
> To: Tran, Fabien
> Subject: [Wien] Query about HSE06
>
> Dear Wien2k users,
>
>I want to use HSE06 for an oxide material. From
> the mailing list, I have come

Re: [Wien] Query about HSE06

[Tran, Fabien]

It is better to show the standard output and what is written in the non-empty 
error files if any.


From: Wien  on behalf of shamik 
chakrabarti 
Sent: Thursday, September 30, 2021 4:04 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Query about HSE06

Dear Sir,

 The SCF (with full Hybrid DFT) stops at the first cycle with the 
error
 start (Thu Sep 30 19:20:13 IST 2021) with lapw0 (400/99 to go)

cycle 1 (Thu Sep 30 19:20:13 IST 2021) (400/99 to go)

>   lapw0 -grr (19:20:13) 201.1u 0.9s 1:18.91 256.1% 0+0k 0+731760io 0pf+0w
>   lapw0   (19:21:32) 167.0u 0.6s 0:56.97 294.3% 0+0k 0+211856io 0pf+0w
>   lapw1  -up -c (19:22:29) 277.6u 21.4s 1:19.85 374.5% 0+0k 32+171728io 
> 0pf+0w
>   lapw1  -dn -c (19:23:49) 338.3u 48.0s 2:00.62 320.3% 0+0k 32+171728io 
> 0pf+0w
>   lapw2 -up -fermi   -c   (19:25:50) 0.9u 0.0s 0:01.18 83.8% 0+0k 16+20232io 
> 0pf+0w
>   lapw2 -dn -fermi   -c   (19:25:52) 0.9u 0.0s 0:00.97 103.0% 0+0k 0+20240io 
> 0pf+0w
>   lapw2 -up -c   (19:25:53) 19.0u 7.6s 0:11.34 235.8% 0+0k 8+124800io 
> 0pf+0w
>   lapw2 -dn -c   (19:26:05) 17.9u 8.5s 0:12.02 220.4% 0+0k 0+124792io 
> 0pf+0w
>   lcore -up (19:26:17) 2.3u 0.0s 0:02.82 84.7% 0+0k 32+26072io 0pf+0w
>   lcore -dn (19:26:20) 2.2u 0.0s 0:02.76 82.6% 0+0k 8+26064io 0pf+0w
>   hf -up   -mode1  -c   (19:26:23) 0.0u 0.0s 0:00.05 0.0% 0+0k 2944+8io 
> 7pf+0w
>   hf -dn   -mode1  -c   (19:26:24) 0.0u 0.0s 0:00.02 0.0% 0+0k 0+8io 
> 0pf+0w
>   lapw2 -up -hf-c   (19:26:24) 0.8u 0.0s 0:01.09 87.1% 0+0k 6120+20200io 
> 13pf+0w
error: command   /usr/local/Wien2k/lapw2c uplapw2.def   failed

>   stop error

I am attaching the struct file here with this mail. I am using 1k point 
initially for testing.

Looking forward to your advice.

with regards,.

On Thu, 30 Sept 2021 at 16:43, Peter Blaha 
mailto:pbl...@theochem.tuwien.ac.at>> wrote:
And the manual says: use "AT LEAST" nband+1; but the recommendation is
for sure to use some more, eg. 10 % more !!

Am 9/30/21 um 1:09 PM schrieb Tran, Fabien:
> The steps are correct. The number of occupied bands is indicated in case.scf 
> (:BAN).
> nband is a parameter like RKmax that has to be tested for convergence.
>
> 
> From: Wien 
> mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>
>  on behalf of shamik chakrabarti 
> mailto:shamik15041...@gmail.com>>
> Sent: Thursday, September 30, 2021 12:56 PM
> To: A Mailing list for WIEN2k users
> Subject: Re: [Wien] Query about HSE06
>
> Dear Prof. Tran,
>
>  I am describing the steps to run HSE06 below. Please correct 
> me if I am wrong.
> (1) Run a spin-polarized SCF with GGA.
> (2) Save_lapw
> (3) init_hf_lapw
> (4) edit case.inhf to put the no. of bands at nband. The value of nband 
> should be the number of occupied bands+1. But how to know the number of 
> occupied bands?
> (5) runsp_lapw -hf
>
> Are these the correct sequence?
>
> with regards,
>
> On Wed, 29 Sept 2021 at 18:49, Tran, Fabien 
> mailto:fabien.t...@tuwien.ac.at><mailto:fabien.t...@tuwien.ac.at<mailto:fabien.t...@tuwien.ac.at>>>
>  wrote:
> Hybrid functionals can be used to calculate the shape of the unit cell 
> (lattice
> constants and angles), but not the position of atoms (the forces are not
> implemented for hybrids).
>
> How to prepare and run a calculation with hybrids is explained in sections
> 4.5.9 and 7.7 of the user's guide.
>
> 
> From: Tran, Fabien
> Sent: Wednesday, September 29, 2021 3:10 PM
> To: Tran, Fabien
> Subject: [Wien] Query about HSE06
>
> Dear Wien2k users,
>
>I want to use HSE06 for an oxide material. From
> the mailing list, I have come to know that HSE06 can not be used for
> structural optimization & the optimized structure has to be obtained from
> GGA. Please correct me if I am wrong.
>
> My query is how to set up the case.inhf file for running HSE06?  On page
> 136 of the user guide it is written that Lambda=0.165 bohr-1, the results
> are very close to that for HSE06. But what is the proper format of the
> input file to use HSE06?
>
> Any response is eagerly awaited.
>
> 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<mailto:Wien@zeus.theochem.tuwien.ac.at><mailto:Wien@zeus.theochem.tuwien.ac.at<mailto:Wien@zeus.theochem.tuwien.ac.at>>
> http://zeus.theochem.tuwien.ac.

Re: [Wien] Query about HSE06

[Tran, Fabien]

The steps are correct. The number of occupied bands is indicated in case.scf 
(:BAN).
nband is a parameter like RKmax that has to be tested for convergence.


From: Wien  on behalf of shamik 
chakrabarti 
Sent: Thursday, September 30, 2021 12:56 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Query about HSE06

Dear Prof. Tran,

I am describing the steps to run HSE06 below. Please correct me 
if I am wrong.
(1) Run a spin-polarized SCF with GGA.
(2) Save_lapw
(3) init_hf_lapw
(4) edit case.inhf to put the no. of bands at nband. The value of nband should 
be the number of occupied bands+1. But how to know the number of occupied bands?
(5) runsp_lapw -hf

Are these the correct sequence?

with regards,

On Wed, 29 Sept 2021 at 18:49, Tran, Fabien 
mailto:fabien.t...@tuwien.ac.at>> wrote:
Hybrid functionals can be used to calculate the shape of the unit cell (lattice
constants and angles), but not the position of atoms (the forces are not
implemented for hybrids).

How to prepare and run a calculation with hybrids is explained in sections
4.5.9 and 7.7 of the user's guide.


From: Tran, Fabien
Sent: Wednesday, September 29, 2021 3:10 PM
To: Tran, Fabien
Subject: [Wien] Query about HSE06

Dear Wien2k users,

  I want to use HSE06 for an oxide material. From
the mailing list, I have come to know that HSE06 can not be used for
structural optimization & the optimized structure has to be obtained from
GGA. Please correct me if I am wrong.

My query is how to set up the case.inhf file for running HSE06?  On page
136 of the user guide it is written that Lambda=0.165 bohr-1, the results
are very close to that for HSE06. But what is the proper format of the
input file to use HSE06?

Any response is eagerly awaited.

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<mailto: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

Re: [Wien] Query about HSE06

[Tran, Fabien]

Hybrid functionals can be used to calculate the shape of the unit cell (lattice
constants and angles), but not the position of atoms (the forces are not
implemented for hybrids).

How to prepare and run a calculation with hybrids is explained in sections
4.5.9 and 7.7 of the user's guide.


From: Tran, Fabien
Sent: Wednesday, September 29, 2021 3:10 PM
To: Tran, Fabien
Subject: [Wien] Query about HSE06

Dear Wien2k users,

  I want to use HSE06 for an oxide material. From
the mailing list, I have come to know that HSE06 can not be used for
structural optimization & the optimized structure has to be obtained from
GGA. Please correct me if I am wrong.

My query is how to set up the case.inhf file for running HSE06?  On page
136 of the user guide it is written that Lambda=0.165 bohr-1, the results
are very close to that for HSE06. But what is the proper format of the
input file to use HSE06?

Any response is eagerly awaited.

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] Increase points in klist_band

[Tran, Fabien]

As far as I know, regenerate klist_band with xcrysden is the only way.

From: Wien  on behalf of Wahid Kamal 

Sent: Sunday, September 26, 2021 7:20 PM
To: A Mailing list for WIEN2k users
Subject: [Wien] Increase points in klist_band

Dear Wien2k users,
is there a way to increase the k-points in the klist_band file or we have to 
generate the path again with xcrysden.
___
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] mBJ+SOC

[Tran, Fabien]

Both ways should in principle lead to exactly the same results, except maybe 
for systems like FeO with multiple low energy local minima.

May?be the first way would in total require less iterations, since only one mBJ 
calculation is needed (mBJ converges faster than PBE).



From: Wien  on behalf of Wahid Kamal 

Sent: Tuesday, September 14, 2021 8:15 PM
To: A Mailing list for WIEN2k users
Subject: [Wien] mBJ+SOC

Dear Wien2k users,
For mBJ+SOC calculation, should I start with a SOC calculation (with PBE) and 
then I continue with mBJ (init_mbj and scf with -so) or else I have to start 
with an scf with mBJ (without SOC) then I continue with SOC (init_so)?
Thank you
___
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] Error in x tetra

[Tran, Fabien]

Your list of partial DOSs is too large (>51). You probably don't need to plot 
s,p,d,f for all atoms.?



From: Wien  on behalf of Peeyush Kumar 
Kamlesh 
Sent: Tuesday, September 7, 2021 12:18 PM
To: wien-requ...@zeus.theochem.tuwien.ac.at; wien@zeus.theochem.tuwien.ac.at
Subject: [Wien] Error in x tetra

Dear Sir,
Greetings of the day!
I am running a case of 13 different atomic positions and calculating DoS. I run
total 1 tot,s,p,d,f 2 tot,s,p,d,f 3 tot,s,p,d,f 4 tot,s,p,d,f 5 tot,s,p,d,f 6 
tot,s,p,d,f 7 tot,s,p,d,f 8 tot,s,p,d,f 9 tot,s,p,d,f 10 tot,s,p,d,f 11 
tot,s,p,d,f 12 tot,s,p,d,f 13 tot,s,p,d,f
command to configure case.int file. After that when I run x 
tetra, then is shows

mg too small, TETRA does not support more the 51 cases
0.0u 0.0s 0:00.00 0.0% 0+0k 0+0io 0pf+0w


I am unable to understand why is it showing this error?

Kindly tell me the solution.


Thanks and Regards

Peeyush Kumar Kamlesh
___
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] Severe bug with MGGA when using Libxc

[Tran, Fabien]

Dear WIEN2k users,

In WIEN2k_21 there is a severe bug when MGGA functionals from Libxc are used 
(this is a bug in
WIEN2k and not in Libxc).

The self-consistent implementation of MGGA functionals is not yet available in 
WIEN2k, therefore
a GGA is used for the potential. The problem is that when a Libxc keyword of a 
MGGA (e.g., SCAN)
in case.in0 is used without specifying the GGA potential:

TOT XC_MGGA_X_SCAN XC_MGGA_C_SCAN (XC_LDA,XC_PBESOL,XC_WC,XC_MBJ,XC_SCAN)

then all results (total energy, band structure, etc.) will be wrong. To obtain 
the correct results it is
necessary to specify explicitly the GGA (e.g., PBE) potential:

TOT XC_MGGA_X_SCAN XC_MGGA_C_SCAN VX_PBE VC_PBE 
(XC_LDA,XC_PBESOL,XC_WC,XC_MBJ,XC_SCAN)

Using the original WIEN2k keywords is no problem even when the GGA potential is 
not specified. Therefore,

TOT XC_SCAN (XC_LDA,XC_PBESOL,XC_WC,XC_MBJ,XC_SCAN)
and
TOT EX_SCAN EC_SCAN VX_PBE VC_PBE (XC_LDA,XC_PBESOL,XC_WC,XC_MBJ,XC_SCAN)

will both produce the correct results.

We will try to provide a bug fix as soon as possible.

FT
___
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] Confusion regarding supercell calculation

[Tran, Fabien]

?The peaks in the png look indeed a bit strange. We can not have access to the 
eps file.



From: Wien  on behalf of Anupriya 
Nyayban 
Sent: Saturday, July 17, 2021 3:28 PM
To: wien@zeus.theochem.tuwien.ac.at
Subject: Re: [Wien] Confusion regarding supercell calculation

Dear Prof. Tran,
I have found the discrepancy  in bandstructure plot (batchband.png) when it is 
plotted in batch mode. There is a sharp peak along X to S, which seems to 
overlap with the previous levels. But I could see there is no overlap (which I 
expect) after analyzing and plotting (plotband.eps) the "case.spaghetti_ene" 
file. Both the files I have shared here via google drive link. I am confused 
why this has happened!
Additionally. I am curious to know when should we use the unfolding of the 
bandstructure?


https://drive.google.com/file/d/1oc2skbk1Vfa28OGaodlWtwXP_Z8F6HDc/view?usp=sharing

https://drive.google.com/file/d/1IuOxHlNdrOaNXaVnoFz1RC1C5Z74U8Yv/view?usp=sharing

--
With regards
Anupriya Nyayban
Ph.D. Scholar
Department of Physics
NIT Silchar
___
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] Confusion regarding supercell calculation

[Tran, Fabien]

Hi,


For which reason does your band structure look odd? Did you know in advance how 
it would look like? Is it metallic, while you expected a band gap??



From: Wien  on behalf of Anupriya 
Nyayban 
Sent: Friday, July 16, 2021 1:16 PM
To: wien@zeus.theochem.tuwien.ac.at
Subject: Re: [Wien] Confusion regarding supercell calculation

Dear experts and users,

I have run the bandstructure calculation with a total k of 100 for a 2*2*2 
supercell with the following steps:
1) created case.klist_band (along ?XSY?ZURTZ)
2) x lapw1 -band
3) x lapw2 -band -qtl
4) edited the case.insp with Fermi energy value
5) x spaghetti
After plotting the bandstructure, I have found that there is a overlapping of 
different states and it looks very odd. Do I miss something or unfolding of the 
bandstructure could be a solution?
Looking forward to hearing from you.

--
With regards
Anupriya Nyayban
Ph.D. Scholar
Department of Physics
NIT Silchar
___
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] Confusion regarding supercell calculation

[Tran, Fabien]

Hi,


By visualizing the struct file (with xcrysden or vesta) you can figure out if 
the structure is the one that you wanted.



From: Wien  on behalf of Anupriya 
Nyayban 
Sent: Wednesday, June 23, 2021 9:48 AM
To: wien@zeus.theochem.tuwien.ac.at
Subject: [Wien] Confusion regarding supercell calculation

Dear experts and users,

I am going to study a system of AB0.5C0.5X3. At first, the optimized struct 
file of orthorhombic ABX3 (space group =Pnma, inequivalent atom=5, total 
atoms=20) has been considered to make a 2*2*2 supercell using "supercell" (in 
single program). I have taken that super.struct file to a new folder and edited 
the struct file by replacing two inequivalent B atoms with two C atoms, then 
started the initialization-calculation after saving the struct file. During the 
initilization process,  nn program gives an warning "mult not equal" and 
suggest a new struct file. I have chosen that and observed a warning "unit cell 
has been reduced" after the sgroup run and it suggests a new struct file with 
space group 11-P21/m (inequivalent atms=40, total atom=80). I couldn't find any 
error after accepting this struct file. I am new to supercell calculation and 
want to confirm whether the structure is okay or not before proceeding further. 
Kindly suggest me if I miss something!!

Thank you!!



--
With regards
Anupriya Nyayban
Ph.D. Scholar
Department of Physics
NIT Silchar
___
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] Problem understanding number of electrons

[Tran, Fabien]

Hi,


NE in case.in2(c) does not include the core electrons. In case.inc or case.scf 
you can see what are the core electrons.?



From: Wien  on behalf of BUSHRA SABIR 

Sent: Monday, June 21, 2021 8:11 PM
To: wien@zeus.theochem.tuwien.ac.at
Subject: [Wien] Problem understanding number of electrons

Hi Wien2k experts ,

I am working with CoGe (Bulk), while doing virtual crystal approximation. i 
need to change NE in case.in2c file.
In case.in2c file it has 116 electrons.
I am unable to understand how software count it 116 electrons.
For 27(Co)+32(Ge) *4 = 236 (since structure has 4 multiplicity with Co and Ge)
or
3d10 4s2 4p2= 14(Ge) and 3d7+4s2=9(Co) it makes 23*4=92

Can anyone help me how can it will be 116.

Bushra Sabir






[http://mail.yimg.com/us.yimg.com/i/mesg/tsmileys2/01.gif]

___
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] Correlation energy in DFT+U

[Tran, Fabien]

Technically, a DFT+U calculation can only be run with runsp_lapw (or 
runsp_c_lapw
to constrain the magnetic moment to be zero). Whatever is the version of DFT+U
that you use, the results should be technically ok. The question is more which 
DFT+U
version is the most appropriate for the physics for your system. This paper 
provides
a very good summary:
https://journals.aps.org/prb/abstract/10.1103/PhysRevB.79.035103


From: Wien  on behalf of Lorenzo 
Mariano 
Sent: Saturday, June 12, 2021 11:56 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Correlation energy in DFT+U

Thanks a lot, now it is clear.

A last question concerning the use of the "Mean field Hubbard model" (nldau=2). 
In the file vldau.f it is specified that this implementation of DFT+U has to be 
used with LDA and not LSDA. Despite that, I can run spin-polarized calculation 
with this DFT+U flavor and the code does not complain. In addition, in the 
vldau.f file, the MFH method seems to be implemented for spin-polarized 
calculations.
Could you please tell me if it makes sense to run a spin-polarized calculation 
with nldau=2 and if yes how can I do that properly?

Thanks again,

Lorenzo
- Mail original -
De: "Tran, Fabien" 
À: "A Mailing list for WIEN2k users" 
Envoyé: Vendredi 11 Juin 2021 22:44:10
Objet: Re: [Wien] Correlation energy in DFT+U

Hi,

Your value (U/2)Tr[n_(m,sigma)(1-n_(m,sigma)] = 0.0546 Ry for sigma=up is 
correct.
I could see that it is only for the sum of the two spins that there is equality:
(U/2)Tr[n_(m,up)(1-n_(m,up)] + (U/2)Tr[n_(m,down)(1-n_(m,down)] = Eldau(up) - 
0.5Edc(up) + Eldau(down) - 0.5Edc(down)
where Eldau and Edc are printed in case.outputorbup/dn. Edc is the same for 
both spins because it is the sum of both spins.



From: Wien  on behalf of Tran, Fabien 

Sent: Friday, June 11, 2021 7:49 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Correlation energy in DFT+U

For sure Ecorr = 2.71166 Ry is not what you want. As I wrote previously, you 
have
to remove trdmv: Ecorr-trdmv=1.59348 Ry, because I think that Eldau and Edc/2 
correspond to
E^ee(n) and E^dc(n), respectively.

I don't fully understand your formula (U/2) sum_(m,sigma) 
Tr[n_(m,sigma)(1-n_(m,sigma)] .
It is not possible to have at the same time a sum over m and a trace.


From: Wien  on behalf of Lorenzo 
Mariano 
Sent: Friday, June 11, 2021 4:09 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Correlation energy in DFT+U

Hi,

thanks a lot for the reference where the DFT+U implementation in the FLAPW 
framework is very well explained. However, I still have some doubts. The 
quantity that I want to obtain is the term E^ee(n)-E^dc(n) that appears in 
eq.1. Following  
https://journals.aps.org/prb/abstract/10.1103/PhysRevB.50.16861 this term 
should correspond to eq.8 that in the rotationally invariant formulation is 
given by (U/2) sum_(m,sigma) Tr[n_(m,sigma)(1-n_(m,sigma)] (always considering 
J=0). This term in the specific NiO calculation that I reported is, for 
sigma=up, ~ 0.0546 Ry.  This value does not correspond to the reported E_corr = 
2.71166 Ry. Is what I am saying correct or I missed something?

Best regards,

Lorenzo

- Mail original -
De: "Tran, Fabien" 
À: "A Mailing list for WIEN2k users" 
Envoyé: Vendredi 11 Juin 2021 13:45:06
Objet: Re: [Wien] Correlation energy in DFT+U

Hi,

In this paper
https://journals.aps.org/prb/abstract/10.1103/PhysRevB.60.10763
there is Eq. (24), which should correspond to
Ecorr = Eldau - Edc/2.d0 - trdmv
in the file vldau.f in the directory SRC_orb. If this is right, then the 
quantity that you want is
Eldau - Edc/2.d0 = 8.38769-13.58842/2 = 1.59348 Ry
where Eldau and Edc are also printed in case.outputorbup


From: Wien  on behalf of Lorenzo 
Mariano 
Sent: Friday, June 11, 2021 12:43 PM
To: A Mailing list for WIEN2k users
Subject: [Wien] Correlation energy in DFT+U

Dear wien2k users,

I am running some DFT+U calculation on NiO compound following instruction 
reported in this series of exercises: 
http://susi.theochem.tuwien.ac.at/reg_user/textbooks/WIEN2k_lecture-notes_2013/Exercises_13.pdf,
 execise 7. I would like to obtain the correlation  energy contribution 
(E_corr) to the total DFT+U energy: E_DFT+U(rho) = E_DFT(rho) + E_corr.
Because I am using the 'SIC method' for the expression of the double counting 
term with J=0, I expect that E_corr= (U/2) sum_(m,sigma) 
Tr[n_(m,sigma)(1-n_(m,sigma)]. I calculated this term for the spin up channel 
(sigma=up) of the first Ni atom starting from  the density matrix reported in 
case.scfdmup (attached the NiO.scfdmup file). With U=0.514 Ry the calculated 
correlation energy is ~ 0.0546 Ry. This value does not correspond to the one 
reported in the case.outputorbup file (attached the NiO.outputorbup file).
I know that in wien2k

Re: [Wien] Correlation energy in DFT+U

[Tran, Fabien]

Hi,

Your value (U/2)Tr[n_(m,sigma)(1-n_(m,sigma)] = 0.0546 Ry for sigma=up is 
correct.
I could see that it is only for the sum of the two spins that there is equality:
(U/2)Tr[n_(m,up)(1-n_(m,up)] + (U/2)Tr[n_(m,down)(1-n_(m,down)] = Eldau(up) - 
0.5Edc(up) + Eldau(down) - 0.5Edc(down)
where Eldau and Edc are printed in case.outputorbup/dn. Edc is the same for 
both spins because it is the sum of both spins.



From: Wien  on behalf of Tran, Fabien 

Sent: Friday, June 11, 2021 7:49 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Correlation energy in DFT+U

For sure Ecorr = 2.71166 Ry is not what you want. As I wrote previously, you 
have
to remove trdmv: Ecorr-trdmv=1.59348 Ry, because I think that Eldau and Edc/2 
correspond to
E^ee(n) and E^dc(n), respectively.

I don't fully understand your formula (U/2) sum_(m,sigma) 
Tr[n_(m,sigma)(1-n_(m,sigma)] .
It is not possible to have at the same time a sum over m and a trace.


From: Wien  on behalf of Lorenzo 
Mariano 
Sent: Friday, June 11, 2021 4:09 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Correlation energy in DFT+U

Hi,

thanks a lot for the reference where the DFT+U implementation in the FLAPW 
framework is very well explained. However, I still have some doubts. The 
quantity that I want to obtain is the term E^ee(n)-E^dc(n) that appears in 
eq.1. Following  
https://journals.aps.org/prb/abstract/10.1103/PhysRevB.50.16861 this term 
should correspond to eq.8 that in the rotationally invariant formulation is 
given by (U/2) sum_(m,sigma) Tr[n_(m,sigma)(1-n_(m,sigma)] (always considering 
J=0). This term in the specific NiO calculation that I reported is, for 
sigma=up, ~ 0.0546 Ry.  This value does not correspond to the reported E_corr = 
2.71166 Ry. Is what I am saying correct or I missed something?

Best regards,

Lorenzo

- Mail original -
De: "Tran, Fabien" 
À: "A Mailing list for WIEN2k users" 
Envoyé: Vendredi 11 Juin 2021 13:45:06
Objet: Re: [Wien] Correlation energy in DFT+U

Hi,

In this paper
https://journals.aps.org/prb/abstract/10.1103/PhysRevB.60.10763
there is Eq. (24), which should correspond to
Ecorr = Eldau - Edc/2.d0 - trdmv
in the file vldau.f in the directory SRC_orb. If this is right, then the 
quantity that you want is
Eldau - Edc/2.d0 = 8.38769-13.58842/2 = 1.59348 Ry
where Eldau and Edc are also printed in case.outputorbup


From: Wien  on behalf of Lorenzo 
Mariano 
Sent: Friday, June 11, 2021 12:43 PM
To: A Mailing list for WIEN2k users
Subject: [Wien] Correlation energy in DFT+U

Dear wien2k users,

I am running some DFT+U calculation on NiO compound following instruction 
reported in this series of exercises: 
http://susi.theochem.tuwien.ac.at/reg_user/textbooks/WIEN2k_lecture-notes_2013/Exercises_13.pdf,
 execise 7. I would like to obtain the correlation  energy contribution 
(E_corr) to the total DFT+U energy: E_DFT+U(rho) = E_DFT(rho) + E_corr.
Because I am using the 'SIC method' for the expression of the double counting 
term with J=0, I expect that E_corr= (U/2) sum_(m,sigma) 
Tr[n_(m,sigma)(1-n_(m,sigma)]. I calculated this term for the spin up channel 
(sigma=up) of the first Ni atom starting from  the density matrix reported in 
case.scfdmup (attached the NiO.scfdmup file). With U=0.514 Ry the calculated 
correlation energy is ~ 0.0546 Ry. This value does not correspond to the one 
reported in the case.outputorbup file (attached the NiO.outputorbup file).
I know that in wien2k E_corr is computed starting from the contribution of the 
Hubbard potential to the eigenvalues. Should I expect that the E_corr value 
reported in the case.outputorbup/dn corresponds to the one computed starting 
from the density matrix elements?

How the terms Eldau and Edc in case.outputorbup/dn are computed?

Thank you in advance for your help,

Lorenzo
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
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] Correlation energy in DFT+U

[Tran, Fabien]

For sure Ecorr = 2.71166 Ry is not what you want. As I wrote previously, you 
have
to remove trdmv: Ecorr-trdmv=1.59348 Ry, because I think that Eldau and Edc/2 
correspond to
E^ee(n) and E^dc(n), respectively.

I don't fully understand your formula (U/2) sum_(m,sigma) 
Tr[n_(m,sigma)(1-n_(m,sigma)] .
It is not possible to have at the same time a sum over m and a trace.


From: Wien  on behalf of Lorenzo 
Mariano 
Sent: Friday, June 11, 2021 4:09 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Correlation energy in DFT+U

Hi,

thanks a lot for the reference where the DFT+U implementation in the FLAPW 
framework is very well explained. However, I still have some doubts. The 
quantity that I want to obtain is the term E^ee(n)-E^dc(n) that appears in 
eq.1. Following  
https://journals.aps.org/prb/abstract/10.1103/PhysRevB.50.16861 this term 
should correspond to eq.8 that in the rotationally invariant formulation is 
given by (U/2) sum_(m,sigma) Tr[n_(m,sigma)(1-n_(m,sigma)] (always considering 
J=0). This term in the specific NiO calculation that I reported is, for 
sigma=up, ~ 0.0546 Ry.  This value does not correspond to the reported E_corr = 
2.71166 Ry. Is what I am saying correct or I missed something?

Best regards,

Lorenzo

- Mail original -
De: "Tran, Fabien" 
À: "A Mailing list for WIEN2k users" 
Envoyé: Vendredi 11 Juin 2021 13:45:06
Objet: Re: [Wien] Correlation energy in DFT+U

Hi,

In this paper
https://journals.aps.org/prb/abstract/10.1103/PhysRevB.60.10763
there is Eq. (24), which should correspond to
Ecorr = Eldau - Edc/2.d0 - trdmv
in the file vldau.f in the directory SRC_orb. If this is right, then the 
quantity that you want is
Eldau - Edc/2.d0 = 8.38769-13.58842/2 = 1.59348 Ry
where Eldau and Edc are also printed in case.outputorbup


From: Wien  on behalf of Lorenzo 
Mariano 
Sent: Friday, June 11, 2021 12:43 PM
To: A Mailing list for WIEN2k users
Subject: [Wien] Correlation energy in DFT+U

Dear wien2k users,

I am running some DFT+U calculation on NiO compound following instruction 
reported in this series of exercises: 
http://susi.theochem.tuwien.ac.at/reg_user/textbooks/WIEN2k_lecture-notes_2013/Exercises_13.pdf,
 execise 7. I would like to obtain the correlation  energy contribution 
(E_corr) to the total DFT+U energy: E_DFT+U(rho) = E_DFT(rho) + E_corr.
Because I am using the 'SIC method' for the expression of the double counting 
term with J=0, I expect that E_corr= (U/2) sum_(m,sigma) 
Tr[n_(m,sigma)(1-n_(m,sigma)]. I calculated this term for the spin up channel 
(sigma=up) of the first Ni atom starting from  the density matrix reported in 
case.scfdmup (attached the NiO.scfdmup file). With U=0.514 Ry the calculated 
correlation energy is ~ 0.0546 Ry. This value does not correspond to the one 
reported in the case.outputorbup file (attached the NiO.outputorbup file).
I know that in wien2k E_corr is computed starting from the contribution of the 
Hubbard potential to the eigenvalues. Should I expect that the E_corr value 
reported in the case.outputorbup/dn corresponds to the one computed starting 
from the density matrix elements?

How the terms Eldau and Edc in case.outputorbup/dn are computed?

Thank you in advance for your help,

Lorenzo
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
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] Correlation energy in DFT+U

[Tran, Fabien]

Hi,

In this paper
https://journals.aps.org/prb/abstract/10.1103/PhysRevB.60.10763
there is Eq. (24), which should correspond to
Ecorr = Eldau - Edc/2.d0 - trdmv
in the file vldau.f in the directory SRC_orb. If this is right, then the 
quantity that you want is
Eldau - Edc/2.d0 = 8.38769-13.58842/2 = 1.59348 Ry
where Eldau and Edc are also printed in case.outputorbup


From: Wien  on behalf of Lorenzo 
Mariano 
Sent: Friday, June 11, 2021 12:43 PM
To: A Mailing list for WIEN2k users
Subject: [Wien] Correlation energy in DFT+U

Dear wien2k users,

I am running some DFT+U calculation on NiO compound following instruction 
reported in this series of exercises: 
http://susi.theochem.tuwien.ac.at/reg_user/textbooks/WIEN2k_lecture-notes_2013/Exercises_13.pdf,
 execise 7. I would like to obtain the correlation  energy contribution 
(E_corr) to the total DFT+U energy: E_DFT+U(rho) = E_DFT(rho) + E_corr.
Because I am using the 'SIC method' for the expression of the double counting 
term with J=0, I expect that E_corr= (U/2) sum_(m,sigma) 
Tr[n_(m,sigma)(1-n_(m,sigma)]. I calculated this term for the spin up channel 
(sigma=up) of the first Ni atom starting from  the density matrix reported in 
case.scfdmup (attached the NiO.scfdmup file). With U=0.514 Ry the calculated 
correlation energy is ~ 0.0546 Ry. This value does not correspond to the one 
reported in the case.outputorbup file (attached the NiO.outputorbup file).
I know that in wien2k E_corr is computed starting from the contribution of the 
Hubbard potential to the eigenvalues. Should I expect that the E_corr value 
reported in the case.outputorbup/dn corresponds to the one computed starting 
from the density matrix elements? 

How the terms Eldau and Edc in case.outputorbup/dn are computed?

Thank you in advance for your help,

Lorenzo
___
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] LDA-Fock alpha hybrid functional

[Tran, Fabien]

Hello,

A reasonable value of alpha is between 0 and 0.5. Typically zero or close to 
zero for metals and in the range 0.15-0.5 for antiferromagnetic correlated 
systems. There are a certain number of papers in the literature about alpha. Is 
there a particular reason why you want to use LDA-Fock rather than the popular 
HSE?



From: Wien  on behalf of 
hajar.nejatip...@yahoo.com 
Sent: Sunday, May 23, 2021 8:26 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] LDA-Fock alpha hybrid functional

Thank you so much for your response.

On Sunday, May 23, 2021, 10:50:34 AM GMT+4:30, Peter Blaha 
 wrote:


alpha is an input parameter (case.inhf) and you can set any value you want.
But make sure you have a good reason to set it to something specifically.

Am 23.05.2021 um 08:17 schrieb 
hajar.nejatip...@yahoo.com:
> Hello,
>
> I have a question about hybrid functionals in Wien2k.
> As written in user guide, there are two possible choices for alpha
> parameter in LDA-Fock alpha hybrid functional, alpha=0.35 and alpha=0.5.
> I want to know, is it possible to select different alpha values in
> LDA-Fock alpha functional or not?
>
> Thank you for your response in advance.
>
> Bests

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

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

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

[Wien] Error in user's guide about the GLLB-SC potential

[Tran, Fabien]

Dear WIEN2k users,

For those who are interested in calculations with the GLLB-SC potential,
note that there is an error in the 2021 version of the user's guide:
it is the file case.inm_vresp (and not case.inm_tau) that has to be created:
cp $WIENROOT/SRC_templates/template.inm_vresp case.inm_vresp

FT
___
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] How to select the appropriate nband in hybrid functionals calculations

[Tran, Fabien]

Is the memory usage that you showed for the 3*3*1 or 4*4*1 supercell? Try to 
figure out if there is no memory problem for the 4*4*1. If you can run a MPI 
calculation, then do it using more than one node.


When you generate (with "run_kgenhf_lapw -redklist") a reduced k-mesh for a 
-redklist calculation, the reduced k-mesh is in case.klist_rfbz, but not in 
case.klist_ibz and case.klist_fbz which are still for the original k-mesh.


If you are interested only in the electronic structure (DOS), then I strongly 
recommend the use of the option "-diagfh" (see explanations in the user's 
guide) for a huge speed up of the calculation (supposing that this 
approximation is accurate enough in your case).


Using -ec 0.6 is nonsense.



From: Wien  on behalf of Yifan Ding 

Sent: Saturday, May 15, 2021 10:25 AM
To: wien
Subject: [Wien] How to select the appropriate nband in hybrid functionals 
calculations

Dear Prof. Tran and Prof. Abo,

Thank you very much for your kindly reply.

The 4*4*1 supercell (including 64 atoms) I want to calculate is really large. 
When I set the h-BN monolayer 3*3*1 supercell including 36 atoms, the 
calculation can be successfully completed.

At present, I am doing a calculation of 3*3*1 supercell, and the SCF is running 
HF in parallel mode. I ssh to the computing node and use the command 'top' to 
query the following information:

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND

15914 yurc  20   0 2681m 2.6g  916 R 100.0  4.1 953:27.35 hfc
  350 root  39  19 000 R 99.9  0.0  5128682h kipmi0
15789 yurc  20   0 2682m 2.6g  824 R 99.9  4.1 953:27.78 hfc
15820 yurc  20   0 2682m 2.6g  916 R 99.9  4.1 953:27.85 hfc
15882 yurc  20   0 2681m 2.6g  916 R 99.9  4.1 953:27.38 hfc
15851 yurc  20   0 2682m 2.6g  904 R 99.6  4.1 953:27.47 hfc

The above five "yurc" are my user names, and it seems that there is no problem 
with memory usage.  I didn't use MPI parallel calculations in 3*3*1 supercell 
or 4*4*1 supercell calculations, and all calculations are k-point parallel. For 
the 3*3*1 supercell, the total number of k points is 9, and there are 5 k 
points in the case.klist_ibz file.

Back to the 4*4*1 supercell calculations with "Error in Parallel HF", although 
I set nx = 1, ny = 1, nz = 1 for the reduced k-mesh, because the total k points 
are 10, the number of k points displayed by case.klist_ibz is 5. In 4*4*1 
supercell calculations with "Error in Parallel HF", the number of nodes is 1 
and the number of cores is 5. Setting -ec 0.6 is indeed very rough, because the 
value of nband will affect the energy range of DOS, but choosing a large nband 
will make the hybrid functional calculation very slow. I want to quickly 
calculate and judge the upper limit of the energy window of DOS by setting 
different nband, and finally choose the appropriate nband to get DOS of -20 eV 
~ 20 eV. In order to complete SCF faster, I used -redklist. Therefore, I set 
"run_lapw -hf -redklist -ec 0.6 -p -i 999 > output.log" in 4*4*1 supercell 
calculations.

I am very grateful to the two professors for your enthusiastic help and help me 
find the questions and answers I didn't found in the mailing list.

I found out from the installation folder that the version information of Wien2k 
I used is WIEN2k_14.2 (Release 15/10/2014). Because I use the public 
supercomputer of the Institute of Physics, I found on the network that using 
the command "grep hf /var/log/syslog" seems to require root, and I don't have 
permission. At present, many people are using the WIEN2k_14.2 in our institute. 
If there is a chance later, I will try to upgrade it.
___
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] How to select the appropriate nband in hybrid functionals calculations

[Tran, Fabien]

?Since your system is quite big, maybe the calculation crashed because of not 
enough RAM (hybrid calculations require more RAM than GGA).

Questions: Have you tried to run you calculations several times? How many 
cores/nodes are you using? Which kind of parallelization did you use (MPI or 
k-point)?


Not related to the crash: for the convergence criteria, use something like at 
least "-ec 0.001 -cc 0.001" to have reasonably converged SCF iterations.



From: Wien  on behalf of Yifan Ding 

Sent: Saturday, May 15, 2021 8:00 AM
To: wien
Subject: [Wien] How to select the appropriate nband in hybrid functionals 
calculations

Dear Prof. Fabien,

Thank you very much for reading and helping to solve my question.

I opened the file output.log, and there was only one line in it:

>   stop error

I found the output.log file for a previous successful example of hybrid 
functional computation, which shows the following:

ec cc and fc_conv 0 1 1
in cycle 2ETEST: .91766722   CTEST: .0349624
ec cc and fc_conv 0 1 1
in cycle 3ETEST: .519013165000   CTEST: .0400105
ec cc and fc_conv 1 1 1

>   stop



___
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] How to select the appropriate nband in hybrid functionals calculations

[Tran, Fabien]

Hello,

​

There is probably an error message also in output.log. What is it?



From: Wien  on behalf of Yifan Ding 

Sent: Friday, May 14, 2021 5:31 PM
To: wien
Subject: [Wien] How to select the appropriate nband in hybrid functionals 
calculations

Dear Wien2k developers，

When I tried to do hybrid functional calculation (YS-PBE0) on h-BN monolayer 
which was set a 4*4*1 supercell including 30 B atoms and 34 N atoms， all 
calculated attempts went wrong in the first loop.

The following content comes from case.dayfile：
>   lcore   (04:48:28) 0.546u 0.788s 0:01.66 79.5%  0+0k 0+0io 2pf+0w
>   hf  -redklist -p -c (04:48:30) running HF in parallel mode
**  HF crashed!
0.159u 0.253s 0:06.88 5.8%  0+0k 0+40io 0pf+0w
error: command   /public/software/wien2k/WIEN2k_14/hfcpara -c hf.def   failed

>   stop error

I searched past mailing lists and found that there are few questions about 
hybrid functional errors, and several questions and answers about hybrid 
functional errors can't solve my problems. I put my calculation steps below， 
and any comments would be highly appreciated. Thanks in advance!

1. Initialization
[yurc@node71 bigc-tahybridtest1]$ init_hf_lapw
   Insulator, EF-inconsistency corrected
:GAP  :0.1301 Ry = 1.769 eV   (provided you have a proper k-mesh)
 Bandranges (emin - emax) and occupancy:
:BAN00120: 120   -0.462509   -0.403568  2.
:BAN00121: 121   -0.403194   -0.379922  2.
:BAN00122: 122   -0.403039   -0.378604  2.
:BAN00123: 123   -0.393649   -0.368830  2.
:BAN00124: 124   -0.391842   -0.367239  2.
:BAN00125: 125   -0.388449   -0.357020  2.
:BAN00126: 126   -0.388279   -0.353847  2.
:BAN00127: 127   -0.388042   -0.60  2.
:BAN00128: 128   -0.387867   -0.326951  2.
:BAN00129: 129   -0.129916   -0.120609  2.
:BAN00130: 130   -0.128004   -0.113769  2.
:BAN00131: 1310.0163340.034382  0.
:BAN00132: 1320.0164860.034448  0.
:BAN00133: 1330.0389040.046957  0.
:BAN00134: 1340.0390020.047860  0.
:BAN00135: 1350.0410630.051186  0.
Energy to separate low and high energystates:   -1.10359


:NOE  : NUMBER OF ELECTRONS  = 260.000

You must set NBAND to at least  NB_occ + 1  and you have 260.00 electrons
edit bigc-tahybridtest1.inhf ...
PS: For very accurate calc. and large NBAND you may have to increase EMAX in 
bigc-tahybridtest1.in1 by hand

Prepare k-mesh for HF. Use identical mesh and shift for IBZ and FBZ
Do you want to use a REDUCED k-mesh for HF (saving cpu-time) (Y/n) ?
Y
 This script runs   x kgen   twice and generates equivalent meshes in the
 IBZ and FBZ.



KGEN ENDS
KGEN ENDS
How many k-points in full BZ?
If you type 0 you can give 3 numbers for nx,ny,nz
10
   2  symmetry operations without inversion
 inversion added (non-spinpolarized non-so calculation)
  NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
 length of reciprocal lattice vectors:   0.383   0.383   0.083   3.586   3.586  
 0.778
  Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
   5  k-points generated, ndiv=   3   3   1
KGEN ENDS
0.000u 0.012s 0:00.06 16.6% 0+0k 0+0io 0pf+0w
   1  symmetry operations without inversion
  NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
 length of reciprocal lattice vectors:   0.383   0.383   0.083   3.586   3.586  
 0.778
  Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
   9  k-points generated, ndiv=   3   3   1
KGEN ENDS
0.000u 0.003s 0:00.04 0.0% 0+0k 0+0io 0pf+0w
Give nx,ny,nz for the reduced mesh
nx=?
1
ny=?
1
nz=?
1
   1  symmetry operations without inversion
  NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
 length of reciprocal lattice vectors:   0.383   0.383   0.083   0.000   0.000  
 0.000
  Specify 3 mesh-divisions (n1,n2,n3):
  Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
   1  k-points generated, ndiv=   1   1   1
KGEN ENDS
0.000u 0.004s 0:00.00 0.0% 0+0k 0+0io 0pf+0w
 Now you can use  run_lapw -hf -redklist ...
bigc-tahybridtest1.in0_grr and bigc-tahybridtest1.inhf and hf-kmesh prepared
Now do the hybrid calculation:   run_lapw -hf -redklist ...
[yurc@node71 bigc-tahybridtest1]$

The content of the file case.inhf is as follows:
case.inhf
0.25 alpha
Tscreened (T) or unscreened (F)
0.165lambda
136  nband
6gmax
3lmaxe
3lmaxv
1d-3 tolu

2. SCF calculations
The command I used when submitting the calculation is "run_lapw -hf -redklist 
-ec 0.6 -p -i 999 > output.log".

3. error information
I tried many times to calculate and modify the parameters. Every time, the 
error appears in first cycle in Hf calculation. The 

Re: [Wien] does dftd3 not work with mBJ

[Tran, Fabien]

Hi,


Do first a geometry optimization with a functional that is appropriate for that 
(PBE, PBEsol?, SCAN, ...).

Then, do the mBJ calculation at the optimized geometry.



From: Wien  on behalf of fatima DFT 

Sent: Saturday, December 26, 2020 4:55 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] does dftd3 not work with mBJ

Thank you Sir for a detailed explanation.

First goal is to optimize the geometry and then band gap.

I got your point.

Thank you very much
Fatima




On Sat, Dec 26, 2020, 00:56 Tran, Fabien 
mailto:fabien.t...@tuwien.ac.at>> wrote:
Hello,

When mBJ is specified with XC_MBJ in case.in0, ?the total energy is calculated 
with LDA (grep for :POT in case.scf).  There exist no dftd3 parameters for LDA. 
You have to specify another functional (e.g., PBE) for the energy in case.in0:
EX_PBE EC_PBE VX_MBJ VC_LDA

Besides, I see no interest in combining dftd3 and mBJ. mBJ is for the band gap, 
while dftd3 is for the geometry and cohesive energy.
What is your goal?


From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>
 on behalf of fatima DFT mailto:fatimad...@gmail.com>>
Sent: Friday, December 25, 2020 1:11 PM
To: A Mailing list for WIEN2k users
Subject: [Wien] does dftd3 not work with mBJ

Dear Wien2k Users
Merry Christmas!

Could someone please confirm that dftd3 does not support  mBJ?
I can run it with PBE but with mBJ it does not work.

Thank you in advance

Fatima
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at<mailto: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] does dftd3 not work with mBJ

[Tran, Fabien]

Hello,

When mBJ is specified with XC_MBJ in case.in0, ​the total energy is calculated 
with LDA (grep for :POT in case.scf).  There exist no dftd3 parameters for LDA. 
You have to specify another functional (e.g., PBE) for the energy in case.in0:
EX_PBE EC_PBE VX_MBJ VC_LDA

Besides, I see no interest in combining dftd3 and mBJ. mBJ is for the band gap, 
while dftd3 is for the geometry and cohesive energy.
What is your goal?


From: Wien  on behalf of fatima DFT 

Sent: Friday, December 25, 2020 1:11 PM
To: A Mailing list for WIEN2k users
Subject: [Wien] does dftd3 not work with mBJ

Dear Wien2k Users
Merry Christmas!

Could someone please confirm that dftd3 does not support  mBJ?
I can run it with PBE but with mBJ it does not work.

Thank you in advance

Fatima 
___
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] Self Interaction Correction (SIC)

[Tran, Fabien]

?Hi,

None of these two SIC methods? is implemented in WIEN2k, and neither for core 
nor valence electrons.

For the core electrons, there is currently no other methods besides LDA, GGA 
and mBJ.

For which purpose do you need SIC for core electrons?



From: Wien  on behalf of Wanderson 
Lobato Ferreira 
Sent: Tuesday, November 17, 2020 5:49 PM
To: wien@zeus.theochem.tuwien.ac.at
Subject: [Wien] Self Interaction Correction (SIC)

Dear users, how to apply the SIC of Lundin and Eriksson (LE-SIC) or of Perdew 
and Zunger (PZ-SIC) to the core states.
___
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] Need extensive help for a job file for slurm job scheduler cluster

[Tran, Fabien]

The probably simplest solution is to ask the system administrator to install bc 
on all nodes:
​​https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17679.html


From: Wien  on behalf of Dr. K. C. 
Bhamu 
Sent: Sunday, November 15, 2020 8:07 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Need extensive help for a job file for slurm job scheduler 
cluster
  


Additional information (maybe this is the main cause of the lapw1 crash):
bc is only working on the head node. node11 or other clint nodes are not having 
bc installed.
If the bc is only the issue then is it possible to modify the job file such 
that it uses bc on the head node only.


Thank you
Bhamu 


On Sun, Nov 15, 2020 at 12:25 PM Dr. K. C. Bhamu  wrote:
 


Dear Gavin and Prof. Marks
Thank you for your inputs.
qsub MyJobFIle.job creates the .machines file.


With the below given  job file, I could create the proper .machine files (equal 
to number of cores in the node and .machines file) but  lapw1  always crashes


case.dayfile is

Calculating pbe in /home/kcbhamu/work/test/pbe
on node11 with PID 9241
using WIEN2k_19.1 (Release 25/6/2019) in /home/kcbhamu/soft/w2k192


    start (Sun Nov 15 15:42:05 KST 2020) with lapw0 (40/99 to go)

    cycle 1 (Sun Nov 15 15:42:05 KST 2020) (40/99 to go)

>   lapw0   -p (15:42:05) starting parallel lapw0 at Sun Nov 15 15:42:05 KST 
> 2020
 .machine0 : processors
running lapw0 in single mode
7.281u 0.272s 0:07.64 98.8% 0+0k 1000+1216io 0pf+0w
>   lapw1  -p     (15:42:13) starting parallel lapw1 at Sun Nov 15 15:42:13 KST 
> 2020
->  starting parallel LAPW1 jobs at Sun Nov 15 15:42:13 KST 2020
running LAPW1 in parallel mode (using .machines)
16 number_of_parallel_jobs
0.200u 0.369s 0:00.59 94.9% 0+0k 208+456io 0pf+0w
error: command   /home/kcbhamu/soft/w2k192/lapw1para lapw1.def   failed

>   stop error



the job.eout file indicates below error:


But I am getting below error


bc: Command not found.
 LAPW0 END
bc: Command not found.
number_per_job: Subscript out of range.
grep: *scf1*: No such file or directory
grep: lapw2*.error: No such file or directory



.machines file is give below



1:node11
1:node11
1:node11
1:node11
1:node11
1:node11
1:node11
1:node11
1:node11
1:node11
1:node11
1:node11
1:node11
1:node11
1:node11
1:node11
granularity:1
extrafine:1





parallel_options file
setenv TASKSET "no"
if ( ! $?USE_REMOTE ) setenv USE_REMOTE 0
if ( ! $?MPI_REMOTE ) setenv MPI_REMOTE 0
setenv WIEN_GRANULARITY 1
setenv DELAY 0.1
setenv SLEEPY 1
setenv WIEN_MPIRUN "mpirun -np _NP_ -machinefile _HOSTS_ _EXEC_"
setenv CORES_PER_NODE 16



job file


#!/bin/sh
#SBATCH -J test
#SBATCH -p 52core    # THis is the name of the partition.
#SBATCH -N 1
#SBATCH -n 16
#SBATCH -o %x.o%j
#SBATCH -e %x.e%j
#export I_MPI_PMI_LIBRARY=/usr/lib64/libpmi.so 

export OMP_NUM_THREADS=16     # I have check with 1,2 4, 8 also.

# Use , as list separator
IFS=','
# Convert string to array
hcpus=($SLURM_JOB_CPUS_PER_NODE)
unset IFS

declare -a conv

# Expand compressed slurm array
for cpu in ${hcpus[@]}; do
     if [[ $cpu =~ (.*)\((.*)x\) ]]; then
# found compressed value
value=${BASH_REMATCH[1]}
factor=${BASH_REMATCH[2]}
for j in $(seq 1 $factor); do
   conv=( ${conv[*]} $value )
done
     else
conv=( ${conv[*]} $cpu )
     fi
done

# Build .machines file
rm -f .machines

nhost=0

echo ${conv[@]};

IFS=','
for node in $SLURM_NODELIST
do 
    declare -i cpuspernode=${conv[$nhost]};
    for ((i=0; i<${cpuspernode}; i++)) 
    do
echo 1:$node >> .machines
    done
    let nhost+=1
done 

echo 'granularity:1' >>.machines
echo 'extrafine:1' >>.machines


run_lapw -p





Thank you very much


Regards
Bhamu



 


On Fri, Nov 13, 2020 at 7:04 PM Gavin Abo  wrote:
 
If you have a look at [1], it can be seen that different cluster systems have 
different commands for job submission.
I did not see it clearly shown in your post how the job was submitted, for 
example did you maybe use something similar to that at [2]:
$ sbatch MyJobScript.sh

What command creates your .machines file?

In your MyJobScript.sh below, I'm not seeing any lines that create a .machines 
file.

 MyJobScript.sh

#!/bin/sh
#SBATCH -J test #job name
#SBATCH -p 44core #partition name
#SBATCH -N 1 #node
#SBATCH -n 18 #core
#SBATCH -o %x.o%j
#SBATCH -e %x.e%j
export I_MPI_PMI_LIBRARY=/usr/lib64/libpmi.so #Do not change here!!
srun ~/soft/qe66/bin/pw.x  < case.in > case.out

 The available jobs files on FAQs are not working. They give me
.machine0  .machines  .machines_current   files only wherein 
.machines has # and the other two are empty.

In the Slurm documentation at [3], it looks like there is variable for helping 
creating a list of nodes on the fly that would need to be written to the 
.machines file:

Re: [Wien] [EXTERNAL] Re: nn distance limit

[Tran, Fabien]

In nn.f there is twice

dstmax=max(20.d0??, ...

Replacing 20.d0 by something larger should help.



From: Wien  on behalf of Parker, David 
S. 
Sent: Wednesday, November 11, 2020 8:57 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] [EXTERNAL] Re: nn distance limit

Does anyone know how to extend the distance limit that nn
Causes atomic distances to be written to case.outputnn? Above
A certain value (about 3.5) input at the prompt following 'x nn',
The case.outputnn file does not continue to increase the maximum
Distance. I am using the WIEN2K_19 version. Presumably there is a
Parameter somewhere in the software that can be changed.

Thanks,
David Parker

___
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] convergence criteria in scf file?

[Tran, Fabien]

The calculation is converged when the convergence criterion is met for three 
subsequent iterations.



From: Wien  on behalf of Pavel 
Ondračka 
Sent: Wednesday, November 4, 2020 9:04 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] convergence criteria in scf file?

On Wed, 2020-11-04 at 07:30 +, Tran, Fabien wrote:
> Is the grep of :ENE, :DIS and :FOR not useful enough?

Right, this is what one would expect, but just to be 100% certain, the
scf is stopped when the change between :ENE, :DIS and (maximum change?)
in :FOR in the last ?two? iterations is below the value specified in
-ec -cc or -fc argument?

BTW what about the criteria itself, new Wien2k versions print in the
:LABEL4 the run_lapw command and arguments (so I can see what specific
values were passed to -ec -cc and -fc), but the stuff I'm looking at
comes from some older version where this was not printed...

Best regards
Pavel

___
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] convergence criteria in scf file?

[Tran, Fabien]

Is the grep of :ENE, :DIS and :FOR not useful enough?


From: Wien  on behalf of Pavel 
Ondračka 
Sent: Wednesday, November 4, 2020 7:58 AM
To: A Mailing list for WIEN2k users
Subject: [Wien] convergence criteria in scf file?

Dear Wien2k mailing list,

I'm looking at some old saved calculations, where I don't have the
dayfile (but I vaguely remember some convergence troubles). So I'm now
looking at the scf file and wondering if it is possible to tell from
the scf file, what was the final convergence of energy, charge and
forces (and also what the convergence criteria passed to run_lapw
were).

Best regards
Pavel

___
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] Regarding calculation of optical properties

[Tran, Fabien]

A few papers about the accuracy of PBE, mBJ, etc. for the electronic structure:
https://aip.scitation.org/doi/10.1063/1.5118863
https://pubs.acs.org/doi/10.1021/acs.jctc.9b00322
https://www.nature.com/articles/s41524-020-00360-0
https://journals.aps.org/prb/abstract/10.1103/PhysRevB.93.115104
https://aip.scitation.org/doi/10.1063/1.5006170

> From: Wien  on behalf of Mohad 
> Abbasnejad 
> Sent: Saturday, October 17, 2020 1:09 PM
> To: A Mailing list for WIEN2k users
> Subject: [Wien] Regarding calculation of optical properties
>
> Dear experts,
>
> Actually, one of the challenging problems in calculating the optical 
> properties by DFT method (using PBE or mbJ) is its accuracy. So, how is it 
> possible to demonstrate the reliability of the results obtained by this 
> method?
> Any comments would be appreciated.
>
> Regards,
> Mohaddeseh
___
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] Regarding calculation of optical properties

[Tran, Fabien]

For a particular system:
By comparing the DFT result to the one obtained with an accurate method (e.g., 
experiment, BSE, GW, hybrid) if available.
If no exp/BSE/GW/hybrid result is available, search for information in the 
literature about the accuracy of the DFT method for systems similar to yours.

In general:
Read the literature.


From: Wien  on behalf of Mohad 
Abbasnejad 
Sent: Saturday, October 17, 2020 1:09 PM
To: A Mailing list for WIEN2k users
Subject: [Wien] Regarding calculation of optical properties

Dear experts,

Actually, one of the challenging problems in calculating the optical properties 
by DFT method (using PBE or mbJ) is its accuracy. So, how is it possible to 
demonstrate the reliability of the results obtained by this method?
Any comments would be appreciated.

Regards,
Mohaddeseh 
___
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] Regarding vacuum level in WIEN2k

[Tran, Fabien]

I made a mistake. This should be: The vacuum level (related to the work 
function) has been discussed ...


From: Wien  on behalf of Tran, Fabien 

Sent: Friday, October 16, 2020 5:32 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Regarding vacuum level in WIEN2k

Hi,

No. The Fermi energy printed in case.scf (:FER) is the energy of the highest 
occupied orbital. The Fermi level (related to the work function) has been 
discussed here:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg09454.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17608.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg03183.html


From: Wien  on behalf of Mohad 
Abbasnejad 
Sent: Friday, October 16, 2020 5:14 PM
To: A Mailing list for WIEN2k users
Subject: [Wien] Regarding vacuum level in WIEN2k

Dear experts,

I was wondering if you guide me whether the Fermi energy is referred to the 
vacuum level or not?
In other words, how is it possible to obtain the vacuum level in WIEN2k 
calculations?

Thanks in advance for your help.

Regards,
Mohaddeseh

 --

-
Mohaddeseh Abbasnejad,
Assistant Professor of Physics,
Faculty of Physics,
Shahid Bahonar University of Kerman,
Kerman, Iran
P.O. Box 76169-133
Tel: +98 34 31322199
Fax: +98 34 33257434
Cellphone: +98 917 731 7514
E-Mail: mohaddeseh.abbasne...@gmail.com
Website:  academicstaff.uk.ac.ir/moabbasnejad
-


___
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] Regarding vacuum level in WIEN2k

[Tran, Fabien]

Hi,

No. The Fermi energy printed in case.scf (:FER) is the energy of the highest 
occupied orbital. The Fermi level (related to the work function) has been 
discussed here:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg09454.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17608.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg03183.html


From: Wien  on behalf of Mohad 
Abbasnejad 
Sent: Friday, October 16, 2020 5:14 PM
To: A Mailing list for WIEN2k users
Subject: [Wien] Regarding vacuum level in WIEN2k
  
Dear experts,

I was wondering if you guide me whether the Fermi energy is referred to the 
vacuum level or not?
In other words, how is it possible to obtain the vacuum level in WIEN2k 
calculations?

Thanks in advance for your help.

Regards,
Mohaddeseh

 -- 

-
Mohaddeseh Abbasnejad, 
Assistant Professor of Physics,
Faculty of Physics, 
Shahid Bahonar University of Kerman,
Kerman, Iran
P.O. Box 76169-133
Tel: +98 34 31322199
Fax: +98 34 33257434
Cellphone: +98 917 731 7514
E-Mail:     mohaddeseh.abbasne...@gmail.com
Website:  academicstaff.uk.ac.ir/moabbasnejad
-

  
___
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] TETRA for 2D system

[Tran, Fabien]

So, finally you could do the calculation on the monolayer with grr fixed to the 
one from the bulk?



From: Wien  on behalf of fatima DFT 

Sent: Thursday, October 15, 2020 8:50 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] TETRA for 2D system

I am sorry sir, if I could not make it clear to you.
Yes, on MP it is in bulk form.


On Thu, Oct 15, 2020 at 12:13 PM Tran, Fabien 
mailto:fabien.t...@tuwien.ac.at>> wrote:

Your explanations are still confusing. What is available on the MP website? The 
structure of the bulk or monolayer?



From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>
 on behalf of fatima DFT mailto:fatimad...@gmail.com>>
Sent: Thursday, October 15, 2020 2:10 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] TETRA for 2D system

Thank you Sir,
Yes, I found the bulk structure on the MP website. The author manipulated the 
atomic positions and then created a monolayer. So the information about exact 
bulk structure  is missing.
I am using case.grr from the structure taken from MP website.

Thank you very much

Fatima

On Thu, Oct 15, 2020 at 12:48 AM Tran, Fabien 
mailto:fabien.t...@tuwien.ac.at>> wrote:

>From your email it is not clear if there is or not a corresponding bulk solid. 
>But it seems that you found one from the MP website? If yes, then do the mBJ 
>calculation on this structure (maybe it does not really matter to optimize the 
>structure or not) and use the file case.grr for the monolayer calculation 
>(and, as explained in Sec. 4.5.10 of the user's guide, don't forget to delete 
>the file case.in0_grr).



From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>
 on behalf of fatima DFT mailto:fatimad...@gmail.com>>
Sent: Wednesday, October 14, 2020 6:28 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] TETRA for 2D system

Thank you Sir.
I see in the case of mBJ the value in the case.grr file is updating in each 
cycle.
So what I understand now is:
Perform mBJ on a well relaxed bulk structure  and then use the case.grr file 
for surface calculation.

But for me, it is difficult to get the exact struct file for its bulk form. The 
monolayer is reported for the very first time in recent.
I took the cif file from a literature paper and no information about its exact 
bulk form (c parameter and how monolayer was created). No response from the 
authors.

I took a rough estimate of c parameter from its original Bulk material from MP 
and doing a test calculation (without relaxing the structure)  for mBJ to get 
the grr file.
Is it okay to do this?
Please guide me.

Thank you very much
Fatima





On Wed, Oct 14, 2020 at 5:52 PM Peter Blaha 
mailto:pbl...@theochem.tuwien.ac.at>> wrote:
> If I understand correctly, I need to initialize the bulk case and use
> its case.grr file for the surface calculation and remove case.in0_grr
> file from the surface calculation.
Yes. But not only "initialize, but also run it to scf with mBJ.


> With TEMP(S), I can not get the band gap value with the grep command on
> the terminal. Is there any workaround for this?

Calculate it yourself. You have the "band-ranges" and occupations in the
scf file. It should be easy to form the difference. (Anyway, the printed
gap is only ok if the k-point (eg. Gamma) where the gap is minimal is
also in your klist.

>
> Is there any tentative date for the new release of the Wien2k version?

No.

>
>
> Thank you
> Fatima
>
>
> On Wed, Oct 14, 2020 at 7:03 PM Peter Blaha
> mailto:pbl...@theochem.tuwien.ac.at> 
> <mailto:pbl...@theochem.tuwien.ac.at<mailto:pbl...@theochem.tuwien.ac.at>>> 
> wrote:
>
> Actually, for a 2D system one should NEVER use TETRA, but always
> TEMP/TEMPS. (For systems with a band gap it does not really matter)
>
> mBJ: You should NOT use normal mBJ for surfaces. mBJ uses an average
> over the unit cell and this is meaningless for a system with vacuum.
>
> Instead you should use the case.grr file for a corresponding bulk
> calculation and remove case.in0_grr from the surface calculation.
>
> PS: In the next release a "local-mBJ" will be available, which can be
> applied also to surfaces.
>
> On 10/14/20 9:38 AM, fatima DFT wrote:
>  > Dear Wien2k Users,
>  > I am running a 2D case (vacuum in c -direction) with Wien2k 19.1
> version.
>  > The case is relaxed with optB-88-vdw. PBE case was okay but for
> mBJ the
>  > ground state energy is oscillating and the band gap is also
>  > overestimating by twice.
>  > After going through, I found that I should use "TEMPS 0.018" [1].
>  >
>  > I have two  questions now:
>  > C

Re: [Wien] TETRA for 2D system

[Tran, Fabien]

Your explanations are still confusing. What is available on the MP website? The 
structure of the bulk or monolayer?



From: Wien  on behalf of fatima DFT 

Sent: Thursday, October 15, 2020 2:10 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] TETRA for 2D system

Thank you Sir,
Yes, I found the bulk structure on the MP website. The author manipulated the 
atomic positions and then created a monolayer. So the information about exact 
bulk structure  is missing.
I am using case.grr from the structure taken from MP website.

Thank you very much

Fatima

On Thu, Oct 15, 2020 at 12:48 AM Tran, Fabien 
mailto:fabien.t...@tuwien.ac.at>> wrote:

>From your email it is not clear if there is or not a corresponding bulk solid. 
>But it seems that you found one from the MP website? If yes, then do the mBJ 
>calculation on this structure (maybe it does not really matter to optimize the 
>structure or not) and use the file case.grr for the monolayer calculation 
>(and, as explained in Sec. 4.5.10 of the user's guide, don't forget to delete 
>the file case.in0_grr).



From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>
 on behalf of fatima DFT mailto:fatimad...@gmail.com>>
Sent: Wednesday, October 14, 2020 6:28 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] TETRA for 2D system

Thank you Sir.
I see in the case of mBJ the value in the case.grr file is updating in each 
cycle.
So what I understand now is:
Perform mBJ on a well relaxed bulk structure  and then use the case.grr file 
for surface calculation.

But for me, it is difficult to get the exact struct file for its bulk form. The 
monolayer is reported for the very first time in recent.
I took the cif file from a literature paper and no information about its exact 
bulk form (c parameter and how monolayer was created). No response from the 
authors.

I took a rough estimate of c parameter from its original Bulk material from MP 
and doing a test calculation (without relaxing the structure)  for mBJ to get 
the grr file.
Is it okay to do this?
Please guide me.

Thank you very much
Fatima





On Wed, Oct 14, 2020 at 5:52 PM Peter Blaha 
mailto:pbl...@theochem.tuwien.ac.at>> wrote:
> If I understand correctly, I need to initialize the bulk case and use
> its case.grr file for the surface calculation and remove case.in0_grr
> file from the surface calculation.
Yes. But not only "initialize, but also run it to scf with mBJ.


> With TEMP(S), I can not get the band gap value with the grep command on
> the terminal. Is there any workaround for this?

Calculate it yourself. You have the "band-ranges" and occupations in the
scf file. It should be easy to form the difference. (Anyway, the printed
gap is only ok if the k-point (eg. Gamma) where the gap is minimal is
also in your klist.

>
> Is there any tentative date for the new release of the Wien2k version?

No.

>
>
> Thank you
> Fatima
>
>
> On Wed, Oct 14, 2020 at 7:03 PM Peter Blaha
> mailto:pbl...@theochem.tuwien.ac.at> 
> <mailto:pbl...@theochem.tuwien.ac.at<mailto:pbl...@theochem.tuwien.ac.at>>> 
> wrote:
>
> Actually, for a 2D system one should NEVER use TETRA, but always
> TEMP/TEMPS. (For systems with a band gap it does not really matter)
>
> mBJ: You should NOT use normal mBJ for surfaces. mBJ uses an average
> over the unit cell and this is meaningless for a system with vacuum.
>
> Instead you should use the case.grr file for a corresponding bulk
> calculation and remove case.in0_grr from the surface calculation.
>
> PS: In the next release a "local-mBJ" will be available, which can be
> applied also to surfaces.
>
> On 10/14/20 9:38 AM, fatima DFT wrote:
>  > Dear Wien2k Users,
>  > I am running a 2D case (vacuum in c -direction) with Wien2k 19.1
> version.
>  > The case is relaxed with optB-88-vdw. PBE case was okay but for
> mBJ the
>  > ground state energy is oscillating and the band gap is also
>  > overestimating by twice.
>  > After going through, I found that I should use "TEMPS 0.018" [1].
>  >
>  > I have two  questions now:
>  > Can I use the scf case of PBE (finished with TETRA) and update TEMPS
>  > 0.018 in case.in2c for mBJ or I need to do a fresh calculation
> starting
>  > from PBE?
>  >
>  > Or should I use PRATT for the first few cycles and then update
> TETRA/TEMPS?
>  >
>  >
>  > [1]
>  >
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg09993.html
>  >
>  > Thank you
>  > Fatima
>  >
>  > 

Re: [Wien] TETRA for 2D system

[Tran, Fabien]

>From your email it is not clear if there is or not a corresponding bulk solid. 
>But it seems that you found one from the MP website? If yes, then do the mBJ 
>calculation on this structure (maybe it does not really matter to optimize the 
>structure or not) and use the file case.grr for the monolayer calculation 
>(and, as explained in Sec. 4.5.10 of the user's guide, don't forget to delete 
>the file case.in0_grr).



From: Wien  on behalf of fatima DFT 

Sent: Wednesday, October 14, 2020 6:28 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] TETRA for 2D system

Thank you Sir.
I see in the case of mBJ the value in the case.grr file is updating in each 
cycle.
So what I understand now is:
Perform mBJ on a well relaxed bulk structure  and then use the case.grr file 
for surface calculation.

But for me, it is difficult to get the exact struct file for its bulk form. The 
monolayer is reported for the very first time in recent.
I took the cif file from a literature paper and no information about its exact 
bulk form (c parameter and how monolayer was created). No response from the 
authors.

I took a rough estimate of c parameter from its original Bulk material from MP 
and doing a test calculation (without relaxing the structure)  for mBJ to get 
the grr file.
Is it okay to do this?
Please guide me.

Thank you very much
Fatima





On Wed, Oct 14, 2020 at 5:52 PM Peter Blaha 
mailto:pbl...@theochem.tuwien.ac.at>> wrote:
> If I understand correctly, I need to initialize the bulk case and use
> its case.grr file for the surface calculation and remove case.in0_grr
> file from the surface calculation.
Yes. But not only "initialize, but also run it to scf with mBJ.


> With TEMP(S), I can not get the band gap value with the grep command on
> the terminal. Is there any workaround for this?

Calculate it yourself. You have the "band-ranges" and occupations in the
scf file. It should be easy to form the difference. (Anyway, the printed
gap is only ok if the k-point (eg. Gamma) where the gap is minimal is
also in your klist.

>
> Is there any tentative date for the new release of the Wien2k version?

No.

>
>
> Thank you
> Fatima
>
>
> On Wed, Oct 14, 2020 at 7:03 PM Peter Blaha
> mailto:pbl...@theochem.tuwien.ac.at> 
> >> 
> wrote:
>
> Actually, for a 2D system one should NEVER use TETRA, but always
> TEMP/TEMPS. (For systems with a band gap it does not really matter)
>
> mBJ: You should NOT use normal mBJ for surfaces. mBJ uses an average
> over the unit cell and this is meaningless for a system with vacuum.
>
> Instead you should use the case.grr file for a corresponding bulk
> calculation and remove case.in0_grr from the surface calculation.
>
> PS: In the next release a "local-mBJ" will be available, which can be
> applied also to surfaces.
>
> On 10/14/20 9:38 AM, fatima DFT wrote:
>  > Dear Wien2k Users,
>  > I am running a 2D case (vacuum in c -direction) with Wien2k 19.1
> version.
>  > The case is relaxed with optB-88-vdw. PBE case was okay but for
> mBJ the
>  > ground state energy is oscillating and the band gap is also
>  > overestimating by twice.
>  > After going through, I found that I should use "TEMPS 0.018" [1].
>  >
>  > I have two  questions now:
>  > Can I use the scf case of PBE (finished with TETRA) and update TEMPS
>  > 0.018 in case.in2c for mBJ or I need to do a fresh calculation
> starting
>  > from PBE?
>  >
>  > Or should I use PRATT for the first few cycles and then update
> TETRA/TEMPS?
>  >
>  >
>  > [1]
>  >
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg09993.html
>  >
>  > Thank you
>  > Fatima
>  >
>  > ___
>  > 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
>  >
>
> --
>
> P.Blaha
> --
> Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
> Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
> Email: bl...@theochem.tuwien.ac.at
> >  
>   WIEN2k: http://www.wien2k.at
> WWW: http://www.imc.tuwien.ac.at/TC_Blaha
> --
> ___
> Wien mailing list
> 

Re: [Wien] LAPW1 error

[Tran, Fabien]

If not already done, also search for problems/solutions related to SECLR4, 
POTRF, or Scalapack/LAPACK in the WIEN2k mailing list.



From: Wien  on behalf of Riyajul Islam 

Sent: Sunday, October 4, 2020 4:25 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] LAPW1 error

I have tried many times in new directories. Most probably i have to install 
scalapack/lapack and recompile wien2k again.

On Sun, 4 Oct 2020, 7:48 pm Tran, Fabien, 
mailto:fabien.t...@tuwien.ac.at>> wrote:
As I said, it works for me. Using your first struct file and executing
init_lapw -b -sp
runsp_lapw -ec 0.0001 -cc 0.0001 -NI
the calculation finishes properly.
Is it really not working if you follow this same procedure in a new directory?
If not, maybe there is a problem/bug with your installed Scalapack/LAPACK 
library?


From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>
 on behalf of Riyajul Islam mailto:riyaju...@gmail.com>>
Sent: Sunday, October 4, 2020 3:43 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] LAPW1 error


It crashes during the 1st iteration. Error occurs in non-parallel calculation 
also. I'm using the 19.2 version of wien2k. I ran other structures and it works 
fine.


On Sun, 4 Oct 2020, 6:42 pm Tran, Fabien, 
mailto:fabien.t...@tuwien.ac.at>> wrote:
  More questions:
At which iteration is it crashing? At the first one or not?
Is it crashing also in non-parallel calculation?
Which WIEN2k version are you using?

One remark:
This second structure corresponds to FeNi, while the first one was for Fe2Ni.


From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>
 on behalf of Riyajul Islam mailto:riyaju...@gmail.com>>
Sent: Sunday, October 4, 2020 2:58 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] LAPW1 error

Calculations details
spin-polarized
PBE functional
RKmax= changed from 5-9
After initialization, I tried running the command runsp_lapw -p -ec 0.0001 -cc 
0.0001 -NI

I tried with another bct structure of FeNi ( case.struct and case.in1 files are 
attached), mentioned in the paper 10.1103/PhysRevB.90.014402

On Sun, 4 Oct 2020 at 18:13, Tran, Fabien 
mailto:fabien.t...@tuwien.ac.at>> wrote:
  Hi,

I can not reproduce this error, at least not with default parameters and PBE 
functional.
You need to provide more information like the functional, spin-polarized or 
non-spin-polarized,
the command that you executed, etc.
Besides, are you sure that your structure is correct? It corresponds to Fe2Ni, 
which seems very odd.


From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>
 on behalf of Riyajul Islam mailto:riyaju...@gmail.com>>
Sent: Sunday, October 4, 2020 10:26 AM
To: A Mailing list for WIEN2k users
Subject: [Wien] LAPW1 error

Dear WIEN2k users,
I am trying to run scf on FeNi fct structure. while running I am getting the 
error

**  Error in Parallel LAPW1
**  LAPW1 STOPPED at Sun Oct 4 13:53:54 IST 2020
**  check ERROR FILES!
 Cholesky INFO =  262
 'SECLR4' - POTRF (Scalapack/LAPACK) failed.

Here I have attached the case.struct and case.in1 files.

Any help would be gratefully appreciated. Many thanks in advance.

Regards

--
Riyajul Islam
Ph.D Scholar
National Institute of Technology Nagaland
Chumukedima, Dimapur
Nagaland 797103, India
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at<mailto: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



 --




Riyajul Islam
Ph.D Scholar
National Institute of Technology Nagaland


Chumukedima, Dimapur
Nagaland 797103, India


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at<mailto: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<mailto: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] LAPW1 error

[Tran, Fabien]

As I said, it works for me. Using your first struct file and executing
init_lapw -b -sp
runsp_lapw -ec 0.0001 -cc 0.0001 -NI
the calculation finishes properly.
Is it really not working if you follow this same procedure in a new directory?
If not, maybe there is a problem/bug with your installed Scalapack/LAPACK 
library?


From: Wien  on behalf of Riyajul Islam 

Sent: Sunday, October 4, 2020 3:43 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] LAPW1 error
  

It crashes during the 1st iteration. Error occurs in non-parallel calculation 
also. I'm using the 19.2 version of wien2k. I ran other structures and it works 
fine.


On Sun, 4 Oct 2020, 6:42 pm Tran, Fabien,  wrote:
  More questions:
At which iteration is it crashing? At the first one or not?
Is it crashing also in non-parallel calculation?
Which WIEN2k version are you using?

One remark:
This second structure corresponds to FeNi, while the first one was for Fe2Ni.


From: Wien  on behalf of Riyajul Islam 

Sent: Sunday, October 4, 2020 2:58 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] LAPW1 error
  
Calculations details 
spin-polarized
PBE functional
RKmax= changed from 5-9
After initialization, I tried running the command runsp_lapw -p -ec 0.0001 -cc 
0.0001 -NI

I tried with another bct structure of FeNi ( case.struct and case.in1 files are 
attached), mentioned in the paper 10.1103/PhysRevB.90.014402

On Sun, 4 Oct 2020 at 18:13, Tran, Fabien  wrote:
  Hi,

I can not reproduce this error, at least not with default parameters and PBE 
functional.
You need to provide more information like the functional, spin-polarized or 
non-spin-polarized,
the command that you executed, etc. 
Besides, are you sure that your structure is correct? It corresponds to Fe2Ni, 
which seems very odd.


From: Wien  on behalf of Riyajul Islam 

Sent: Sunday, October 4, 2020 10:26 AM
To: A Mailing list for WIEN2k users
Subject: [Wien] LAPW1 error
  
Dear WIEN2k users,
I am trying to run scf on FeNi fct structure. while running I am getting the 
error

**  Error in Parallel LAPW1
**  LAPW1 STOPPED at Sun Oct 4 13:53:54 IST 2020
**  check ERROR FILES!
 Cholesky INFO =          262
 'SECLR4' - POTRF (Scalapack/LAPACK) failed.

Here I have attached the case.struct and case.in1 files.

Any help would be gratefully appreciated. Many thanks in advance.

Regards

-- 
Riyajul Islam
Ph.D Scholar
National Institute of Technology Nagaland
Chumukedima, Dimapur
Nagaland 797103, 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



 -- 




Riyajul Islam
Ph.D Scholar
National Institute of Technology Nagaland


Chumukedima, Dimapur
Nagaland 797103, 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] LAPW1 error

[Tran, Fabien]

More questions:
At which iteration is it crashing? At the first one or not?
Is it crashing also in non-parallel calculation?
Which WIEN2k version are you using?

One remark:
This second structure corresponds to FeNi, while the first one was for Fe2Ni.


From: Wien  on behalf of Riyajul Islam 

Sent: Sunday, October 4, 2020 2:58 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] LAPW1 error
  
Calculations details 
spin-polarized
PBE functional
RKmax= changed from 5-9
After initialization, I tried running the command runsp_lapw -p -ec 0.0001 -cc 
0.0001 -NI

I tried with another bct structure of FeNi ( case.struct and case.in1 files are 
attached), mentioned in the paper 10.1103/PhysRevB.90.014402

On Sun, 4 Oct 2020 at 18:13, Tran, Fabien  wrote:
  Hi,

I can not reproduce this error, at least not with default parameters and PBE 
functional.
You need to provide more information like the functional, spin-polarized or 
non-spin-polarized,
the command that you executed, etc. 
Besides, are you sure that your structure is correct? It corresponds to Fe2Ni, 
which seems very odd.


From: Wien  on behalf of Riyajul Islam 

Sent: Sunday, October 4, 2020 10:26 AM
To: A Mailing list for WIEN2k users
Subject: [Wien] LAPW1 error
  
Dear WIEN2k users,
I am trying to run scf on FeNi fct structure. while running I am getting the 
error

**  Error in Parallel LAPW1
**  LAPW1 STOPPED at Sun Oct 4 13:53:54 IST 2020
**  check ERROR FILES!
 Cholesky INFO =          262
 'SECLR4' - POTRF (Scalapack/LAPACK) failed.

Here I have attached the case.struct and case.in1 files.

Any help would be gratefully appreciated. Many thanks in advance.

Regards

-- 
Riyajul Islam
Ph.D Scholar
National Institute of Technology Nagaland
Chumukedima, Dimapur
Nagaland 797103, 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
 


 -- 




Riyajul Islam
Ph.D Scholar
National Institute of Technology Nagaland


Chumukedima, Dimapur
Nagaland 797103, 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] LAPW1 error

[Tran, Fabien]

Hi,

I can not reproduce this error, at least not with default parameters and PBE 
functional.
You need to provide more information like the functional, spin-polarized or 
non-spin-polarized,
the command that you executed, etc. 
Besides, are you sure that your structure is correct? It corresponds to Fe2Ni, 
which seems very odd.


From: Wien  on behalf of Riyajul Islam 

Sent: Sunday, October 4, 2020 10:26 AM
To: A Mailing list for WIEN2k users
Subject: [Wien] LAPW1 error
  
Dear WIEN2k users,
I am trying to run scf on FeNi fct structure. while running I am getting the 
error

**  Error in Parallel LAPW1
**  LAPW1 STOPPED at Sun Oct 4 13:53:54 IST 2020
**  check ERROR FILES!
 Cholesky INFO =          262
 'SECLR4' - POTRF (Scalapack/LAPACK) failed.

Here I have attached the case.struct and case.in1 files.

Any help would be gratefully appreciated. Many thanks in advance.

Regards

-- 
Riyajul Islam
Ph.D Scholar
National Institute of Technology Nagaland
Chumukedima, Dimapur
Nagaland 797103, 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] GGA+U+SO steps order

[Tran, Fabien]

You need both -orb and -so:
runsp_lapw -p -ec 0.0001 -orb -so -i 99

Don't forget to execute init_so_lapw before runsp_lapw in order to generate 
case.inso.



From: Wien  on behalf of tarek 

Sent: Sunday, September 6, 2020 6:25 PM
To: A Mailing list for WIEN2k users
Subject: [Wien] GGA+U+SO steps order

Dear Wien2k useres / team

I have 2 questions

If I ran GGA+U for spin-polarized case and later after the calculations
were ended I wanted

to add SO calculations to the previous GGA+U. Does it write to use the
following command in new run:

 "runsp_lapw -p -ec 0.0001 -so -i 99".

Thanks a lot for your help

Tarek Hammad.



___
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] how to increase the band gap with TB-MBJ or other potential

[Tran, Fabien]

Hi,

For Pb-based perovskites, you should use the parameterization of Jishi et al. 
(https://pubs.acs.org/doi/10.1021/jp5050145) and include SO coupling.
Jishi's parameterization corresponds to "parameterization 4" in init_mbj_lapw.

What is the size of the disagreement for Sn-based perovskites?

A general comment about DFT: There is no functional which is good for 
everything.

FT

From: Wien  on behalf of Sanjay 
Pachori 
Sent: Thursday, August 20, 2020 1:22 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] how to increase the band gap with TB-MBJ or other potential

Sir,
I am calculating the electronic properties of organic-inorganic hybrid halide 
perovskites materials. such as FAPbI3, FAPbBr3, FAPbCl3, FASnI3, FASnBr3, 
FASnCl3. 
the electronic properties of Pb based materials do have successfully completed. 
but I am not able to calculate Sn-based materials with proper bandgap. 
so please help me with proper guidance.

Sanjay Pachori
Assistant Professor (Physics)
Jaipur National University 
SIILAS Campus
Contact No. +91-9785459874
Jaipur- Rajasthan
___
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] Error in Parallel LAPW1 during mBJ calculations

[Tran, Fabien]

Hi,

Try to make the transition from WC to mBJ smoother by using PRATT in case.inm 
with a small mixing factor like 0.10. Use also 0.10 in case.inm_vresp. Start 
the mBJ calculation with the files case.clmsum, case.vrespsum and case.r2v from 
WC. Supposing that it works, the SCF convergence will be very slow.



From: Wien  on behalf of Peeyush Kumar 
Kamlesh 
Sent: Monday, August 17, 2020 6:43 PM
To: wien-requ...@zeus.theochem.tuwien.ac.at; wien@zeus.theochem.tuwien.ac.at
Subject: [Wien] Error in Parallel LAPW1 during mBJ calculations

Dear Users,
Greetings!
I am using WIEN2k_19.1. I have successfully completed scf calculations using 
WC-GGA potential functional. But when I Use to do the same by employing mBJ, 
then I get following error in lapw1 of the 3rd scf cycle:
-
**  LAPW1 STOPPED at Mon Aug 17 21:36:46 IST 2020
**  check ERROR FILES!
 Cholesky INFO =1
 'SECLR4' - POTRF (Scalapack/LAPACK) failed.
 Cholesky INFO =1
 'SECLR4' - POTRF (Scalapack/LAPACK) failed.
 Cholesky INFO =1
 'SECLR4' - POTRF (Scalapack/LAPACK) failed.
 Cholesky INFO =1
 'SECLR4' - POTRF (Scalapack/LAPACK) failed.
-

case.in1 file is as follows:
---
WFFIL  EF= 0.5   (WFFIL, WFPRI, ENFIL, SUPWF)
  7.00 10   4   ELPA pxq BL 64 (R-MT*K-MAX,MAX L IN WF,V-NMT,LIB)
  0.304  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW)
 00.30 0. CONT 1
 0   -2.05 0.0010 CONT 1
 10.30 0. CONT 1
 1   -0.86 0.0010 CONT 1
  0.302  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW)
 20.30 0.0010 CONT 1
 00.30 0. CONT 1
  0.305  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW)
 20.30 0. CONT 1
 2   -1.53 0.0010 CONT 1
 00.30 0. CONT 1
 0   -0.72 0.0010 CONT 1
 10.30 0. CONT 1
K-VECTORS FROM UNIT:4   -9.0   1.538   emin / de (emax=Ef+de) / nband 
#red

Although I have successfully completed mBJ calculations of the other materials 
of the same group. But in this I am getting error msg again and again. I have 
also tried it for different values of RKmax ranging from 5-7. But the result is 
the same. Kindly tell me the solution.
Thanks and 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

Re: [Wien] Wien post from pascal.bou...@univ-amu.fr (Errors with DGEMM and hybrid calculations)

[Tran, Fabien]

> ​If I remember right, lmaxv & lmaxe change how the LM expansion is done 
> inside the spheres, so need to be larger with higher L. The CPU scales 
> something like a square, and they are CPU expensive.

Yes, in principle they should be increased (in particular lmaxv for open 
f-shells). In the Hartree-Fock expressions for energy and potential, there is a 
quadruple sums over lmaxv and a single sum over lmaxe.
 
> GMAX is a plane wave expansion, so (like lapw0) would need to be larger for 
> small RMT such as H or odd cases. Again something like a square dependence, 
> although I am not sure how CPU expensive except for a surface.

Yes.

> The CPU time will scale something like the product of the outer k-mesh and 
> the inner (for which a reduced mesh can be used). Standard accuracy issue.

Yes.

> NBand in case.inhf is I think linear in CPU; I am not exactly sure why it 
> needs to be larger than the number of occupied bands (forgotten).

Like spin-orbit coupling, HF/hybrid is implemented in a 2nd variational 
procedure. NBand orbitals from lapw1 are used as basis functions to construct a 
NBand*NBand Hamiltonian.

> RKMAX is standard, with a 2-3 power dependence of CPU time.

Maybe.

> N.B., I think there is also a dependence upon how different the straight 
> lapw1 & hf are, for instance the band gap in lapw1. This matters for how 
> large the number of states used in lapw1 has to be.

I don't understand.

_
Professor Laurence Marks
"Research is to see what everybody else has seen, and to think what nobody else 
has thought", Albert Szent-Gyorgi
www.numis.northwestern.edu 


On Sat, Aug 15, 2020, 08:38 Tran, Fabien  wrote:
  That's difficult since it may depend on the system, RMT, property, and 
required accuracy, but roughly (concerning  the parameters in case.inhf):

-For geometry: none of the parameters really need to be increased compared to 
default. In particular, nband can be set to minimum required (number of 
occupied bands plus one). Maybe gmax (from case.inhf) should be tested if RMT 
are chosen clearly smaller than  default. The option "-nonself" could also be 
used for non-magnetic systems.

-For cohesive energy: preferably test nband, gmax, lmaxe and lmaxv. Especially 
the latter two for systems with an open  f-shell.

-For electronic structure: test lmaxe and lmaxv for systems with an open  
f-shell. For the band gap of non-magnetic systems, the option "-diaghf" 
(https://urldefense.com/v3/__https://doi.org/10.1016/j.physleta.2012.01.022__;!!Dq0X2DkFhyF93HkjWTBQKhk!AN3JSEcq-L36m1Ickxc1xjixv8KB9lE8fbCvyAvgSj7ySnH9QhVXJB8tDGGm-rjxGqJUjQ$
  ) can be used to reduce the computational time by two orders of magnitude.

-For electron density (e.g., for EFG): Test carefully all parameters.

-k-mesh: In general, the convergence of properties with HF/hybrids is slower 
than with LDA/GGA/MGGA (fortunately only slightly slower with screened hybrids 
like HSE06).

-RKmax: the convergence is the same as for LDA/GGA/MGGA.

-Computational time: strongly influenced by k-mesh, RKmax, nband, lmaxe and 
lmaxv. Less by gmax (from case.inhf).


From: Wien  on behalf of Laurence 
Marks 
Sent: Saturday, August 15, 2020 2:40 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Wien post from  pascal.bou...@univ-amu.fr (Errors with 
DGEMM and hybrid calculations)
  
It would be good to have a brief summary of what matters with hf:
a) For speed
b) For accuracy

It is probably somewhere in the docu, but another cite for the list would be 
useful (to me as well as others).
_
Professor Laurence Marks
"Research is to see what everybody else has seen, and to think what nobody else 
has thought", Albert Szent-Gyorgi
http://www.numis.northwestern.edu
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
https://urldefense.com/v3/__http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien__;!!Dq0X2DkFhyF93HkjWTBQKhk!AN3JSEcq-L36m1Ickxc1xjixv8KB9lE8fbCvyAvgSj7ySnH9QhVXJB8tDGGm-rgXzLvd8g$
SEARCH the MAILING-LIST at:   
https://urldefense.com/v3/__http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html__;!!Dq0X2DkFhyF93HkjWTBQKhk!AN3JSEcq-L36m1Ickxc1xjixv8KB9lE8fbCvyAvgSj7ySnH9QhVXJB8tDGGm-rjETTfF-Q$
   
___
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