Re: [Wien] [EXTERNAL] Re: Bug in nn

[Parker, David S.]

Thank you for your timely attention to this matter. Unfortunately, the revised 
"nn.f"
Appears to call a function "angle" that is not contained in the code - see the 
compile.msg
Below. "angles" is a defined array, but the code will not compile presently. I 
am using
WIEN2K_19.1 As always, your help is much appreciated.

With best regards,

David Parker
Group Leader, Materials Theory
Lead, “Developing Substitutes”
Critical Materials Institute

ifort  -O -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback -assume 
buffered_io -I/software/tools/compilers/intel_2017/mkl/include
  -c nn.f
ifort -o ./nn struk.o variable_fields.o nn.o dirlat.o ord2.o reduce_alloc.o 
bvan.o  -O -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -tra
ceback -assume buffered_io -I/software/tools/compilers/intel_2017/mkl/include  
-L/software/tools/compilers/intel_2017/mkl/lib/ -lpthread -lm
 -ldl -liomp5 
nn.o: In function `MAIN__':
nn.f:(.text+0x4d0d): undefined reference to `angle_'
/usr/bin/ld: link errors found, deleting executable `./nn'
/usr/bin/sha1sum: ./nn: No such file or directory
make: *** [nn] Error 1

David Parker
Group Leader, Materials Theory
Lead, “Developing Substitutes”
Critical Materials Institute
 
 

On 12/14/20, 6:14 AM, "Wien on behalf of Peter Blaha" 
 wrote:

You can call it a bug or a "feature", because we usually try to avoid 
that something stupid can appear (huge output file) if a user specifies 
unusual input (distances beyond a certain limit).

Anyway, in order to not "delay your research" further, I've looked into 
this issue.

It has NOTHING to do with CXZ lattices, but with a limit in the number 
of "neighboring shells". This is set to 100 shells and the code was 
jumping out of the loop if this has been reached. This would happen in 
all lattice types once 100 shells are reached, but of course in low 
symmetry structures this is reached earlier.

I changed it such that it is not jumping out of the loop, but will 
continue to print.

-- 

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

Subject: FW: [Wien] [EXTERNAL] Re: Bug in nn
From: "Parker, David S." 
Date: 12/13/20, 5:06 PM
To: "wien@zeus.theochem.tuwien.ac.at" 
Dear all:



There is apparently a bug in nn for lattices of the CXZ and P1 symmetry 
that is precluding

Printing of extended distances in case.outputnn. The issue is not 
related to distmax – I have

Manually typed in values as large as 40 Bohr and the output is still 
truncated to about 7.6 A

(see case.outputnn and struct file below). This is significantly 
delaying research results.



Any help would be much appreciated.



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] [EXTERNAL] Re: nn distance limit

[Parker, David S.]

Thanks – I do that but it doesn’t change anything – i.e. the following inputs


[dp3@or-slurm-login03 CuInCr4S8_FI3]$ x nn

 specify nn-bondlength factor: (usually=2) [and optionally dlimit, dstmax (about

  1.d-5, 20)]

6 1.d-5 40

Still yield a maximum output distance of 7.63 A; the actual nn distance is 2.38 
A.
I think the problem may be related to an OS/library update done recently.

David Parker



From: Wien  on behalf of Laurence 
Marks 
Reply-To: A users 
Date: Wednesday, November 11, 2020 at 3:59 PM
To: A users 
Subject: Re: [Wien] [EXTERNAL] Re: nn distance limit

Dstmax can also be set in the command line (3rd number), e.g. 10 2e-5 40
---
Prof Laurence Marks
"Research is to see what everyone else has seen, and to think what nobody else 
has thought", Albert Szent-Gyorgi
www.numis.northwestern.edu<http://www.numis.northwestern.edu>

On Wed, Nov 11, 2020, 14:46 Tran, Fabien 
mailto:fabien.t...@tuwien.ac.at>> wrote:

In nn.f there is twice

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

Replacing 20.d0 by something larger should help.




From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>
 on behalf of Parker, David S. mailto:parke...@ornl.gov>>
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<mailto:Wien@zeus.theochem.tuwien.ac.at>
https://urldefense.com/v3/__http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien__;!!Dq0X2DkFhyF93HkjWTBQKhk!FEbHL7o5pbyc2FhcDUbrda6NEa9rw0675SxzBMmssR2YiiMAbEPFukBcVrKubjS8CI5DnQ$<https://urldefense.com/v3/__http:/zeus.theochem.tuwien.ac.at/mailman/listinfo/wien__;!!Dq0X2DkFhyF93HkjWTBQKhk!FEbHL7o5pbyc2FhcDUbrda6NEa9rw0675SxzBMmssR2YiiMAbEPFukBcVrKubjS8CI5DnQ$>
SEARCH the MAILING-LIST at:  
https://urldefense.com/v3/__http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html__;!!Dq0X2DkFhyF93HkjWTBQKhk!FEbHL7o5pbyc2FhcDUbrda6NEa9rw0675SxzBMmssR2YiiMAbEPFukBcVrKubjTlP0CVNw$<https://urldefense.com/v3/__http:/www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html__;!!Dq0X2DkFhyF93HkjWTBQKhk!FEbHL7o5pbyc2FhcDUbrda6NEa9rw0675SxzBMmssR2YiiMAbEPFukBcVrKubjTlP0CVNw$>
___
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] [EXTERNAL] Re: nn distance limit

[Parker, David S.]

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] [EXTERNAL] Re: Where am I making mistake in LDA+U MAE calculation

[Parker, David S.]

You can use P1 but it will be slow. Sm2Fe17 is rhombohedral, so for anisotropy
The (1,-1,0) cell (rhombohedral coordinates) produced by initso and symmeto is 
the one to use.
See my comment of a few minutes ago.

From: Wien  on behalf of Tuvshin D 

Reply-To: A users 
Date: Tuesday, June 11, 2019 at 11:08 AM
To: A users 
Subject: [EXTERNAL] Re: [Wien] Where am I making mistake in LDA+U MAE 
calculation

Thanks you sir, lowest symmetry in P1 means it's better to not group individual 
atoms right? For my example of Sm2Fe17, I should make struct file with 19 
individual atoms instead of 5  that x symm of init generates to me (or 8 in 
certain direction)

My inaccuracy comes from that my struct file changed in -so calculation. Best 
way to prevent is use P1 with ungrouped all atoms, is it correct?



[Image removed by sender. 
Mailtrack]
Sender notified by
Mailtrack
 06/11/19, 11:51:42 PM
[Image removed by sender.]

On Tue, Jun 11, 2019 at 11:29 PM Peter Blaha 
mailto:pbl...@theochem.tuwien.ac.at>> wrote:
Definitely, MAE calculations should ALWAYS be done with ONE struct file
of lowest symmetry (eventually in P1) to avoid any possible biases.

Usually initso will change your struct file and reduce symmetry. Take
the reduced symmetry file and put another magnetization direction.
Repeat such that at the end no further symmetry change appears in any of
your desired directions.

With this struct file do a non-SO calculation with -orb (PS: You should
NEVER use   -orb right after init_lapw, but always converge first with
GGA, then create new dmatup/dn files (x lapwdm -up/dn); save and then
continue with -orb.

Obviously, LDA+U can lead to different (meta-stable) solutions and then
a comparison of total energies is not possible.

On 6/9/19 6:13 AM, Tuvshin D wrote:
> Dear WIEN2k users, while my normal MAE calculations are being well
> achieved, LDA+U or inclusion of Orbital Potential methods giving not so
> reliable results, makes me wonder if I'm doing correct or not. I'd
> really appreciate if anyone with an experience on MAE calculations make
> quick skim through my steps and point out where did I went wrong. System
> is SmFe and calculating DM and U only on Sm atom. Full list of my given
> commands are included.
>
> 1. I make directory, bring struct file and run (init_lapw)
> 2. Set proper case.indm case.indmc and case.inorb files and run
> (runsp_lapw -p -orb -ec 0.01 -cc 0.01 -fc 0.001 -i 500 -NI)
> 3. After reached convergence, (save_lapw -d name) to save results.
> 4. Make 2 new directory for each magnetization directions and copy above
> result to them.
> 5. Run initso_lapw for setup on each of directions.
> 6. Now run (runsp_lapw -p -so -orb -ec 0.01 -cc 0.01 -fc 0.001
> -i 500 -NI)
> 7. Get MAE from difference between energy of 2 directions (from bottom
> of case.scf) as -orb already calculated DM.
>
> Is there any wrong steps, if I were to run SO first then scf, what would
> be its step, or should I include -orb after normal scf.
>
> Thanks for your kind attention, best of all.
>
>
>
>
> Mailtrack
> 
>   Sender notified by
> Mailtrack
> 
> 06/09/19, 1:10:23 PM
>
>
> ___
> 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
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] [EXTERNAL] Re: Where am I making mistake in LDA+U MAE calculation

[Parker, David S.]

I would add to Peter's comments that generally, for a 2D hexagonal system (such 
as SmFe5)
The struct file to use is the one given by initso (and symmetso) for a planar 
orientation of the 
Moments - I usually use (110).  A similar comment applies to a tetragonal 
system; for rhombohedral
I use (1,-1,0) (note that in these rhombohedral coordinates the c-axis is 
(111)).  For a cubic case
it seems that the struct file should have only inversion symmetry, as this and 
the identity are
the only common elements to the (100), (110) and (111) directions. The only 
input file that should differ 
for the c-axis and planar total energy calculations is case.inso - everything 
else should be identical, with the exception
Of the WIEN2K-computed Fermi energy in case.in1.

Regarding Sm, one often gets meta-stable states that produce spurious MAE 
results on the order of hundreds
Of meV per unit cell.  If your energy difference is this large it is nearly 
certain to be a spurious (untrue) result.
To deal with these one must play around with the density matrix - one way that 
sometimes
works is to take the density matrix from the lowest energy direction and 
substitute into the 
metastable configuration.

Good luck - David Parker

On 6/11/19, 10:29 AM, "Wien on behalf of Peter Blaha" 
 wrote:

Definitely, MAE calculations should ALWAYS be done with ONE struct file 
of lowest symmetry (eventually in P1) to avoid any possible biases.

Usually initso will change your struct file and reduce symmetry. Take 
the reduced symmetry file and put another magnetization direction. 
Repeat such that at the end no further symmetry change appears in any of 
your desired directions.

With this struct file do a non-SO calculation with -orb (PS: You should 
NEVER use   -orb right after init_lapw, but always converge first with 
GGA, then create new dmatup/dn files (x lapwdm -up/dn); save and then 
continue with -orb.

Obviously, LDA+U can lead to different (meta-stable) solutions and then 
a comparison of total energies is not possible.

On 6/9/19 6:13 AM, Tuvshin D wrote:
> Dear WIEN2k users, while my normal MAE calculations are being well 
> achieved, LDA+U or inclusion of Orbital Potential methods giving not so 
> reliable results, makes me wonder if I'm doing correct or not. I'd 
> really appreciate if anyone with an experience on MAE calculations make 
> quick skim through my steps and point out where did I went wrong. System 
> is SmFe and calculating DM and U only on Sm atom. Full list of my given 
> commands are included.
> 
> 1. I make directory, bring struct file and run (init_lapw)
> 2. Set proper case.indm case.indmc and case.inorb files and run 
> (runsp_lapw -p -orb -ec 0.01 -cc 0.01 -fc 0.001 -i 500 -NI)
> 3. After reached convergence, (save_lapw -d name) to save results.
> 4. Make 2 new directory for each magnetization directions and copy above 
> result to them.
> 5. Run initso_lapw for setup on each of directions.
> 6. Now run (runsp_lapw -p -so -orb -ec 0.01 -cc 0.01 -fc 0.001 
> -i 500 -NI)
> 7. Get MAE from difference between energy of 2 directions (from bottom 
> of case.scf) as -orb already calculated DM.
> 
> Is there any wrong steps, if I were to run SO first then scf, what would 
> be its step, or should I include -orb after normal scf.
> 
> Thanks for your kind attention, best of all.
> 
> 
> 
> 
> Mailtrack 
> 

 
>   Sender notified by
> Mailtrack 
> 

 
> 06/09/19, 1:10:23 PM  
> 
> 
> ___
> 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


___
Wien mailing list
Wien@zeus.theo

[Wien] FW: Axes convention spin-orbit coupling monoclinic

[Parker, David S.]

A question regarding this:

What is the axes convention for the direction of magnetization
In a monoclinic case? I attach the case.inso, struct, and an excerpt
>From the scf file. For magnetization along 0 1 0, as in case.inso I would 
>expect
The angle (M,x) to be 29.6, since that is the angle between x and y axes in
The struct file, but the value given at the bottom is 90, which seems strange - 
does anyone know?
Thanks in advance, David Parker

WFFIL
4  0  0 llmax,ipr,kpot
-10  1.5Emin, Emax
0 1 0   h,k,l (direction of magnetization)
 0   number of atoms with RLO
0 0  number of atoms without SO, atomnumbers


CXZ LATTICE,NONEQUIV.ATOMS: 10 8 Cm
 RELA
 30.926707 16.155673  9.357451 90.00 90.00 29.596825
ATOM  -1: X=0. Y=0. Z=0.
  MULT= 1  ISPLIT= 8
Ce1NPT=  781  R0=.1 RMT= 2.5 Z:  58.
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.14420622 Y=0.14420622 Z=0.
  MULT= 1  ISPLIT= 8
Ce2NPT=  781  R0=.1 RMT= 2.5 Z:  58.
L

:KPT   :  NUMBER OF K-POINTS: 18
  Potential not averaged when calculating dV/dr
  90.0  90.0 angle (M,z), angle (M,x) deg

___
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 get accurate GAP using BJ or mBJ methods?

[Parker, David S.]

Pablo, if you read Fabien's original 2009 PRL on the mBJ the parameters (a.b.c) 
were chosen to reproduce
Experimental band gaps.  This does not call the work into question, the basic 
method is on solid ground, but there
is a certain empirical fitting involved.  It usually does reasonably well for 
this precise reason.  Remember it is an exchange correlation
potential, not a functional like GGA.  Best, David Parker

Fabien, perhaps you can comment on the above.

-Original Message-
From: wien-boun...@zeus.theochem.tuwien.ac.at 
[mailto:wien-boun...@zeus.theochem.tuwien.ac.at] On Behalf Of delamora
Sent: Friday, March 04, 2016 1:11 PM
To: A Mailing list for WIEN2k users
Cc: Juan Manuel Radear; gt
Subject: Re: [Wien] How to get accurate GAP using BJ or mBJ methods?

Dear Fabien,
I think that there is a confusion here;
Semi empirical methods need parameters and one get, adjusting 
parameters, good results
On the other hand DFT, in principle, does not need adjustable 
parameters.
There are issues that need adjustable parameters, such as the Hubbard U.
My impression was that the BJ was an improvement that did not need any 
extra adjustable parameters, but from what you are saying, I am wrong. Is this 
the case?
We used the mBJ for K2LnTa3O10 (1) and for Ce1/3NbO3 (2) and we got 
good results. Was this just good luck?
Yours

Pablo de la Mora

1) 
https://www.researchgate.net/profile/Pablo_De_La_Mora/publication/258749881_Evaluation_of_the_band-gap_of_Ruddlesden-Popper_tantalates/links/54ad94470cf24aca1c6f66c0.pdf
2 ) On the mechanism of electrical conductivity in Ce1/3NbO3, Computational 
Materials Science Volume 111, January 2016, Pages 101?106


De: wien-boun...@zeus.theochem.tuwien.ac.at 
 en nombre de 
t...@theochem.tuwien.ac.at 
Enviado: lunes, 29 de febrero de 2016 11:40 a. m.
Para: A Mailing list for WIEN2k users
Asunto: Re: [Wien] How to get accurate GAP using BJ or mBJ methods?

The fundamental problem of DFT is to be an approximate method whatever
is the xc functional/potential that is used.

Anyway, if you really need band structure for your compounds with correct
band gap, then you can empirically adjust the parameter c of the mBJ
potential until the desired band gaps is obtained. For this, you need
to create the file case.in0abp.
For instance if you want to fix c to 1.2, the case.in0abp should be like
this (see Sec. 4.5.9 of the UG):
1.2
0.0
1.0

F. Tran

On Mon, 29 Feb 2016, JingQun wrote:

>
> Dear all,
>
> I am running wien 14.2 on a machine with operating system centos 6.5, fortran 
> compiler ifort.
>
> I want to calculate the electronic structures of borates （such as BBO, KBBF, 
> LBO, and so on）and get accurate GAP using BJ or mBJ methods. During the 
> calculation, I have encountered some problems. They are:
>
> 1, Take KBBF for example. The bandgap of KBBF is 8.0 eV (the UV cutoff edge 
> is about 155 nm).  During the calculation, the unit-cell parameters and 
> atomic coordinates were obtained from XRD, and the RMT were set as K (2.50), 
> Be(1.28), B(1.19), O(1.38)
> F(1.56). The core electron states were separated from the valence states by 
> -8.0 Ry, and the Rkmax was set as 5.0. The Irreducible Brillouin Zon was 
> sampled at 500 k-points without shifted meshes, and the convergent condition 
> for SCF was set as 10E(-5). In
> order to get accurate GAP as described elsewhere, a mBJ method was used. 
> While unlike many other successful example, the bandgap obtained is either 
> larger or smaller than the experimental values. That is to say, when I chose 
> ‘Original mBJ values (Tran,Blaha
> PRL102,226401)’to calculate, the GAP of KBBF is about 11.504 eV, much larger 
> than the experimental values (8.0 eV), while when I chose ‘Unmodified BJ 
> potential (Becke,Johnson J.Chem.Phys 124,221101’, the result is 7.301 eV, 
> smaller than experimental values.
> Can anyone kindly tell me how to get accurate bandgap value of borates ?
>
> PS: The KBBF.struct, KBBF.in1c, KBBF.in2c were added as attachment.
>
> KBBF.struct
>
> blebleble
> R   LATTICE,NONEQUIV.ATOMS   5  155 R32
> MODE OF CALC=RELA unit=bohr
>   8.364065  8.364065 35.454261 90.00 90.00120.00
> ATOM  -1: X=0. Y=0. Z=0.
>   MULT= 1  ISPLIT= 4
> K  NPT=  781  R0=.5 RMT= 2.5 Z:  19.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.72172000 Y=0.72172000 Z=0.72172000
>   MULT= 2  ISPLIT= 4
>   -2: X=0.27828000 Y=0.27828000 Z=0.27828000
> F  NPT=  781  R0=.00010 RMT= 1.56Z:   9.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.802420

Re: [Wien] Hi. I have some questions about tasks. (main purpose)

[Parker, David S.]

Youngbeam, there are a tremendous number of things one can do with WIEN2K or 
other reliable DFT codes such as VASP etc - band gaps and transport properties 
of semiconductors, magnetic materials including magnetization, magnetic 
anisotropy and Curie temperature, etc - the list is almost endless.  Alas, so 
is the expertise required to do these calculations properly.  It is difficult 
and impractical to teach all these things vie e-mail.  You are presumably a 
student at a major university in Korea.  What I suggest you do is find someone 
at your university who does first principles calculations - there should be 
someone, people do this worldwide - and indicate your interest in doing 
research using first principles calculations.  That is likely your best avenue 
for approaching this.  Good luck - David Parker

-Original Message-
From: wien-boun...@zeus.theochem.tuwien.ac.at 
[mailto:wien-boun...@zeus.theochem.tuwien.ac.at] On Behalf Of Youngbeom Cho
Sent: Sunday, August 02, 2015 2:00 PM
To: wien@zeus.theochem.tuwien.ac.at
Subject: [Wien] Hi. I have some questions about tasks. (main purpose)

Hi. I'm a college student interested in WIEN2k.
My WIEN2k's version is 14.2.
I've used this simulation for a month.
I have majored in electronic engineering. but sadly i am not good at 
solid state physics. To make matters worse, i'm not good at English too.
so, i really need your kind helps. there are some questions.

1) what is the main purpose(the targets) of this simulations??
what kinds of parameter did you use to get?
There are examples that i had gotten. -> Energy band gap, kind of 
material(semi-conductor and so on), direct or indirect bandgap 
semi-conductor.

2) Are there any other important parameters that i can extract from 
those SCF files? if so, please teach me.

3) Are there anyone who kindly be my pen-pal teacher or friend?
I have many questions about solid state physics. so i need a really kind 
teacher, friend majoring in physics and so on..,,

My e-mail address is jj2...@naver.com
thank you for reading.




___
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] BerryPI spin-orbit?

[Parker, David S.]

Has anyone succeeded in running BerryPI with spin-orbit? I am using
BerryPI1.3 with the latest WIEN2K version but is is not clear to me what
flags or args one uses to run with spin-orbit. Any help is greatly
appreciated - David Parker

On 7/7/15, 2:01 PM, "Gavin Abo"  wrote:

>X86_64-K1om-linux-ld => I think this is a linker for Intel Xeon Phi
>coprocessors.  As the error message says, it cannot find the
>X86_64-K1om-linux-ld file.  I guess that you have to install a redhat
>package (I would expect that redhat support [
>https://access.redhat.com/support/ ] would be able to tell what package
>needs installed ) or Intel's Manycore Platform Software Stack (MSSP) [
>https://software.intel.com/en-us/articles/intel-manycore-platform-software
>-stack-mpss 
>] to get the file.
>
>I don't see anything noticeable wrong with your compile settings, but it
>should be better to use the recommended siteconfig settings as there are
>differences.  For example, you don't have -assume buffered_io (or -assu
>buff), which can be faster [
>http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg05711.htm
>l 
>] and prevent NFS problems [
>http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg03171.htm
>l 
>].
>
>Maybe, the segmentation fault is related to Xeon Phi coprocessors, but I
>don't have experience using a Xeon Phi coprocessor.
>
>On 7/7/2015 4:26 AM, shamik chakrabarti wrote:
>> Dear wien2k users,
>>
>> We are trying to install wien2k in a server with Red Hat Linux.
>> The compiler used for the installation is composer_xe_2015.0.090
>>
>> Two errors were appeared during installation as being seen from
>> compiler.msg
>>
>> 1) X86_64-K1om-linux-ld: No such file or directory..Error 100
>>
>> 2) segmentation fault (core dumped)Error 2
>>
>> I am giving the settings of OPTION below
>>
>> current:FOPT:-FR -mp1 -w -prec_div -pc80 -pad -ip -traceback
>> current:LDFLAGS:$(FOPT) -L$(MKLROOT)/lib/$(MKL_TARGET_ARCH) -lpthread
>> current:DPARALLEL:'-DParallel'
>> current:R_LIBS:-lmkl_lapack95_lp64 -lmkl_intel_lp64 -lmkl_intel_thread
>> -lmkl_core -lpthread
>>
>> Any response in this regard will be helpful for us.
>>
>> Thanks in advance.
>>
>> with regards,
>>
>> -- 
>> Shamik Chakrabarti
>> Senior Research Fellow
>> Dept. of Physics & Meteorology
>> Material Processing & Solid State Ionics Lab
>> IIT Kharagpur
>> Kharagpur 721302
>> 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

[Wien] Berry PI

[Parker, David S.]

Dear all: I am encountering a problem attempting to install BerryPI on a system 
using  Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-53-generic x86_64). I am using 
Berry PI 1.1 and WIEN2K_14 but the problem shows up in trying to use init.sh to 
set up Numpy.  I have installed python2.7 as /usr/bin/python2.7 and have numpy 
in the $HOME/.local directory but get the following series of error messages 
while running init.sh:

SOURCE: './init.sh'
DIR: '.' resolves to '/home/dp3/BerryPI-1.1'
DIR: '/home/dp3/BerryPI-1.1'
Python Version initially found: 2.7.6
WIEN2k detected
/home/ngs/WIEN2k/w2w
w2w detected
Installation via wget available
##
BerryPI directory found
Continuing...
Python 2.7 directory found
Continuing...
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/dp3/.local/lib/python2.7/site-packages/numpy/__init__.py", line 
137, in 
import add_newdocs
  File "/home/dp3/.local/lib/python2.7/site-packages/numpy/add_newdocs.py", 
line 9, in 
from numpy.lib import add_newdoc
  File "/home/dp3/.local/lib/python2.7/site-packages/numpy/lib/__init__.py", 
line 4, in 
from type_check import *
  File "/home/dp3/.local/lib/python2.7/site-packages/numpy/lib/type_check.py", 
line 8, in 
import numpy.core.numeric as _nx
  File "/home/dp3/.local/lib/python2.7/site-packages/numpy/core/__init__.py", 
line 5, in 
import multiarray
ImportError: 
/home/dp3/.local/lib/python2.7/site-packages/numpy/core/multiarray.so: 
undefined symbol: PyUnicodeUCS2_AsASCIIString
No NumPy directory found
BerryPI will fail to run without NumPy
Would you like to attempt to install NumPy?

I am wondering if this is a Python-Numpy compatibility problem of some sort but 
don't know how to solve it. Any help is greatly appreciated.  Thanks in 
advance, 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] Relaxation of already known structure

[Parker, David S.]

Jihoon, it depends on the sensitivity of the calculations. I generally always 
use the experimental lattice constants, and then relax the internal coordinates 
if forces are significant - greater than 5 or so mRyd/bohr (the units WIEN 
uses). But this takes a lot longer than a simple scf run and often has little, 
if any effect on the results.  For a first pass at a calculation, unless the 
forces are huge, I don't do a relaxation.  If the result is interesting enough 
that a publication may result, then I do a relaxation. Best, David Parker

From: Jihoon Park 
mailto:maximumenergyprod...@gmail.com>>
Reply-To: A users 
mailto:wien@zeus.theochem.tuwien.ac.at>>
Date: Monday, July 21, 2014 3:16 PM
To: A users 
mailto:wien@zeus.theochem.tuwien.ac.at>>
Subject: [Wien] Relaxation of already known structure

Dear Users,


I am wondering if we must do the relaxation for all calculations.
I have found some first principles studies with experimental lattice constants, 
including Dr. Novak's work "PRB 71, 1844422 (2005)."
Therefore, I need to know if the first principles calculations with 
experimental lattice constants are reliable or in what case, it is good enough 
or somethings.
Could anybody please give me some guidance?


All my best
Jihoon Park
___
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] file case.klist_band

[Parker, David S.]

Does anyone know if it is possible in the case.klist_band file to include
k vectors consisting of 3 digit numbers, not 1 or 2 (the physical k-point
is divided of course by the overall number, for which 3 digits seems OK)?
I am trying to plot an off-symmetry point feature and need to use a
3-digit k-point identifier. Thanks, David Parker

On 5/19/14 4:14 AM, "pieper"  wrote:

>In general, follow the extensive description in the user guide.
>
>You have a warning of overlapping spheres - why did you INCREASE the
>RMT's??? Check your structure, look into output nn if the distances are
>ok and reduce the RMT's by proabably a few per cent.
>
>Good look
>
>---
>Dr. Martin Pieper
>Karl-Franzens University
>Institute of Physics
>Universitätsplatz 5
>A-8010 Graz
>Austria
>Tel.: +43-(0)316-380-8564
>
>
>Am 16.05.2014 16:25, schrieb ben amara imen:
>> Hello, 
>> 
>> In order to optimize the internal position u, I have do these steps
>> just after the Initialization :
>> 
>> 1) I have chosen 6 for change structures and 20 for iterations
>> 2) job file : min_lapw
>> 3) prepare commande
>> 4) start it 
>> 
>> Then, during the iterations I have this warning : overlapping spheres.
>> I have increased the Rmt value. But after some iterations  I have
>> this error :   STOP IN MINI, SMALL FORCE  what means.??
>> 
>>  what I can do to overcome this probleme and  my steps are
>> corrects???
>> 
>> Can someone help me Please and thanks in advance
>> 
>> 
>> ___
>> 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] mBJ gap GaAs

[Parker, David S.]

Jianxin, indeed, I have done many non-spin-polarized calculations with mBJ
and so.  Best, David

On 4/15/14 11:04 AM, "Zhu, Jianxin"  wrote:

>Dear Dr. Tran, 
>
>Can I use the -so option together with the mBJ functional?
>
>In the UG, I see that (i) the -so option cannot be used together with -hf;
>(ii) the -so option seems to be ok together with -eece at the expense that
>-eece can be used only for spin-polarized calculations.
>Please correct me if I'm wrong.
>
>Thanks, 
>
>Jianxin 
>
>
>
>On 4/15/14 12:51 AM, "t...@theochem.tuwien.ac.at"
> wrote:
>
>>Hi,
>>
>>yes, 1.63 eV is the value that you should obtained with mBJ. This value
>>is
>>in much better agreement with experiment than LDA or PBE, but you should
>>not expect perfect agreement with experiment. However, by varying
>>manually the value of c [Eq. (3) of PRL 102, 226401 (2009)] you can get
>>more or less any value of the band gap that you want (an increase of
>>c leads to an increase of the band gap). For this, you have
>>to specify yourself the values of alpha, beta and e in case.in0abp
>>(c=alpha and choose 0 and 1 for beta and e, respectively).
>>You can find some explanations at the very end of Sec. 4.5.9 in the
>>user's
>>guide.
>>
>>F. Tran
>>
>>On Tue, 15 Apr 2014, sollebac wrote:
>>
>>> Dear wien2k users,
>>> Im trying to calculate the gap mBJ  of GaAs as an example following the
>>> user-guide. Everything finished ok  but the value that  I got is 1.63
>>>eV  at Gamma,  while the experimental value are  ~1.52 (300K)  and ~1.42
>>>(0K).  How can i
>>> get close value to experimental?  i mean how can i converge the value
>>>(1.63)  to get the best value close to experimental?  the k-points are
>>>560 IBZ and is
>>> not-spin-polarized.
>>> thank in advance.
>>> Jose Luis  
>>> 
>
>___
>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] lapw2 "help031" missing error

[Parker, David S.]

It turns out that this an error that shows up after one has generated a QTL 
file, as for a DOS calculation, and can
Be remedied by switching the "QTL" in the first three characters of case.in2(c) 
to TOT.  Thanks, David

-Original Message-
From: wien-boun...@zeus.theochem.tuwien.ac.at 
[mailto:wien-boun...@zeus.theochem.tuwien.ac.at] On Behalf Of Zhu, Jianxin
Sent: Sunday, April 13, 2014 12:02 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] lapw2 "help031" missing error

Peter and David, 

It looks like I didn't encounter the problem either with

x lapw2 -so -qtl -p -up/dn


or with

x lapw2 -p -so -up/dn -fermi
x lapwdm -p -so -up


unless I did something as I reported yesterday.



Cheers,


Jianxin

On 4/13/14 8:58 AM, "Peter Blaha"  wrote:

>The problem can only be related to the input, i.e. you are trying a
>calculation with QTL in case.in2c, not with TOT.
>
>I'm aware of a problem in   x lapw2 -so -qtl -p -up/dn
>
>which seems to match your error message.
>
>I've found the problem and it will be fixed in the next release.
>
>If you want to calculate orbital moments,
>just run (make sure, case.in2c contains TOT and not QTL)
>
>x lapw2 -p -so -up/dn -fermi
>x lapwdm -p -so -up
>
>
>Am 11.04.2014 16:30, schrieb Parker, David S.:
>> Has anyone encountered (and perhaps fixed) an error in lapw2? I am
>>running a spin polarized calculation, spin-orbit included, for Fe5Ce.
>>The scf run worked fine and I get converged results.   However, when I
>>then go to run a single cycle (to get orbital moments), I get the
>>following error. It seems to be related to a naming convention format
>>error in the setup for the "help031", "help032", etc. files as it is
>>looking for files "031", "032", etc. which are empty.  I have
>>experienced this error numerous times in different situations, even in
>>non-spin polarized calculations for semiconductors; it doesn't seem to
>>be related to the dm flag as it gives the same behavior when I don't
>>use this flag. Any help one can provide is most appreciated.  Thanks,
>>David Parker
>>
>>
>> dp3@node021:Fe5Ce$ runsp_lapw -so -p -dm -NI -i 1
>>   LAPW0 END
>>   LAPW1 END
>>   LAPW1 END
>>   LAPW1 END
>>   LAPW1 END
>>   LAPW1 END
>>   LAPW1 END
>>   LAPW1 END
>>   LAPW1 END
>> LAPWSO END
>> LAPWSO END
>> LAPWSO END
>> LAPWSO END
>> forrtl: severe (24): end-of-file during read, unit 1001, file
>>/var/scratch/dp3/Fe5Ce/031
>> Image  PCRoutineLine
>>Source
>> lapw2c 005461DD  Unknown   Unknown
>>Unknown
>> lapw2c 00544CE5  Unknown   Unknown
>>Unknown
>> lapw2c 004E3E29  Unknown   Unknown
>>Unknown
>> lapw2c 0049B498  Unknown   Unknown
>>Unknown
>> lapw2c 0049ACA8  Unknown   Unknown
>>Unknown
>> lapw2c 004BBFE2  Unknown   Unknown
>>Unknown
>> lapw2c 00478EBA  outp_ 180
>>outp.f
>> lapw2c 00464DBE  l2main_  2125
>>l2main_tmp_.F
>> lapw2c 00473C91  MAIN__605
>>lapw2_tmp_.F
>> lapw2c 0040411C  Unknown   Unknown
>>Unknown
>> libc.so.6  2AF338768B54  Unknown   Unknown
>>Unknown
>> lapw2c 00404019  Unknown   Unknown
>>Unknown
>>
>>>stop error
>>
>> ___
>> 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. Materials Chemistry, TU Vienna
>Getreidemarkt 9, A-1060 Vienna, Austria
>Tel: +43-1-5880115671
>Fax: +43-1-5880115698
>email: pbl...@theochem.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 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] lapw2 "help031" missing error

[Parker, David S.]

Has anyone encountered (and perhaps fixed) an error in lapw2? I am running a 
spin polarized calculation, spin-orbit included, for Fe5Ce.  The scf run worked 
fine and I get converged results.   However, when I then go to run a single 
cycle (to get orbital moments), I get the following error. It seems to be 
related to a naming convention format error in the setup for the "help031", 
"help032", etc. files as it is looking for files "031", "032", etc. which are 
empty.  I have experienced this error numerous times in different situations, 
even in non-spin polarized calculations for semiconductors; it doesn't seem to 
be related to the –dm flag as it gives the same behavior when I don't use this 
flag. Any help one can provide is most appreciated.  Thanks, David Parker


dp3@node021:Fe5Ce$ runsp_lapw -so -p -dm -NI -i 1
 LAPW0 END
 LAPW1 END
 LAPW1 END
 LAPW1 END
 LAPW1 END
 LAPW1 END
 LAPW1 END
 LAPW1 END
 LAPW1 END
LAPWSO END
LAPWSO END
LAPWSO END
LAPWSO END
forrtl: severe (24): end-of-file during read, unit 1001, file 
/var/scratch/dp3/Fe5Ce/031
Image  PCRoutineLineSource
lapw2c 005461DD  Unknown   Unknown  Unknown
lapw2c 00544CE5  Unknown   Unknown  Unknown
lapw2c 004E3E29  Unknown   Unknown  Unknown
lapw2c 0049B498  Unknown   Unknown  Unknown
lapw2c 0049ACA8  Unknown   Unknown  Unknown
lapw2c 004BBFE2  Unknown   Unknown  Unknown
lapw2c 00478EBA  outp_ 180  outp.f
lapw2c 00464DBE  l2main_  2125  
l2main_tmp_.F
lapw2c 00473C91  MAIN__605  lapw2_tmp_.F
lapw2c 0040411C  Unknown   Unknown  Unknown
libc.so.6  2AF338768B54  Unknown   Unknown  Unknown
lapw2c 00404019  Unknown   Unknown  Unknown

>   stop error

___
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] Strucutre Optimization with SO and GGA+U

[Parker, David S.]

Jifeng, remember that the energy associated
With spin-orbit, except perhaps for the actinides, is small
Compared with other energies in the problem, so you can probably
Get "reasonable" results by simply doing the optimization without
spin-orbit, and then include
Spin-orbit when you want the electronic structure .BTW< what is the "PM"
in BaPmO4? Best, David

On 12/19/13 3:52 PM, "Jifeng Sun"  wrote:

>Dear Prof. Marks,
>
>Thank you for your reply! That means it is impossible to get reasonable
>results from 
>WIEN2K if I really want to do structure optimization (atomic positions)
>for heavy 
>materials. Is that right?
>Thanks!
>
>Best,
>Jifeng 
>
>--
>Jifeng Sun
>
>Graduate Research Assistant
>National High Magnetic Field Laboratory
>Condensed Matter Science
>Chemical & Biomedical Engineering
>FAMU-FSU College of Engineering
>Florida State University
>s...@magnet.fsu.edu
>
>- Original Message -
>From: "Laurence Marks" 
>To: "A Mailing list for WIEN2k users" 
>Sent: Thursday, December 19, 2013 2:54:56 PM
>Subject: Re: [Wien] Strucutre Optimization with SO and GGA+U
>
>You cannot do force optimization with SO, it does not work (Pulay
>corrections not implemented).
>
>On Thu, Dec 19, 2013 at 1:08 PM, Jifeng Sun  wrote:
>> Dear All,
>>
>> I was working on a heavy material BaPm2O4. I am wondering about the
>>standard procedure in
>> doing structure optimization (both internal and external) with SO and
>>U. I've been trying
>> to look up some info. on the forum but still don't quite get it. Do I
>>need to use init_so
>> before doing 'x optimize'? Is that possible to do force minimization
>>with SO?? Thanks!
>>
>> Best,
>> Jifeng
>>
>> --
>> Jifeng Sun
>>
>> Graduate Research Assistant
>> National High Magnetic Field Laboratory
>> Condensed Matter Science
>> Chemical & Biomedical Engineering
>> FAMU-FSU College of Engineering
>> Florida State University
>> s...@magnet.fsu.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
>
>
>
>-- 
>Professor Laurence Marks
>Department of Materials Science and Engineering
>Northwestern University
>www.numis.northwestern.edu 1-847-491-3996
>"Research is to see what everybody else has seen, and to think what
>nobody else has thought"
>Albert Szent-Gyorgi
>___
>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] RKMAX reduced due to NMATMAX

[Parker, David S.]

Dear all: I am running a large calculation and got the above error message in 
case.scf, which I presume is due to a limit in param.inc
on the size of the matrix to be diagonalized in lapw1.  Does anyone know where 
I can find the actual RKmax lapw1 used (not the value specified in case.in1)? 
Thanks in advance, 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] lapw0 in mBJ

[Parker, David S.]

Has anyone else encountered a problem with lapw0 in running modified Becke 
Johnson potential calculations? I am looking at UO2, have run a regular GGA scf 
cycle, but after following carefully the procedure in the user's guide x lapw0 
–grr runs properly in a couple seconds but the regular "x lapw0" just sits 
there, bot running even after a full minute. I attach case.in0 and 
case.in0_grr.  Thanks, David Parker

in0

TOT   28(5:LDA, 13:PBE, 11:WC, 19:PBEsol, 28:mBJ, 29:revTPSS, 46:HTBS)
R2V  IFFT  (R2V)
  40  40  402.00  1min IFFT-parameters, enhancement factor, iprint

in0_grr

TOT   50(5:LDA, 13:PBE, 11:WC, 19:PBEsol, 28:mBJ, 29:revTPSS, 46:HTBS)
R2V  IFFT  (R2V)
  40  40  402.00  1min IFFT-parameters, enhancement factor, iprint

___
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] Question about RMT and meaning of optimze.job

[Parker, David S.]

Taro, regarding the first question, changing the RMTs will necessarily
change the energies, but typically one is interested in energy differences
(e.g. From a magnetic to non-magnetic state).  If the RMTs are not
radically altered, these should not change much, hence the literature
statement.  The default RMT's are usually good, sometimes I increase the
smallest one by ~ 10 percent to get faster convergence. David Parker

On 4/15/13 6:16 AM, "s-taro"  wrote:

>Dear users
>
>I am running wien version wien2k-12.
>I have 2 questions.
>
>First, 
>when I change the RMT value, calculation results of energy and volume are
>changed. Does RMT value affect the calculation result?
>Since I have read the literature which says RMT only affects the speed of
>the calculation, I am so confused now.
>
>Second, 
>I cannot understand the meaning of the script written in [optimize.job]
>file.
>1.
>---
> if (-e case.clmsum &&  ! -z case.clmsum) then
>   x dstart -super
> endif
> if (-e case.clmup &&  ! -z case.clmup) then
>   x dstart -super -up
>   x dstart -super -dn
> endif
>---
>
>2.
>---
>clmextrapol_lapw
> if (-e case.clmup &&  ! -z case.clmup) then
> clmextrapol_lapw -up
> clmextrapol_lapw -dn
> endif
>---
>Is there anyone who could help me to understand these script?
>
>Regards
>Taro
>___
>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] mbj and so

[Parker, David S.]

Sahra, the easiest thing to do is to use initso.  Magnetization direction 
doesn't matter for a non-spin-polarized calculation, and the prompts after 
initso are to do things like, turn so off for certain atoms, which you don't 
need to do. All the nest, David Parker

From: Sahra Sahraii mailto:sahraii1...@yahoo.com>>
Reply-To: A users mailto:wien at 
zeus.theochem.tuwien.ac.at>>
List-Post: wien@zeus.theochem.tuwien.ac.at
Date: Thursday, January 10, 2013 1:15 PM
To: A users mailto:wien at 
zeus.theochem.tuwien.ac.at>>
Subject: [Wien] mbj and so


Dear WIEN2k users

I am running wien2k_12, I am trying  So calculation first time using InSb 
crystal . I face  some problems when I want to perform the so calculations :
1- I don,t know how should I edit the Insb. inso for the system that is not a 
spinpolarized system.
WFFIL
 4  1  0  llmax,ipr,kpot
 -10.   1.5   emin,emax (output energy window)
   0.  0.  1. direction of magnetization (lattice vectors)
 NX   number of atoms for which RLO is added
 NX1   -4.97  0.0005  atom number,e-lo,de (case.in1), repeat NX times
 0 0 0 0 0number of atoms for which SO is switch off; atoms


   for 
InSb crystal in line 4,5 and 6. What are the direction of magnetization, NX and 
NX1



2- I want to calculate the band gap of this compound using modified 
Beck-Johnson potential (mbj) , so I  want to perform mbj calculations with so, 
but I do not know how should I do that, for performing  the calculations of 
band gap using mbj potential I  use the following steps:

1-  Running regular initialization and scf

2-  Creating. Inm_vresp

3-  Editing InSb. In0 and setting  R2V option.

4-  Running  one more scf cycle .

5-  Savinge the calculation.

6-  Editing theInSb.in0 and changing the functional to option indxc=28

7-
 Copying the InSb. In0 InSb. In0_grr and changing indxc in Insb. In0_grr to 50.

8-  Running another scf cycle.


On the other hand for doing so calculations, after generating the structure 
file and initializing, I run a scf cycle with SO option, but I don,t know  what 
should I do when I want to run a scf cycle with so option and mbj potential.
best regards
sahraii

[Wien] BoltzTraP : Problem

[Parker, David S.]

Ali, the thing to remember is that in a physical experiment the doping level is 
independent of temperature.  In semiconductors
The chemical potential is a function of temperature, and what you need to do is 
interpolate the data (in case.trace) at a fixed doping level, not at fixed 
chemical potential.  Good luck ? David Parker

From: Ali ALLAM mailto:ali.all...@hotmail.com>>
Reply-To: A users mailto:wien at 
zeus.theochem.tuwien.ac.at>>
List-Post: wien@zeus.theochem.tuwien.ac.at
Date: Monday, October 29, 2012 9:29 AM
To: A users mailto:wien at 
zeus.theochem.tuwien.ac.at>>
Subject: [Wien] BoltzTraP : Problem



Dear Wien2k users

I am PhD student

I work on wien2k and BoltzTraP codes

My problem is how to extract the value of the seebeck coefficient versus the 
Temperature

My input is :

WIEN
0 0 0 0.0
0.814 0.0005 0.1 712
CALC
3
BOLTZ
0.15
1000. 50.
-1
HISTO

In the file case.trace, i obtain different value of fermi energy at different 
Temperatures and at different carrier concentrations

Thus, which seebeck coefficient i choose ? (the carrier concentartion varies at 
the same time with the fermi enegy and the temperature)

With my best regards

Ali ALLAM
Aix Marseille university
PhD - Physics of materials
Marseille 13013 - FRANCE

[Wien] Fermi level after mBJ calculation

[Parker, David S.]

For an insulator, finding the VBM can require plotting of the Fermi
surface at some doping using xcrysden or something else, if the maximum is
not at a symmetry point, which happens sometimes.

On 10/26/12 12:58 PM, "Peter Blaha"  wrote:

>Clearly, you should in general NOT use EF from case.scf2up in a band
>structure calculation.
>In particular when your system is METALLIC, with a "bandstructure k-mesh"
>one cannot perform a
>good BZ integration and EF will be wrong!
>Of course, you have to increase the regular k-mesh of the scf runs, until
>EF is stable.
>
>Of course, the situation may be different for an insulator because
>in the scf k-mesh due to "shifted k-meshes", the VBM may not be in your
>mesh and thus you may miss
>the highest occupied state. Eventually you will have the VBM in your
>bandstructure mesh
>(eg. the Gamma point), but there are numerous cases, where the VBM can
>also somewhere in
>the BZ and NOT at a high symmetry point.
>Thus for an insulator, I'd call the proper EF as the highest energy you
>can get of the l
>ast occupied band.
>
>
>
>Am 26.10.2012 18:42, schrieb Kamil Klier:
>> Colleagues,
>>
>> Please advise whether, following a converged LDA+U and mBJ calculation,
>>the Fermi energy to be inserted into case.insp after the sequence:
>>
>> x lapw1 -c -p -up -band
>> x lapw1 -c -p -dn -band
>> x lapwso -c -orb -p -up
>> x lapw2 -c -so -p -qtl -up -band
>> x lapw2 -c -so -p -qtl -dn -band
>>
>> is to be found from case.scf2up/dn (grep :FER case.scf2up), not from
>>previously saved case.scf (cf. paragraph 8.3.2, line 9, efermi in the
>>Wien2k manual).
>>
>> The -band calculation uses different number of k-points read from
>>case.klist_band (e.g. 61 k-points for the hcp list) than the preceding
>>mBJ calculation with fewer
>> k-points. Is this the reason for the difference between :FER from
>>case.scf and case.scf2up/dn?  Would the difference be removed if
>>case.klist and case.klist_band were
>> identical?
>>
>> Thanks,
>>
>> Kamil Klier
>> Lehigh University
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 
>> This message was sent using IMP, the Internet Messaging Program.
>>
>> ___
>> Wien mailing list
>> Wien at zeus.theochem.tuwien.ac.at
>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
>-- 
>-
>Peter Blaha
>Inst. Materials Chemistry, TU Vienna
>Getreidemarkt 9, A-1060 Vienna, Austria
>Tel: +43-1-5880115671
>Fax: +43-1-5880115698
>email: pblaha at theochem.tuwien.ac.at
>-
>___
>Wien mailing list
>Wien at zeus.theochem.tuwien.ac.at
>http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

[Wien] gap

[Parker, David S.]

Ben, the reason there are three different band gaps listed is that there are 
three different k-point meshes used for the scf, band structure and density of 
states calculations (although one can for this use the same mesh as for scf).  
WIEN can only tell you the difference  between the highest occupied eigenvalue 
and the lowest unoccupied eigenvalue, for the chosen k-point mesh.  In the 
limit of an infinitely fine k-mesh this will be the band gap, but of course any 
practical k-point mesh will have a certain finite mesh grid.

What I would recommend doing is to use xcrysden on a relatively fine k-point 
mesh (maybe 20x20x20 at minimum) to plot the Fermi surface to determine the 
location in k-space of the valence band maximum and conduction band minimum.  
Often but not always this will be at a symmetry point; you can then select a 
path in k-space that includes this point (ie. case.klist_band).  Xcrysden will 
actually tell you what the band range is (use a fine k-point mesh) and this 
will give you a good idea of the gap.

Note also that if the VBM and/or CBM do not fall on a symmetry point, the gap 
reported in case.scf (or case.scf2) will virtually always be an overestimate of 
the real gap, and the problem becomes more severe for very dispersive bands. I 
do a lot of calculations for very small gap semiconductors, like 0.1 eV or 
less, and frequently the gap given in case.scf can be 0.1 or even 0.2 eV larger 
than the actual gap.  To sum up: when in doubt, plot the Fermi surface in 
xcrysden and locate the VBM and CBM, then choose a case.klist_band mesh that 
includes these points.  Good luck - David Parker

From: wien-bounces at zeus.theochem.tuwien.ac.at 
[mailto:wien-boun...@zeus.theochem.tuwien.ac.at] On Behalf Of ben amara imen
Sent: Wednesday, October 17, 2012 11:26 AM
To: wien at zeus.theochem.tuwien.ac.at
Subject: [Wien] gap

Hello !

 I want to determine the gap's value for my compound. So, I have calculated DOS 
and structure bands SB. In my case, DOS gives a value , SB gives me  another 
different value and I have found a another value in case.SCf2 . So I have a 
three different value of gap 

I want to know the singnification of each value (given by DOS; SB and case.SC2 
) and what's the right value??? I mean what the right value  that I have to 
choose

Can someone helps me please!
 And thanks in advance
-- next part --
An HTML attachment was scrubbed...
URL: 

[Wien] 'symmetry' in 12.1

[Parker, David S.]

I see this same error frequently and simply run init for these cases using
the 10 version, this can then be run on scf with the 12 version.  It tends
to show up in supercell type calculations.  All the best, David Parker

On 9/20/12 4:16 PM, "Stefaan Cottenier"  wrote:

>
>Dear wien2k community,
>
>I run into problems with the symmetry program in version 12.1.
>Hereafter, you'll find a case.struct (a 3x1x1 ZnO supercell with one Mg
>impurity at a Zn site) which was produced by 'x supercell' and treated
>by 'x sgroup'.
>
>In version 12.1, this structure file produces error messages in
>case.outputs:
>
>  -- ERROR --
>  ERROR: (multiplicity of atom   9 )*(number of
>pointgroup-operations)
>  ERROR: is NOT = (number of spacegroup-operations)
>  ERROR: MULT:   1  ISYM:   1  NSYM   2
>  ERROR: Check your struct file withx sgroup
>  -- ERROR --
>
>There is no suspicious message in the compile.msg for symmetry, and no
>other warnings or errors are produced.
>
>The same case.struct runs fine in 10.1, and produces a 'negative
>position in rstruc -- please report' message in version 11.1.
>
>Does someone get similar problems with this case.struct and wien2k 12.1?
>Or is it due to a local installation problem?
>
>The file hereafter is the smallest one I could find that gives this
>problem. Put it in an empty directory, run 'x symmetry' and inspect
>case.outputs -- that should produce the error (if at all).
>
>Thanks for testing,
>Stefaan
>
>blebleble
>CXZ LATTICE,NONEQUIV.ATOMS: 12 8 Cm
>MODE OF CALC=RELA unit=bohr
>  31.911957 33.394298  6.141459 90.00 90.00162.864562
>ATOM   1: X=0. Y=0. Z=0.
>   MULT= 1  ISPLIT=15
>Mg1NPT=  781  R0=0.5000 RMT=   1.76  Z: 12.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. Y=0.5000 Z=0.5000
>   MULT= 1  ISPLIT=15
>Zn1NPT=  781  R0=0.5000 RMT=   1.87  Z: 30.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.1666 Y=0. Z=0.4999
>   MULT= 1  ISPLIT=15
>Zn2NPT=  781  R0=0.5000 RMT=   1.87  Z: 30.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.7222 Y=0.5000 Z=0.
>   MULT= 1  ISPLIT=15
>Zn3NPT=  781  R0=0.5000 RMT=   1.87  Z: 30.0
>LOCAL ROT MATRIX:1.000 0.000 0.000
>  0.000 1.000 0.000
>  0.000 0.000 1.000
>ATOM   5: X=0. Y=0. Z=0.
>   MULT= 1  ISPLIT=15
>Zn4NPT=  781  R0=0.5000 RMT=   1.87  Z: 30.0
>LOCAL ROT MATRIX:1.000 0.000 0.000
>  0.000 1.000 0.000
>  0.000 0.000 1.000
>ATOM   6: X=0.8889 Y=0.5000 Z=0.5001
>   MULT= 1  ISPLIT=15
>Zn5NPT=  781  R0=0.5000 RMT=   1.87  Z: 30.0
>LOCAL ROT MATRIX:1.000 0.000 0.000
>  0.000 1.000 0.000
>  0.000 0.000 1.000
>ATOM   7: X=0.3819 Y=0.3819 Z=0.
>   MULT= 1  ISPLIT=15
>O 1NPT=  781  R0=0.0001 RMT=   1.66  Z:  8.0
>LOCAL ROT MATRIX:1.000 0.000 0.000
>  0.000 1.000 0.000
>  0.000 0.000 1.000
>ATOM   8: X=0.9374 Y=0.8819 Z=0.5000
>   MULT= 1  ISPLIT=15
>O 2NPT=  781  R0=0.0001 RMT=   1.66  Z:  8.0
>LOCAL ROT MATRIX:1.000 0.000 0.000
>  0.000 1.000 0.000
>  0.000 0.000 1.000
>ATOM   9: X=0.5485 Y=0.3819 Z=0.4999
>   MULT= 1  ISPLIT=15
>O 3NPT=  781  R0=0.0001 RMT=   1.66  Z:  8.0
>LOCAL ROT MATRIX:1.000 0.000 0.000
>  0.000 1.000 0.000
>  0.000 0.000 1.000
>ATOM  10: X=0.1041 Y=0.8819 Z=0.
>   MULT= 1  ISPLIT=15
>O 4NPT=  781  R0=0.0001 RMT=   1.66  Z:  8.0
>LOCAL ROT MATRIX:1.000 0.000 0.000
>  0.000 1.000 0.000
>  0.000 0.000 1.000
>ATOM  11: X=0.7152 Y=0.3819 Z=0.
>   MULT= 1  ISPLIT=15
>O 5NPT=  781  R0=0.0001 RMT=   1.66  Z:  8.0
>LOCAL ROT MATRIX:1.000 0.000 0.000
>  0.

[Wien] Problems in the 1st step of the SCF cycle of mBj

[Parker, David S.]

I have had this problem too, only with mBJ, in the latest (2012) version
of WIEN, which I solved by using an earlier (in this case 2010) version of
lapw0 in WIENROOT.  This is obviously not an ideal solution, however, and
I wonder if there is a better way - perhaps a compilation option? - David
Parker

On 8/23/12 9:12 AM, "eitel at iflysib.unlp.edu.ar"
 wrote:

>Dear Wien users,
>
>I have had problems when I try to run the cycle mBJ, on in the first
>iteration, the error is:
>
>  LAPW0 END
>forrtl: severe (174): SIGSEGV, segmentation fault occurred
>Image  PCRoutineLineSource
>lapw0  00404F58  c3fft_1_  119
>fftpack_helpers.f
>lapw0  00411EC1  fftpack_mp_c3fft_ 397
>fft_modules.F
>lapw0  0047B3ED  vresp_106
>vresp.F
>lapw0  004913E8  xcpot3_   147
>xcpot3.F
>lapw0  004582D9  MAIN__   1935
>lapw0.F
>lapw0  00403CEC  Unknown   Unknown
>Unknown
>libc.so.6  2B57EE0B7EFF  Unknown   Unknown
>Unknown
>lapw0  00403BE9  Unknown   Unknown
>Unknown
>
>>   stop error
>
>can someone tell me what is the origin for this error?
>
>   Thanking in advance.
>
>   Eitel Peltzer
>
>
>This message was sent using IMP, the Internet Messaging Program.
>
>
>-- 
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.
>
>___
>Wien mailing list
>Wien at zeus.theochem.tuwien.ac.at
>http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

[Wien] Parallel lapw1 bug, WIEN2K_12?

[Parker, David S.]

Thanks so much, Laurence.  Changing parallel_options to the values in the 
earlier version seems to rectify the problem - David Parker


On 8/6/12 10:44 AM, "Laurence Marks"  wrote:

It is hard to know exactly, but it looks like there is something not
correct with your combination of machine file and/or how
parallel_options is setup and/or communications. The message
"/home/dp3/CoSi not found" indicates some bash/OS issue that has no
connection to the compilation options.

Suggestions:

a) Remove the ":1" from the machines file, as it might get in the way.
b) Compare parallel_options in the two versions
c) Check that everything is OK for "ssh node014"
d) Check how the variable remote is defined in the two cases -- for
instance by doing a grep on it in lapw1para for the two cases.

On Mon, Aug 6, 2012 at 9:24 AM, Parker, David S.  wrote:
> Dear all:
>
> I am experiencing a problem with the (k-point) parallel version of lapw1 in 
> the newest WIEN2K, version 12.  lapw1 works fine in single processor mode but 
> when
> I go to run lapw1 -p I get the error messages below.
>
> I was using the 2010 version of WIEN2K and did not have these problems. Any 
> ideas? Thanks in advance for your help - David Parker
>
> dp3 at head:CoSi$ x lapw1 -p
> starting parallel lapw1 at Mon Aug  6 10:50:10 EDT 2012
> ->  starting parallel LAPW1 jobs at Mon Aug  6 10:50:10 EDT 2012
> running LAPW1 in parallel mode (using .machines)
> 4 number_of_parallel_jobs
> [1] 15388
> bash: line 0: cd: /home/dp3/CoSi: No such file or directory
> LAPW1 - Error
> [1]  + Done  ( ( $remote $machine[$p]  ...
> [1] 15413
> bash: line 0: cd: /home/dp3/CoSi: No such file or directory
> LAPW1 - Error
> [1]  + Done  ( ( $remote $machine[$p]  ...
> [1] 15438
> bash: line 0: cd: /home/dp3/CoSi: No such file or directory
> LAPW1 - Error
> [1]  + Done  ( ( $remote $machine[$p]  ...
> [1] 15463
> bash: line 0: cd: /home/dp3/CoSi: No such file or directory
> LAPW1 - Error
> [1]  + Done  ( ( $remote $machine[$p]  ...
> [1] 15489
> bash: line 0: cd: /home/dp3/CoSi: No such file or directory
> LAPW1 - Error
> [1]  + Done  ( ( $remote $machine[$p]  ...
> [1] 15514
> bash: line 0: cd: /home/dp3/CoSi: No such file or directory
> LAPW1 - Error
> [1]  + Done  ( ( $remote $machine[$p]  ...
> [1] 15539
> bash: line 0: cd: /home/dp3/CoSi: No such file or directory
> LAPW1 - Error
> [1]  + Done  ( ( $remote $machine[$p]  ...
>  node014(2) 0.000u 0.004s 0.01 0.00%  0+0k 0+0io 0pf+0w
>  node014(2) 0.004u 0.004s 0.00 88.89%  0+0k 0+0io 0pf+0w
>  node014(2) 0.000u 0.004s 0.01 0.00%  0+0k 0+0io 0pf+0w
>  node014(2) 0.008u 0.004s 0.01 120.00%  0+0k 0+0io 0pf+0w
>  node014(1) 0.004u 0.000s 0.01 40.00%  0+0k 0+0io 0pf+0w
>  node014(1) 0.004u 0.008s 0.05 22.64%  0+0k 0+0io 0pf+0w
>  node014(1) 0.000u 0.008s 0.02 0.00%  0+0k 0+0io 0pf+0w
> CoSi.scf1_1: No such file or directory.
>Summary of lapw1para:
>node014   k=11user=0.02   wallclock=278.13
>
> Here are the settings from the options file, I am using Ifort11.1
>
> current:FOPT:-FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback
> current:FPOPT:-FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback 
> -DFFTW3
> current:LDFLAGS:$(FOPT) -L/opt/intel/Compiler/11.1/046/mkl/lib/em64t -pthread
> current:DPARALLEL:'-DParallel'
> current:R_LIBS:-lmkl_lapack -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core 
> -openmp -lpthread -lguide
> current:RP_LIBS:-lmkl_scalapack_lp64 -lmkl_solver_lp64 -lmkl_blacs_lp64 
> -L/opt/local/fftw3/lib/ -lfftw3_mpi -lfftw3 $(R_LIBS)
> current:MPIRUN:mpirun -np _NP_ -machinefile _HOSTS_ _EXEC_
>
>
> Here is the .machines file
> #
> granularity:1
> 1:node014:1
> 1:node014:1
> 1:node014:1
> 1:node014:1
> extrafine:1
>
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien



--
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu 1-847-491-3996
"Research is to see what everybody else has seen, and to think what
nobody else has thought"
Albert Szent-Gyorgi
___
Wien mailing list
Wien at zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

[Wien] Parallel lapw1 bug, WIEN2K_12?

[Parker, David S.]

Dear all:

I am experiencing a problem with the (k-point) parallel version of lapw1 in the 
newest WIEN2K, version 12.  lapw1 works fine in single processor mode but when
I go to run lapw1 -p I get the error messages below.

I was using the 2010 version of WIEN2K and did not have these problems. Any 
ideas? Thanks in advance for your help - David Parker

dp3 at head:CoSi$ x lapw1 -p
starting parallel lapw1 at Mon Aug  6 10:50:10 EDT 2012
->  starting parallel LAPW1 jobs at Mon Aug  6 10:50:10 EDT 2012
running LAPW1 in parallel mode (using .machines)
4 number_of_parallel_jobs
[1] 15388
bash: line 0: cd: /home/dp3/CoSi: No such file or directory
LAPW1 - Error
[1]  + Done  ( ( $remote $machine[$p]  ...
[1] 15413
bash: line 0: cd: /home/dp3/CoSi: No such file or directory
LAPW1 - Error
[1]  + Done  ( ( $remote $machine[$p]  ...
[1] 15438
bash: line 0: cd: /home/dp3/CoSi: No such file or directory
LAPW1 - Error
[1]  + Done  ( ( $remote $machine[$p]  ...
[1] 15463
bash: line 0: cd: /home/dp3/CoSi: No such file or directory
LAPW1 - Error
[1]  + Done  ( ( $remote $machine[$p]  ...
[1] 15489
bash: line 0: cd: /home/dp3/CoSi: No such file or directory
LAPW1 - Error
[1]  + Done  ( ( $remote $machine[$p]  ...
[1] 15514
bash: line 0: cd: /home/dp3/CoSi: No such file or directory
LAPW1 - Error
[1]  + Done  ( ( $remote $machine[$p]  ...
[1] 15539
bash: line 0: cd: /home/dp3/CoSi: No such file or directory
LAPW1 - Error
[1]  + Done  ( ( $remote $machine[$p]  ...
 node014(2) 0.000u 0.004s 0.01 0.00%  0+0k 0+0io 0pf+0w
 node014(2) 0.004u 0.004s 0.00 88.89%  0+0k 0+0io 0pf+0w
 node014(2) 0.000u 0.004s 0.01 0.00%  0+0k 0+0io 0pf+0w
 node014(2) 0.008u 0.004s 0.01 120.00%  0+0k 0+0io 0pf+0w
 node014(1) 0.004u 0.000s 0.01 40.00%  0+0k 0+0io 0pf+0w
 node014(1) 0.004u 0.008s 0.05 22.64%  0+0k 0+0io 0pf+0w
 node014(1) 0.000u 0.008s 0.02 0.00%  0+0k 0+0io 0pf+0w
CoSi.scf1_1: No such file or directory.
   Summary of lapw1para:
   node014   k=11user=0.02   wallclock=278.13

Here are the settings from the options file, I am using Ifort11.1

current:FOPT:-FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback
current:FPOPT:-FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback 
-DFFTW3
current:LDFLAGS:$(FOPT) -L/opt/intel/Compiler/11.1/046/mkl/lib/em64t -pthread
current:DPARALLEL:'-DParallel'
current:R_LIBS:-lmkl_lapack -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core 
-openmp -lpthread -lguide
current:RP_LIBS:-lmkl_scalapack_lp64 -lmkl_solver_lp64 -lmkl_blacs_lp64 
-L/opt/local/fftw3/lib/ -lfftw3_mpi -lfftw3 $(R_LIBS)
current:MPIRUN:mpirun -np _NP_ -machinefile _HOSTS_ _EXEC_


Here is the .machines file
#
granularity:1
1:node014:1
1:node014:1
1:node014:1
1:node014:1
extrafine:1

[Wien] FW: K_list band format

[Parker, David S.]

Does anyone know where in the lapw1 code the k-vectors from a case.klist_band 
file are read? I want to modify the format descriptor
(lapw1 doesn't like k point labels of more than 3 digits).  Thanks in advance, 
David Parker
-- End of Forwarded Message

[Wien] converting *.struct format to another format

[Parker, David S.]

Mohaddeseh, it is simple; use the command "x structxyz" or "x struct2cif" and 
it should work (provided you have a struct file).  Best, David Parker


On 3/8/12 10:25 AM, "mohaddeseh abbasnejad"  wrote:



Dear users,

Whatever I try to convert the *.struct file to either *.xyz or *.cif format 
using "struct2xyz or struct2cif , it gives me such  message:
"GTFNAM - Exactly one commandline argument has to be given."
Would you please guide me to solve the problem.

Yours,
Mohaddeseh

[Wien] supercell

[Parker, David S.]

Saba, generally if I am running a system that is not big, such as the Heuslers 
or supercells thereof, 2000 k points in the full BZ is enough. For bigger 
systems the number of k-points will be limited by your patience and access to 
parallel computing resources, but for a basic scf calc I very rarely use more 
than 2000 k points. I have recently run an mBJ calculation on a structure that 
is a variant of the half-Heusler. without problems.  There should be no problem 
running LSDA+so calcs as you ask, when I do these I often incorporate so from 
the start.  Best, David Parker


On 2/17/12 1:54 PM, "Saba Sabeti"  wrote:

Dear all,
Thanks to Mr Fecher for his attention to my previous question, which was solved 
just after posing the question.
Now, I'm going to ask you all some other questions and I would be so thankful 
if you help me to solve them:

1. How many k-points are needed for a supercell calculation like AxB1-xCD when 
x=1/4-3/4, and while I use 5000 k-points for ACD and BCD?
 2. Can I do LSDA+so calculations like ACD(a half-heusler) case,I mean:
initialize+run scf
save case_nrel
initso
run scf+so
3. And a calculation similar to which has come in userguide for Becke-Johnson?
best regards

[Wien] a question about forces

[Parker, David S.]

Zhou, in running the second set of calculations did you include force 
convergence (i.e., run_lapw -fc 0.1) in your job script? If not the forces 
given in scf will be only partial forces (without a valence correction) and 
would not be expected to correspond to the small forces in your optimized 
structure. - David Parker


On 1/13/12 10:05 AM, "Zhou Bing"  wrote:



I am puzzled by a question about forces:

My case is a mineral (ulexite) with 2 Ca atoms, 2 Na atoms, 10 B atoms,
34 O atoms and 32 H-atoms in the unit cell. I have relaxed the atomic
positions using the following RMT-values: Ca=2.27, Na=2.21, B=1.27,
O=0.9, H=0.48. The matrix size was 11400 (RKM=2.50), with 3 k-points in
the IBZ and GMAX=20. All forces ended up below 1 mRy/au.

After I noticed that these RMT-values were different from the ones
recommended by setrmt_lapw, I choose the values suggested by the latter:
Ca=2.15, Na=2.09, B=1.22, O=1.18, H=0.57. Without altering the positions
and using the same settings as before (including RKM=2.50, now resulting
in a matrix size of almost 7000 only), the forces became suddenly much
higher, with values of sometimes more than 20 mRy/au.

In increased RKM to 3.00 (leading to the same matrix size of 11700 as
before) and increased the number of k-points to 15: this did not alter
these high forces in a significant way.

I need the optimized internal positions, and it is worrying that a small
(?) change of RMT but an equivalent accuracy leads to forces that are so
much different. Which of both sets of values can I trust, and why? Is
there any other parameter that I failed to consider?

The atoms with these high forces are O and H only (although there are
changes in the forces on Ca, Na and B as well, but one order of
magnitude less). Not all of the O atoms, however: twelve of them show a
significantly smaller change of force than the others.

Both sets of calculations were cross-checked on several computer
systems, to exclude any compilation-related problems.

Does anybody have a clue?








___
Wien mailing list
Wien at zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

[Wien] lapw2 error

[Parker, David S.]

Dear all, I am attempting to run an mBJ scf calculation on tetragonal CuInS2.  
I have already run the non-mbJ scf calculation and am attempting to set up the 
*vresp files to run the mBJ calculation.  Here is what happens:

dp3 at head:CuInS2$ run_lapw -NI -i 1
 LAPW0 END
 LAPW1 END
forrtl: severe (64): input conversion error, unit 1001, file 
/home/dp3/CuInS2/031
Image  PCRoutineLineSource
lapw2c 0051FF9D  Unknown   Unknown  Unknown
lapw2c 0051EAA5  Unknown   Unknown  Unknown
lapw2c 004BE0F9  Unknown   Unknown  Unknown
lapw2c 004780F8  Unknown   Unknown  Unknown
lapw2c 00477908  Unknown   Unknown  Unknown
lapw2c 0049A83B  Unknown   Unknown  Unknown
lapw2c 00460CB2  outp_ 180  outp.f
lapw2c 004531C5  l2main_  1710  
l2main_tmp_.F
lapw2c 0045C7A3  MAIN__546  lapw2_tmp_.F
lapw2c 00403E0C  Unknown   Unknown  Unknown
libc.so.6  2B9F7642A586  Unknown   Unknown  Unknown
lapw2c 00403D09  Unknown   Unknown  Unknown

>   stop error

I am using version 10.1 and have identical problems with two other 
isostructural materials. Has anyone else experienced this problem?

I attach the case.in0 file.  Thanks in advance, David Parker

TOT   13(5...CA-LDA, 13...PBE-GGA, 11...WC-GGA)
R2V  IFFT  (R2V)
  40  40  902.00  1min IFFT-parameters, enhancement factor, iprint

[Wien] quick initso question

[Parker, David S.]

Anyone know if the magnetization direction in case.inso is in lattice 
coordinates or Cartesian coordinates?  Thanks, David Parker


On 12/1/11 9:17 AM, "Stefaan Cottenier"  wrote:



> I am not sure how can I add a number in the "label" field.Do you mean in
> the case.struct file or anywhere else? Can you tell me in detail?

If you use w2web, there is a field provided for this.

If you edit case.struct directly, then put numbers (1,2,...) immediately
after the chemical symbol (hence: Fe1, Fe2, ...). Be sure to delete a
space first, as the file is position sensitive.

Stefaan
___
Wien mailing list
Wien at zeus.theochem.tuwien.ac.at
hxxp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

[Wien] Missing data in DOS plot & data file

[Parker, David S.]

JK, look in wherever you have the "SRC_tetra" directory, the tetra Makefile 
should be in there. Then once it is compiled copy the executable "tetra" to 
your $WIENROOT directory - where you keep the executables. - David


On 11/21/11 12:30 PM, "J. K. Balamurugan"  wrote:

Dear Prof. David,

As you have mentioned I do not find the 'NaN' in the case.qtlup/dn files.
While I hope that your suggestion could help me to get the full data & plot
of DOS, I do not understand/know where/what file in which I must add the
flag that you have mentioned - I mean I do not understand which file you
mean by "tetra Makefile". I hope you can write for me and others a littler
more in detail. I also bit worried by your note that "other optimization
flags may vary " as whether the addition of the flag might give any
error or wrong results.

Thanks.

On Mon, Nov 21, 2011 at 8:51 AM, Parker, David S.  wrote:

> Dear J K and everyone else: The instructions below were helpful in solving
> a problem
> With tetra producing some DOS and partial DOS values as 'NaN' despite the
> lack
> Of an 'NaN' in the corresponding case.qtl file.  To fix just add the flag
> ("-fp-model precise") below at the end
> Of this line in the tetra Makefile, i.e.
>
> FOPT = -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback
> -fp-model precise
>
> Note that the other optimization flags may vary depending upon your
> compiler, architecture, etc.
>
> And then compile using "make" as usual.
>
> Good luck - David Parker
>
>
>
> On 11/20/11 9:58 PM, "J. K. Balamurugan"  wrote:
>
> Dear Wien2k developers and users,
>
> I am using Wien2k 11.1 version for calculating band structure thee and DOS
> of some non-magnetic and magnetic systems. Fewer times I find that in the
> DOS plots and in the DOS data file a portion of data is missing! I use
> PBE-GGA functional with 1000 k-points and RKmax = 8 for my calculations.
> The structure is non-centrosymmetric. In the case of a non-magnetic
> quaternary semiconducting sulfide, I got the DOS plot and data wherein some
> portion of graph and data were missing. I recalculated the DOS and found
> the same problem. I repeated the whole calculation in another
> folder/experiment starting from structure generation, initialization etc,
> yet the problem persists. After that I left that work as it is -
> uncompleted!
>
> Following the above I calculated another magnetic system in which Fe is the
> magnetic element with same structure and I got everything fine. Full DOS
> data and plot I got. But, when I continued the same method for a third
> compound with the same structure I got that problem again. DOS of spin up
> electrons' plot and graph are perfectly OK. But, for spin down electrons I
> got the same problem that some portion of data are missing.
>
> I have attached a picture file (*png format). Please view and note that in
> energy range -0.38355 eV to -0.05701 eV, in the pictures there is no
> graph-line showing the DOS and correspondingly the letters "NaN" instead of
> numbers appear in the data file. (I am not able to send the data file as
> the file size bigger than the allowed 40kB for the mailinglist.) I do not
> know any other users faced this problem in Wien2k. I am also looking for
> some suggestions to get the full data and graph-line in the picture.
>
> Thanks.
>
> With kind regards,
>
> K.  Balamurugan
> Pittsburgh, USA.
>
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> hxxp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>



--
*K. Balamurugan
Pittsburgh, USA.
+1 412 961 5055*

[Wien] Missing data in DOS plot & data file

[Parker, David S.]

Dear J K and everyone else: The instructions below were helpful in solving a 
problem
With tetra producing some DOS and partial DOS values as 'NaN' despite the lack
Of an 'NaN' in the corresponding case.qtl file.  To fix just add the flag 
("-fp-model precise") below at the end
Of this line in the tetra Makefile, i.e.

FOPT = -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback 
-fp-model precise

Note that the other optimization flags may vary depending upon your compiler, 
architecture, etc.

And then compile using "make" as usual.

Good luck - David Parker



On 11/20/11 9:58 PM, "J. K. Balamurugan"  wrote:

Dear Wien2k developers and users,

I am using Wien2k 11.1 version for calculating band structure thee and DOS
of some non-magnetic and magnetic systems. Fewer times I find that in the
DOS plots and in the DOS data file a portion of data is missing! I use
PBE-GGA functional with 1000 k-points and RKmax = 8 for my calculations.
The structure is non-centrosymmetric. In the case of a non-magnetic
quaternary semiconducting sulfide, I got the DOS plot and data wherein some
portion of graph and data were missing. I recalculated the DOS and found
the same problem. I repeated the whole calculation in another
folder/experiment starting from structure generation, initialization etc,
yet the problem persists. After that I left that work as it is -
uncompleted!

Following the above I calculated another magnetic system in which Fe is the
magnetic element with same structure and I got everything fine. Full DOS
data and plot I got. But, when I continued the same method for a third
compound with the same structure I got that problem again. DOS of spin up
electrons' plot and graph are perfectly OK. But, for spin down electrons I
got the same problem that some portion of data are missing.

I have attached a picture file (*png format). Please view and note that in
energy range -0.38355 eV to -0.05701 eV, in the pictures there is no
graph-line showing the DOS and correspondingly the letters "NaN" instead of
numbers appear in the data file. (I am not able to send the data file as
the file size bigger than the allowed 40kB for the mailinglist.) I do not
know any other users faced this problem in Wien2k. I am also looking for
some suggestions to get the full data and graph-line in the picture.

Thanks.

With kind regards,

K.  Balamurugan
Pittsburgh, USA.

[Wien] (no subject)

[Parker, David S.]

Margo, no one knows - it is a function of temperature and doping and will in 
general be material specific.  The virtue of using Boltztrap
Is that one can compute the thermopower without needing to know the value.  You 
can make an estimate if you have published values of the mobility for the 
material at hand, but in general estimating the relaxation time from first 
principles is a hard problem. - David
-Original Message-
From: wien-bounces at zeus.theochem.tuwien.ac.at 
[mailto:wien-boun...@zeus.theochem.tuwien.ac.at] On Behalf Of Malgorzata Bukala
Sent: Thursday, October 06, 2011 10:32 AM
To: wien at zeus.theochem.tuwien.ac.at
Subject: [Wien] (no subject)

Dear users of  Wien2k,

I have a question about BoltzTraP code. 
In this program to simplify the Boltzmann equation the relaxation time 
approximation is adopted and relaxation time is kept constant. But what is the 
value of this parameter?

Margo 

[Wien] Eigenvalue mix-up - large unit cells

[Parker, David S.]

Dear WIEN2K users:

Has anyone else experienced an apparent bug in WIEN (I am using WIEN_2010), 
which seems to occur
only for fairly large unit cells (nelectron > ~ 400), where eigenvalues are not 
properly sorted in spaghetti and 
other programs - this leads to bands that are terribly jagged rather than 
smooth? Similar problems show up in the 
case.energy_1, energy_2,( when these files are gathered together) when lapw1 is 
run in parallel, so this appears to be an lapw1 bug rather than spaghetti.  
Thanks in advance - David Parker

[Wien] Tetra NaN problem solved

[Parker, David S.]

Dear All: The instructions below were helpful in solving a problem
With tetra producing some DOS and partial DOS values as 'NaN' despite the lack
Of an 'NaN' in the corresponding case.qtl file.  To fix just add the flag 
("-fp-model precise") below at the end
Of this line in the tetra Makefile, i.e.

FOPT = -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback 
-fp-model precise

Note that the other optimization flags may vary depending upon your compiler, 
arthitecture, etc.

And then compile using "make" as usual.

Good luck - David Parker






Dear colleagues,
when using tetra (WIEN2k 9.1), compiled with the Intel Fortran compiler
11.0, occasionally the calculation of DOS and partial DOSs results in
'NaN' for single energy values. This is a matter of numerical precision.
When compiling tetra with the option:
-fp-model precise
, which disables optimization that can change the result of
floating-point calculations, the problem wasn't observed up to now.
The effect of this compiler option on the performance of the program
seems to be marginal.

Best regards

Ulrich Wedig

--
-
Dr. Ulrich Wedig  Tel. 0711/6891535
Max-Planck-Institut fuer Festkoerperforschung FAX  0711/6891502
Heisenbergstr. 1
70569 Stuttgart   U.Wedig at fkf.mpg.de
-