Re: [Wien] Error in lapw1 or lapw2, frequently

[Peter Blaha]

The struct file you attached does not even pass the initialization. You 
cannot do calculations with this struct file.


sgroup needs to regroup the equivalent atoms and you MUST accept this.

After taking the struct file from sgroup at least the first 8 iteration 
ran without problems.


Please note:

I'd reduce the a,b lattic parameter (reducing the "vacuum"), but then 
use RKmax=6


It is a 1D-BZ, so use TEMP(S) and not TETRA.

As mentioned before: You cannot do "volume" optimization.
You do a force minimization (-min) and the atoms within your ring will 
optimize their positions on their own. After that you can (manually) 
change c, repeat the force optimization and and find the optimal c.





On 2/16/20 5:40 PM, hajar.nejatip...@yahoo.com wrote:

Dear Peter Blaha and Laurence Marks

thank you so much for your help.

(1) I structed my structure in this way: by using of lattice
parameter of Ti2C layer the diameter of nanotube was be determined. C
and Ti atoms were  located on their site by the polar coordinates. the
atoms located on coaxial cylinders.


please consider that removing of the energy parameter was one of the
changes that i used  to
solve the problem.

(2) at first i got an lapw1 error
Error in Parallel LAPW1
**  LAPW1 STOPPED at Sat Jan 25 12:28:03 +0330 2020
**  check ERROR FILES!
'SELECT' - no energy limits found for atom  7  L= 0
'SELECT' - E-bottom  -2.20384  E-top -200.0

then i changed RMT, L max=12, energy parameter (e.g -1.2 , -1.3, 1.2...)
(one of these changes or all of them simultaneously) ,these changes
usually solved LAPW1 error,  even it got me an total energy e.g for
-10 volume reduction percentage but  after several scf  LAPW2 error appeared

'LAPW2' - semicore band-ranges too large, ghostbands ?
**  testerror: Error in Parallel LAPW2

or error in parallel lapw2

'l2main' - QTL-B.GT.15., Ghostbands, check scf files

lapw2.def failed

and frequently i changed case.in1 and RMTs and received lapw1 and lapw2 
errors.


(3)I received the  lapw1 error at the first cycle. after the changes it was
solved (as mentioned in (1)).
(4) it was  mpi-parallel.
(5) RKM =5.
(6) k point = 1*1*12
(7) I wanted to optimize volume then c/a.
(8)  volume optimization for less reduction percentages e.g  -5, 0,


___
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.atWIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at/TC_Blaha
--
___
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] NMR chemical shift calculations

[Peter Blaha]

Your system is metallic !!!

For metals you have to use the-metal  switch

x_nmr -metal

In addition you should use a fermi smearing (TEMP with 4-6 mRy)  and you 
will need to check k-point convergence.


On 2/14/20 9:56 PM, Nader Ghassemi wrote:

Dear WIEN2K experts,

I am trying to calculate the NMR chemical shift for Cu12Sb4S13.
I am running wien2K on 4 cores PC with operating system Ubuntu 16-04, 
Fortran compiler intel and math libraries mkl.

I am using the spacegroup-217 structure.
The  DOS and band structure calculation goes smoothly without any 
errors. However, after setting up the chemical shift calculations, in 
the final case.outputnmr_integ file for the chemical shift, I get * In 
place of many of the calculated values in the results. Below is an 
extract of the calculated chemical shifts.


:NMRTOT001  ATOM: Cu1+   1  NMR(total/ppm) Sigma-ISO =** 
 Sigma_xx =**   Sigma_yy =**   Sigma_zz =**
:NMRASY001  ATOM: Cu1+   1  NMR(total/ppm) ANISO (delta-sigma) = 
-53300.41 ASYM (eta) = 0.000 SPAN =  53300.41 SKEW =-1.000


:NMRTOT001  ATOM: Cu1+   1  NMR(total/ppm) Sigma-ISO =** 
 Sigma_xx =**   Sigma_yy =**   Sigma_zz =**
:NMRASY001  ATOM: Cu1+   1  NMR(total/ppm) ANISO (delta-sigma) = 
-53300.41 ASYM (eta) = 0.000 SPAN =  53300.41 SKEW =-1.000


:NMRTOT001  ATOM: Cu1+   1  NMR(total/ppm) Sigma-ISO =** 
 Sigma_xx =**   Sigma_yy =**   Sigma_zz =**
:NMRASY001  ATOM: Cu1+   1  NMR(total/ppm) ANISO (delta-sigma) = 
-53300.41 ASYM (eta) = 0.000 SPAN =  53300.41 SKEW =-1.000




Note that I do not get any error message during the calculations, and 
the resulting density of states looks quite similar to what is expected 
from other publications. However, clearly there is a problem with the 
NMR calculation. If there are any suggestions about this please let me 
know. Since there is no explicit error I was not sure what to try. Note 
that Cu12Sb4S13 has its Fermi surface inside one of the bands, making it 
metallic, and in this calculation, I have only considered 1728 K points. 
I realize that a denser grid is likely required for accuracy but it 
appears that perhaps there is some more fundamental problem. Also, my 
real interest is in comparing to substituted Cu12Sb4S13 materials which 
are semiconducting, and I tried artificially placing Ef into the 
semiconducting gap for this material, but with the same error. Also, I 
did get a warning :

$ x_nmr_lapw -mode in1 -p

EXECUTING: /home/lab/Downloads/Wien2k/nmrc -case Cu12Sb4S13_test1 
-mode in1 -nodes 8 -green -ovlpmax 0.4


:WARNINIG  ATOM=   3  L= 0  HIGH OVERLAP between radial functions 0.99 
setting new lo energy:  0.30
:WARNINIG  ATOM=   3  L= 0  HIGH OVERLAP between radial functions 0.96 
setting new lo energy:  0.80
:WARNINIG  ATOM=   3  L= 0  HIGH OVERLAP between radial functions 0.92 
setting new lo energy:  1.30
:WARNINIG  ATOM=   3  L= 0  HIGH OVERLAP between radial functions 0.87 
setting new lo energy:  1.80
:WARNINIG  ATOM=   3  L= 0  HIGH OVERLAP between radial functions 0.79 
setting new lo energy:  2.30
:WARNINIG  ATOM=   3  L= 0  HIGH OVERLAP between radial functions 0.70 
setting new lo energy:  2.80
:WARNINIG  ATOM=   4  L= 0  HIGH OVERLAP between radial functions 0.99 
setting new lo energy:  0.30
:WARNINIG  ATOM=   4  L= 0  HIGH OVERLAP between radial functions 0.98 
setting new lo energy:  0.80
:WARNINIG  ATOM=   4  L= 0  HIGH OVERLAP between radial functions 0.96 
setting new lo energy:  1.30
:WARNINIG  ATOM=   4  L= 0  HIGH OVERLAP between radial functions 0.93 
setting new lo energy:  1.80
:WARNINIG  ATOM=   4  L= 0  HIGH OVERLAP between radial functions 0.90 
setting new lo energy:  2.30
:WARNINIG  ATOM=   4  L= 0  HIGH OVERLAP between radial functions 0.86 
setting new lo energy:  2.80
:WARNINIG  ATOM=   4  L= 0  HIGH OVERLAP between radial functions 0.81 
setting new lo energy:  3.30
:WARNINIG  ATOM=   4  L= 0  HIGH OVERLAP between radial functions 0.75 
setting new lo energy:  3.80
:WARNINIG  ATOM=   4  L= 0  HIGH OVERLAP between radial functions 0.69 
setting new lo energy:  4.30
:WARNINIG  ATOM=   5  L= 0  HIGH OVERLAP between radial functions 0.99 
setting new lo energy:  0.30
:WARNINIG  ATOM=   5  L= 0  HIGH OVERLAP between radial functions 0.98 
setting new lo energy:  0.80
:WARNINIG  ATOM=   5  L= 0  HIGH OVERLAP between radial functions 0.96 
setting new lo energy:  1.30
:WARNINIG  ATOM=   5  L= 0  HIGH OVERLAP between radial functions 0.93 
setting new lo energy:  1.80
:WARNINIG  ATOM=   5  L= 0  HIGH OVERLAP between radial functions 0.90 
setting new lo energy:  2.30
:WARNINIG  ATOM=   5  L= 0  HIGH OVERLAP between radial functions 0.86 
setting new lo energy:  2.80
:WARNINIG  ATOM=   5  L= 0  HIGH OVERLAP between radial functions 0.81 
setting new lo energy:  3.30
:WARNINIG  ATOM=   5  L= 0  HIGH OVERLAP between radial functions 0.75 

Re: [Wien] A basic question

[shamik chakrabarti]

Dear Prof. Xavier & Prof. Tran,

  Thank you so much for your illustration and
weblinks. These will be of immense help to me.

Thanks once again.

with best regards,

On Mon, 17 Feb 2020 at 13:29, Tran, Fabien  wrote:

> https://aip.scitation.org/doi/10.1063/1.4704546
>
> https://pubs.acs.org/doi/10.1021/cr200107z
>
> https://aip.scitation.org/doi/10.1063/1.4869598
>
> https://journals.aps.org/rmp/abstract/10.1103/RevModPhys.87.897
>
> https://science.sciencemag.org/content/298/5594/759
>
> https://royalsocietypublishing.org/doi/full/10.1098/rsta.2012.0476
>
>
> --
> *From:* Wien  on behalf of
> shamik chakrabarti 
> *Sent:* Monday, February 17, 2020 7:44 AM
> *To:* A Mailing list for WIEN2k users
> *Subject:* [Wien] A basic question
>
> Dear Wien2k users & Experts,
>
>  I have a basic question regarding
> simulation using different functionals. I have learned that simulation
> using mbj would provide more accurate band gap than it is provided by
> either GGA or GGA+U or nlvdw. On the contrary, if we want to check accurate
> lattice parameters we go for rev-vdW-DF2 & again if we need to check
> accurate cohesive energy we go for SCAN. So, for checking different
> parameters we use different functionals while one property with one
> functional may be correct & at the same time one property with the same
> functional is not accurate enough.
>
> Why is that so? Why there is no unique functional by using which we can
> get all the properties relatively accurately.
>
> Looking forward to your esteemed advices.
>
> 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
>


-- 
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] Error in nlvdw

[Peter Blaha]

But in nlvdw we do NOT write to the screen (except in case of some errors).

In any case, please change nlvdw.def unit 6 to 66  and run nlvdw 
nlved.def to verify if this is the source of the problem.

It should print all output on the screen then.


On 2/16/20 6:39 PM, Gavin Abo wrote:
Perhaps it's just my system but the WIEN2k 19.1 nlvdw, which has been 
compiled with gfortran (gcc version 7.4.0 under Ubuntu 18.04.4 LTS), is 
behaving strangely.  It seems to get hung up trying to open 
$file.outputnlvdw in SCR_nlvdw/vdw.F.  In x_lapw, I see 
$file.outputnlvdw defined as unit 6.



It might be that use of unit 6 in the nlvdw package is problematic when 
compiled with gfortran similar to what we saw for SRC_symmetry:



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


On 2/16/2020 9:18 AM, Tran, Fabien wrote:


The RAM of the computer was probably not sufficient and the job got 
killed. For such large systems you need to do MPI parallel 
calculations by adding a line "nlvdw:..." in the file .machines (see 
user's guide for detail) and using option -p (runsp_lapw -p ...). You 
should also run the other modules (lapw0, lapw1, lapw2) in parallel.


Beside this, I will very soon (probably tomorrow) send to the mailing 
list updated Fortran files for the nlvdw module. With these updates, 
MPI calculations should be much faster.


F. Tran



*From:* Wien  on behalf of 
shamik chakrabarti 

*Sent:* Sunday, February 16, 2020 4:50 PM
*To:* A Mailing list for WIEN2k users
*Subject:* Re: [Wien] Error in nlvdw
Dear Sir,

          I am replying to each of queries as below;

On Sun, 16 Feb 2020 at 20:35, Laurence Marks > wrote:


It is probably impossible for anyone to help you with so little
information, beyond guesses which may be wrong.

1) What information (errors) are in *.error, *.outputnlvdw,
*.dayfile, :log ?

* in .error file;*
     Error in NLVDW

in *.outputnlvdw*
*
*
kernel type =  1 (M. Dion et al., PRL 92, 246401 (2004))
parameter Z_ab of kernel =    -1.8870
gmax =  25.0
density cutoff rhoc = 0.300E+00
the NL-vdW potential is calculated with gmax_pot =  10.0

n_max, m_max, p_max =    101    101    101
ifft1, ifft2, ifft3 (for proc myid     0) =    203  203    203
ifft1*ifft2*ifft3 (for proc myid     0) =    8365427
Number of G-vectors (for proc myid     0) =    3099627


%                %
% You are using vdW-DF, which was implemented by the Thonhauser group. %
% Please cite the following two papers that made this development      %
% possible and the two reviews that describe the various versions:     %
%                %
%   T. Thonhauser et al., PRL 115, 136402 (2015).                %
%   T. Thonhauser et al., PRB 76, 125112 (2007).               %
%   K. Berland et al., Rep. Prog. Phys. 78, 066501 (2015).             %
%   D.C. Langreth et al., J. Phys.: Condens. Matter 21, 084203 (2009). %
%                %
%                %
% If you are calculating the stress with vdW-DF, please also cite:     %
%                %
%   R. Sabatini et al., J. Phys.: Condens. Matter 24, 424209 (2012).   %
%                %


parameters of the kernel table:
Nq =  30, lambda = 0.111292E+01, q(1) = 0.10E-04, q_cut = 0.10E+02
Nr_points =   2000, r_max =   100.0
q_mesh =
     0.1000     0.05312929     0.11224701 0.17804050
     0.25126365     0.33275542     0.42344952 0.52438515
     0.63671875     0.76173753     0.90087384 1.05572188
     1.22805595     1.41985071     1.63330352 1.87086022
     2.13524270     2.42948008     2.75694394 3.12138629
     3.52698255     3.97838044     4.48075151 5.03985262
     5.66208887     6.35459089     7.12529230 7.98302412
     8.93761444    10.
* case.dayfile*:

 start (Sun Feb 16 20:49:03 IST 2020) with nlvdw (40/99 to go)
>   nlvdw (20:49:03) 111.6u 0.8s 2:47.73 67.0% 0+0k 95536+32io 24pf+0w
error: command   /usr/local/Wien2k/nlvdw nlvdw.def failed

>   stop error

in *.log file*.

Sun Feb 16 11:53:50 IST 2020>; (x_lapw) nn -f setrmt
Sun Feb 16 11:54:07 IST 2020>; (x) nn -up
Sun Feb 16 11:54:23 IST 2020>; (x) sgroup -up
Sun Feb 16 11:54:34 IST 2020>; (x) symmetry -up
Sun Feb 16 11:54:52 IST 2020>; (x) lstart -up
Sun Feb 16 11:55:32 IST 2020>; (x) kgen
Sun Feb 16 11:55:38 IST 2020>; (x) kgen -up
Sun Feb 16 11:55:47 IST 2020>; (x) dstart
Sun Feb 16 11:56:29 IST 2020>; (x) dstart -up
Sun Feb 16 11:56:58 IST 2020>; (x) dstart -dn
Sun Feb 16 12:00:37 IST 2020>; (x) optimize -up
Sun Feb 16 12:02:05 IST 2020>; (x) dstart -super -p
Sun Feb 16 12:02:24 IST 2020>; (x) dstart -super -up -p
Sun Feb 16 12:02:50 IST 2020>; (x) dstart -super -dn -p
Sun Feb 16 12:03:11 IST 2020>; (x) dstart -p -super
Sun Feb 16 12:03:31 IST 2020>; (x) clmaddsub
Sun Feb 16 12:03:33 IST 2020>; (x) 

Re: [Wien] A basic question

[Tran, Fabien]

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

https://pubs.acs.org/doi/10.1021/cr200107z

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

https://journals.aps.org/rmp/abstract/10.1103/RevModPhys.87.897

https://science.sciencemag.org/content/298/5594/759

https://royalsocietypublishing.org/doi/full/10.1098/rsta.2012.0476



From: Wien  on behalf of shamik 
chakrabarti 
Sent: Monday, February 17, 2020 7:44 AM
To: A Mailing list for WIEN2k users
Subject: [Wien] A basic question

Dear Wien2k users & Experts,

 I have a basic question regarding simulation 
using different functionals. I have learned that simulation using mbj would 
provide more accurate band gap than it is provided by either GGA or GGA+U or 
nlvdw. On the contrary, if we want to check accurate lattice parameters we go 
for rev-vdW-DF2 & again if we need to check accurate cohesive energy we go for 
SCAN. So, for checking different parameters we use different functionals while 
one property with one functional may be correct & at the same time one property 
with the same functional is not accurate enough.

Why is that so? Why there is no unique functional by using which we can get all 
the properties relatively accurately.

Looking forward to your esteemed advices.

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