Re: [Wien] WIEN2WANNIER

[Rubel, Oleg]

I would not expect any major problems. From the past experience: Compatibility 
issues (minor) usually arise when wannier90 developers change options in the 
input file case.win for wannier90.x This file is prepared by "write_win" and 
can be modified for compatibility. If you see any issues, please send it to 
this mailing list.

"x w2w" computes the overlaps Mmn and initial projections Amn, and writes them, 
together with
the eigenvalues En, to case.mmn, case.amn, and case.eig. These files should be 
fine for the new wannier90 version.

I hope it will help
Oleg


From: Wien  on behalf of shahrbano 
rahimi 
Sent: Friday, April 16, 2021 13:18
To: wien@zeus.theochem.tuwien.ac.at
Subject: [Wien] WIEN2WANNIER

Dear all,
Is the following version of the Wannier90 interfaced to the Wien2k by the 
WIEN2WANNIER?
https://iopscience.iop.org/article/10.1088/1361-648X/ab51ff/meta
Thank you for your kind attention to this matter.
Best Regards,
Shahrbano Rahimi
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] WIEN2WANNIER

[shahrbano rahimi]

Dear all,
Is the following version of the Wannier90 interfaced to the Wien2k by the
WIEN2WANNIER?
https://iopscience.iop.org/article/10.1088/1361-648X/ab51ff/meta
Thank you for your kind attention to this matter.
Best Regards,
Shahrbano Rahimi
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] wien2wannier and local coordinate systems

[Marcus Ekholm]

Dear all,

I am trying to calculate Wannier functions for NiO with wien2wannier and 
wannier90. I use the attached struct file, which uses hexagonal coordinates. I 
think this choice of coordinates will make the interpretation of dxy, dxz,  
a bit confusing, since the lattice vectors A, B, C do not point along the Ni-O 
bonds, as we are used to seeing the (x,y,z)-axes in this context.

So, do I need to use local rotation matrices in the Wien2k scf calculations, or 
can the rotation of axes be done in wien2wannier, which seems hinted at in the 
wien2wannier manual?

Best regards



NiO.struct
Description: NiO.struct
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier with SOC but without sp

[Gavin Abo]

Regarding your question 1) below, yes, it is necessary to add the -up 
and -dn to the "x w2w -so" command as the Wien2Wannier 2.0 User’s Guide 
says on page 5:


"Note: it does not make sense to run x w2w -so without either -up or -dn;"

Regarding your question 2) below, in the thread of posts for a 
wien2wannier spin polarized with spin orbit coupling calculation [2], it 
looks like they did a converged scf calculation with


init -b -sp
runsp
initso
runsp -so

before doing the wien2wannier calculation [3].  This implies using a 
counterpart scf calculation for a non-spin polarized with spin orbit 
coupling calculation.


As you probably know, a non-spin polarized with spin orbit coupling scf 
calculation could be done with something like


init -b
run
initso
run -so

However, the wien2wannier article [4] seems to suggest that spin orbit 
calculations done with it must be spin polarized:


"Spin-orbit calculation must be run as formally spin-polarized even if 
the polarization is zero."


However, while it might be possible to “mimick” a spin polarized 
calculation similar to what is described for a optic calculation in 
section "8.17.1 Execution" on page 177 in the WIEN2k 17.1 usersguide [6].


The accepted scf procedure for wien2wannier [7] seems to be to use 
runsp_c instead:


init -b -sp
runsp_c
initso
runsp_c -so

[1] 
https://github.com/wien2wannier/wien2wannier/releases/download/v2.0.0/wien2wannier_userguide.pdf
[2] 
http://wien.zeus.theochem.tuwien.ac.narkive.com/lEYFiNqR/error-in-wien2wannier-for-spin-orbit-coupling-case

[3] https://github.com/wien2wannier/wien2wannier/wiki/wien2wannier-with-SOC
[4] https://arxiv.org/abs/1004.3934v1
[5] 
http://wien.zeus.theochem.tuwien.ac.narkive.com/uipUZHQ4/wien2wannier-for-non-spinpolarized-soc-cases

[6] http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf
[7] 
http://zeus.theochem.tuwien.ac.at/pipermail/wien/2014-December/022086.html


On 1/2/2018 1:50 AM, Sahra Sahraii wrote:

Dear wien2k users and developer

I have a question regarding to wien2wannier with soc, but without sp.

I found the  work flow in Wien2wannier user guide  for spin-orbit 
coupling :


|$ prepare_w2wdir W $ init_w2w -up ... > findbands -so -all -1 1 
(13:30:56) > write_inwf -f W (13:31:01) ... > minimal and maximal band 
indices [Nmin Nmax]? 41 46 > next proj. (6 to go; Ctrl-D if done)? 
1:dt2g added 3 projections: 2:dxy,dxz,dyz > next proj. (3 to go; 
Ctrl-D if done)? 1:dt2g added 3 projections: 2:dxy,dxz,dyz --> 6 
bands, 6 initial projections ... $ x lapw1; x lapwso $ x w2w -so -up; 
w2w -so -dn $ x wannier90 -so|
 I wonder that for considering spin orbit coupling I also should 
consider spin up and down.

1) Is it necessary to add up and dn in the above commands.

2) I also wants to know  if   I should do a converged  so Wien2k 
calculation  before running wien2wannier  or I  should do a non so 
calculation?

Thank you in advance
Best
Sahraii


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier with SOC but without sp

[Sahra Sahraii]

Dear wien2k users and developer
I have a question regarding to wien2wannier with soc, but without sp. 
I found the  work flow in Wien2wannier user guide  for spin-orbit coupling :
$ prepare_w2wdir W
$ init_w2w -up
...
> findbands -so -all -1 1 (13:30:56)
> write_inwf -f W (13:31:01)
...
> minimal and maximal band indices [Nmin Nmax]? 41 46
> next proj. (6 to go; Ctrl-D if done)? 1:dt2g
added 3 projections: 2:dxy,dxz,dyz
> next proj. (3 to go; Ctrl-D if done)? 1:dt2g
added 3 projections: 2:dxy,dxz,dyz

--> 6 bands, 6 initial projections
...
$ x lapw1; x lapwso
$ x w2w -so -up; w2w -so -dn
$ x wannier90 -so I wonder that for considering spin orbit coupling I also 
should consider spin up and down.Is it necessary to add up and dn in the above 
commands.
I also wants to know  if   I should do a converged  so Wien2k calculation  
before running wien2wannier  or I  should do a non so calculation? 
Thank you in advanceBestSahraii







___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier and wannier90

[Gavin Abo]

FYI, write_inwf_lapw in WIEN2k 17.1 should be from version 1 of 
wien2wannier.  If you want write_inwf_lapw from the version 2 of 
wien2wannier.  You may download and install it [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16099.html 
].


On 12/31/2017 9:10 AM, Oleg Rubel wrote:
The wien2wannier comes with wien2k, but the wannier90 does not. It is, 
however, straightforward to install wannier90.


Thanks
Oleg

--
Oleg Rubel (PhD, PEng)
Department of Materials Science and Engineering
McMaster University
JHE 359, 1280 Main Street West, Hamilton, Ontario L8S 4L8, Canada
Email: rub...@mcmaster.ca
Tel: +1-905-525-9140, ext. 24094
Web: http://olegrubel.mcmaster.ca

On 2017-Dec-31 02:55, Sahra Sahraii wrote:





Dear wien2k users,

I am running my calculation with wien 17, I just want to know if 
wien2wannier and also wannier 90 are implemented in wien2k17 or they 
should be downloaded and installed separately?


Best
Sahraii 


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier and wannier90

[Oleg Rubel]

The wien2wannier comes with wien2k, but the wannier90 does not. It is, 
however, straightforward to install wannier90.


Thanks
Oleg

--
Oleg Rubel (PhD, PEng)
Department of Materials Science and Engineering
McMaster University
JHE 359, 1280 Main Street West, Hamilton, Ontario L8S 4L8, Canada
Email: rub...@mcmaster.ca
Tel: +1-905-525-9140, ext. 24094
Web: http://olegrubel.mcmaster.ca

On 2017-Dec-31 02:55, Sahra Sahraii wrote:





Dear wien2k users,

I am running my calculation with wien 17, I just want to know if 
wien2wannier and also wannier 90 are implemented in wien2k17 or they 
should be downloaded and installed separately?


Best
Sahraii





___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier and wannier90

[Sahra Sahraii]

 

 Dear wien2k users,
I am running my calculation with wien 17, I just want to know if wien2wannier 
and also wannier 90 are implemented in wien2k17 or they should be downloaded 
and installed separately?

BestSahraii



   ___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier interfaced with wien2k 17.1

[Rubel, Oleg]

Hello Jianpeng,

> I don't understand why in GaAs including spin-orbit coupling would induce 
> such big changes in the MLWFs. But anyway, it is probably what it is.

I fully share your discomfort. During the Workshop last week, symmetry-adapted 
WFs were mentioned, but I do not have experience with that. Maybe other members 
of the List can point to a solution?

> My purpose is to extract some Kondo coupling  parameters between the Ce 4f 
> and 5d states. In my case, it may be important to generate atomic-orbital
> like WFs. I am not sure whether I should include 4f WFs or not. I am still 
> playing with it.

I agree that atomic orbitals-like WFs would be an ideal tool for that. To 
decide on which states to include in construction of WFs, I would plot a fat 
band structure to get an idea of hybridization.


Thank you
Oleg

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier interfaced with wien2k 17.1

[Jianpeng Liu]

Hi Oleg,

I don't understand why in GaAs including spin-orbit coupling would induce
such big changes in the MLWFs. But anyway, it is probably what it is.

My purpose is to extract some Kondo coupling  parameters between the Ce 4f
and 5d states. In my case, it may be important to generate atomic-orbital
like WFs. I am not sure whether I should include 4f WFs or not. I am still
playing with it.

Best,

Jianpeng


On Mon, Sep 25, 2017 at 4:12 PM, Rubel, Oleg  wrote:

> Hello Jianpeng,
>
> > As to difference between the Wannier centers with and without SOC: did
> you carry out maximal localization procedure in both cases (with and
> without SOC)?
>
> Yes, I did optimization in both cases.
>
> > What if you simply do a single-step projection, i.e., set num_iter=0 ?
>
> I do not think you will get MLWF in this case since the purpose of
> iterations is to achieve a max localization.
>
> > Then the projected localized functions will not hybridize with each
> other, and should have the symmetry of atomic orbitals (as long as these
> initial projections are well localized after some disentanglement
> procedure).
>
> GaAs is easy since there is no need for disentanglement.
>
> > As to the meaning of the tight-binding model: I think it is meaningful
> as long as the low-energy bandstructure is the same as the DFT
> bandstructure and  the Wannier functions are well localized. But I agree it
> may be more convenient in some cases  if the Wannier functions are
> atomic-orbital like.
>
> If you only need to fit the band structure, the it is OK to have WF
> shifted. But usually the objective is beyond that.  What would you like to
> do with WF after wannierization?
>
>
> Thank you
> Oleg
>
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:  http://www.mail-archive.com/wi
> e...@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] wien2wannier interfaced with wien2k 17.1

[Rubel, Oleg]

Hello Jianpeng,

> As to difference between the Wannier centers with and without SOC: did you 
> carry out maximal localization procedure in both cases (with and without SOC)?

Yes, I did optimization in both cases.

> What if you simply do a single-step projection, i.e., set num_iter=0 ?

I do not think you will get MLWF in this case since the purpose of iterations 
is to achieve a max localization.

> Then the projected localized functions will not hybridize with each other, 
> and should have the symmetry of atomic orbitals (as long as these initial 
> projections are well localized after some disentanglement procedure).

GaAs is easy since there is no need for disentanglement.

> As to the meaning of the tight-binding model: I think it is meaningful as 
> long as the low-energy bandstructure is the same as the DFT bandstructure and 
>  the Wannier functions are well localized. But I agree it may be more 
> convenient in some cases  if the Wannier functions are atomic-orbital like.

If you only need to fit the band structure, the it is OK to have WF shifted. 
But usually the objective is beyond that.  What would you like to do with WF 
after wannierization?


Thank you
Oleg

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier interfaced with wien2k 17.1

[Jianpeng Liu]

Hi Oleg,

Thanks for testing the procedures on GaAs. As to difference between the
Wannier centers with and without SOC: did you carry out maximal
localization procedure in both cases (with and without SOC)? What if you
simply do a single-step projection, i.e., set num_iter=0 ? Then the
projected localized functions will not hybridize with each other, and
should have the symmetry of atomic orbitals (as long as these initial
projections are well localized after some disentanglement procedure).

As to the meaning of the tight-binding model: I think it is meaningful as
long as the low-energy bandstructure is the same as the DFT bandstructure
and  the Wannier functions are well localized. But I agree it may be more
convenient in some cases  if the Wannier functions are atomic-orbital like.

Thanks!

Jianpeng


On Mon, Sep 25, 2017 at 12:49 PM, Rubel, Oleg  wrote:

> Dear Jianpeng:
>
> I applied your procedure to WF in zinc-blende GaAs. Your procedure works.
> I had to do two extra steps
> $ cp wannier.inwf wannier.inwfup
> $ cp wannier.inwf wannier.inwfdn
> before running
> $ x w2w -so -up
> $ x w2w -so -dn
>
> The projections are:
> begin projections
>   1:sp3(u,d)
>   2:sp3(u,d)
> end projections
>
> At the end I got the following output with -so and -sp options:
>
>  Final State
>   WF centre and spread1  ( -0.457506,  0.457588,  0.457476 )
>  4.36038947
>   WF centre and spread2  (  0.457535,  0.457378, -0.457522 )
>  4.36341214
>   WF centre and spread3  ( -0.457477, -0.457464, -0.457434 )
>  4.36424964
>   WF centre and spread4  (  0.457409, -0.457465,  0.457515 )
>  4.36405300
>   WF centre and spread5  (  1.800179, -1.026445, -1.026433 )
>  2.89020535
>   WF centre and spread6  (  1.800146, -1.800199, -1.800158 )
>  2.89044140
>   WF centre and spread7  (  1.026459, -1.026417, -1.800189 )
>  2.88989157
>   WF centre and spread8  (  1.026408, -1.800139, -1.026430 )
>  2.89026491
>   WF centre and spread9  ( -0.457482,  0.457621,  0.457463 )
>  4.36089512
>   WF centre and spread   10  (  0.457601,  0.457520, -0.457595 )
>  4.35805760
>   WF centre and spread   11  ( -0.457628, -0.457579, -0.457578 )
>  4.35685014
>   WF centre and spread   12  (  0.457550, -0.457579,  0.457661 )
>  4.35678662
>   WF centre and spread   13  (  1.800180, -1.026454, -1.026421 )
>  2.89005317
>   WF centre and spread   14  (  1.800147, -1.800197, -1.800166 )
>  2.88979441
>   WF centre and spread   15  (  1.026464, -1.026412, -1.800185 )
>  2.89031329
>   WF centre and spread   16  (  1.026412, -1.800135, -1.026420 )
>  2.88997190
>   Sum of centres and spreads ( 11.306397,-11.306377,-11.306414 )
> 58.00562975
>
> It can be compared to the calculation without -so and -sp
>
>  Final State
>   WF centre and spread1  ( -0.00,  0.00, -0.00 )
>  1.91775879
>   WF centre and spread2  (  0.00, -0.00,  0.00 )
>  5.85946098
>   WF centre and spread3  ( -0.00, -0.00, -0.00 )
>  5.85946098
>   WF centre and spread4  (  0.00,  0.00,  0.00 )
>  5.85946098
>   WF centre and spread5  (  1.413300, -1.413300, -1.413300 )
>  1.61203280
>   WF centre and spread6  (  1.413300, -1.413300, -1.413300 )
>  3.81968345
>   WF centre and spread7  (  1.413300, -1.413300, -1.413300 )
>  3.81968345
>   WF centre and spread8  (  1.413300, -1.413300, -1.413300 )
>  3.81968345
>   Sum of centres and spreads (  5.653200, -5.653200, -5.653200 )
> 32.56722487
>
> It looks like Wannier centres with SOC are not centred at atomic
> positions, which implies that their interpretation as atomic orbitals will
> be a stretch. I am not sure how useful the Hamiltonian will be then.
>
>
> Thank you
> Oleg
> --
> Oleg Rubel (PhD, PEng)
> Department of Materials Science and Engineering
> McMaster University
> JHE 359, 1280 Main Street West, Hamilton, Ontario L8S 4L8, Canada
> Email: rub...@mcmaster.ca
> Tel: +1-905-525-9140, ext. 24094
> Web: http://olegrubel.mcmaster.ca
>
> > On Sep 25, 2017, at 10:52, Jianpeng Liu  wrote:
> >
> > Dear WIEN2k users and developers,
> >
> > I am using wien2wannier to generate a tight-binding model for some
> rare-earth compound including Ce.  Both spin-orbit coupling and
> spin-polarization have been included in my calculation. The following is my
> workflow:
> >
> > 1) Finish a scf calculation, then prepare_w2wdir wannier
> >
> > 2) init_w2w -up
> >   At this step, I have to specify the energy windows.
> >
> > 3) write_inwf -f wannier
> >   At this step, I have to input the minimal and maximal band indices
> exported from the previous step, then specify the projections of the
> Wannier functions. I want to project onto 5 Ce d orbitals, but I made two
> identical copies of projections, i.e.:
> > Ce:d
> > Ce:d
> > One for spin-up, and the other for spin-dn, so in total there are 10
> projections. I copied the generated file wannier.inwf to wannier.inwfup and
> wannier.inwfdn. Now both wannier.inw

Re: [Wien] wien2wannier interfaced with wien2k 17.1

[Rubel, Oleg]

Dear Jianpeng:

I applied your procedure to WF in zinc-blende GaAs. Your procedure works. I had 
to do two extra steps
$ cp wannier.inwf wannier.inwfup
$ cp wannier.inwf wannier.inwfdn
before running
$ x w2w -so -up
$ x w2w -so -dn

The projections are:
begin projections
  1:sp3(u,d)
  2:sp3(u,d)
end projections

At the end I got the following output with -so and -sp options:

 Final State
  WF centre and spread1  ( -0.457506,  0.457588,  0.457476 ) 4.36038947
  WF centre and spread2  (  0.457535,  0.457378, -0.457522 ) 4.36341214
  WF centre and spread3  ( -0.457477, -0.457464, -0.457434 ) 4.36424964
  WF centre and spread4  (  0.457409, -0.457465,  0.457515 ) 4.36405300
  WF centre and spread5  (  1.800179, -1.026445, -1.026433 ) 2.89020535
  WF centre and spread6  (  1.800146, -1.800199, -1.800158 ) 2.89044140
  WF centre and spread7  (  1.026459, -1.026417, -1.800189 ) 2.88989157
  WF centre and spread8  (  1.026408, -1.800139, -1.026430 ) 2.89026491
  WF centre and spread9  ( -0.457482,  0.457621,  0.457463 ) 4.36089512
  WF centre and spread   10  (  0.457601,  0.457520, -0.457595 ) 4.35805760
  WF centre and spread   11  ( -0.457628, -0.457579, -0.457578 ) 4.35685014
  WF centre and spread   12  (  0.457550, -0.457579,  0.457661 ) 4.35678662
  WF centre and spread   13  (  1.800180, -1.026454, -1.026421 ) 2.89005317
  WF centre and spread   14  (  1.800147, -1.800197, -1.800166 ) 2.88979441
  WF centre and spread   15  (  1.026464, -1.026412, -1.800185 ) 2.89031329
  WF centre and spread   16  (  1.026412, -1.800135, -1.026420 ) 2.88997190
  Sum of centres and spreads ( 11.306397,-11.306377,-11.306414 )58.00562975

It can be compared to the calculation without -so and -sp

 Final State
  WF centre and spread1  ( -0.00,  0.00, -0.00 ) 1.91775879
  WF centre and spread2  (  0.00, -0.00,  0.00 ) 5.85946098
  WF centre and spread3  ( -0.00, -0.00, -0.00 ) 5.85946098
  WF centre and spread4  (  0.00,  0.00,  0.00 ) 5.85946098
  WF centre and spread5  (  1.413300, -1.413300, -1.413300 ) 1.61203280
  WF centre and spread6  (  1.413300, -1.413300, -1.413300 ) 3.81968345
  WF centre and spread7  (  1.413300, -1.413300, -1.413300 ) 3.81968345
  WF centre and spread8  (  1.413300, -1.413300, -1.413300 ) 3.81968345
  Sum of centres and spreads (  5.653200, -5.653200, -5.653200 )32.56722487

It looks like Wannier centres with SOC are not centred at atomic positions, 
which implies that their interpretation as atomic orbitals will be a stretch. I 
am not sure how useful the Hamiltonian will be then.


Thank you
Oleg
--
Oleg Rubel (PhD, PEng)
Department of Materials Science and Engineering
McMaster University
JHE 359, 1280 Main Street West, Hamilton, Ontario L8S 4L8, Canada
Email: rub...@mcmaster.ca
Tel: +1-905-525-9140, ext. 24094
Web: http://olegrubel.mcmaster.ca

> On Sep 25, 2017, at 10:52, Jianpeng Liu  wrote:
> 
> Dear WIEN2k users and developers,
> 
> I am using wien2wannier to generate a tight-binding model for some rare-earth 
> compound including Ce.  Both spin-orbit coupling and spin-polarization have 
> been included in my calculation. The following is my workflow:
> 
> 1) Finish a scf calculation, then prepare_w2wdir wannier
> 
> 2) init_w2w -up
>   At this step, I have to specify the energy windows.
> 
> 3) write_inwf -f wannier
>   At this step, I have to input the minimal and maximal band indices  
> exported from the previous step, then specify the projections of the Wannier 
> functions. I want to project onto 5 Ce d orbitals, but I made two identical 
> copies of projections, i.e.: 
> Ce:d
> Ce:d
> One for spin-up, and the other for spin-dn, so in total there are 10 
> projections. I copied the generated file wannier.inwf to wannier.inwfup and 
> wannier.inwfdn. Now both wannier.inwfup and .inwfdn have 10 projections, but 
> actually there are only 5 orbitals without the spin degrees of freedom. Did I 
> do it correctly?
> 
> 4) Then I wrote a wannier.win file by myself, in which there 
> are 10 *spinor* Wannier-function projections, and I set spinors=.true. (is 
> this correct?).
> 
> 5)With all the inputs generated from the previous steps, I re-run the lapw1 
> calculation on the full BZ mesh, run wannier90 -pp to generate .nnkp file, 
> run w2w, and then finally wannier90:  
>   x lapw1 -up -p
>   x lapw1 -dn -p
>   x lapwso -up -p
>   x wannier90 -pp
>   x w2w -so -up -p
>   x w2w -so -dn -p
>   x wannier90 -so
> 
> The above is my workflow of wien2wannier.  The code seems to be running well, 
> but I am not sure if I did everything correctly. In particular I am worried 
> that there are 2 identical copies of the orbital projections in both 
> wannier.inwfup and .inwfdn. I would like to make sure that it is correct. I 
> would greatly appreciat

[Wien] wien2wannier interfaced with wien2k 17.1

[Jianpeng Liu]

Dear WIEN2k users and developers,

I am using wien2wannier to generate a tight-binding model for some
rare-earth compound including Ce.  Both spin-orbit coupling and
spin-polarization have been included in my calculation. The following is my
workflow:

1) Finish a scf calculation, then prepare_w2wdir wannier

2) init_w2w -up
  At this step, I have to specify the energy windows.

3) write_inwf -f wannier
  At this step, I have to input the minimal and maximal band indices
exported from the previous step, then specify the projections of the
Wannier functions. I want to project onto 5 Ce d orbitals, but I made two
identical copies of projections, i.e.:
Ce:d
Ce:d
One for spin-up, and the other for spin-dn, so in total there are 10
projections. I copied the generated file wannier.inwf to wannier.inwfup and
wannier.inwfdn. Now both wannier.inwfup and .inwfdn have 10 projections,
but actually there are only 5 orbitals without the spin degrees of freedom.
Did I do it correctly?

4) Then I wrote a wannier.win file by myself, in which there
are 10 *spinor* Wannier-function projections, and I set spinors=.true. (is
this correct?).

5)With all the inputs generated from the previous steps, I re-run the lapw1
calculation on the full BZ mesh, run wannier90 -pp to generate .nnkp file,
run w2w, and then finally wannier90:
  x lapw1 -up -p
  x lapw1 -dn -p
  x lapwso -up -p
  x wannier90 -pp
  x w2w -so -up -p
  x w2w -so -dn -p
  x wannier90 -so

The above is my workflow of wien2wannier.  The code seems to be running
well, but I am not sure if I did everything correctly. In particular I am
worried that there are 2 identical copies of the orbital projections in
both wannier.inwfup and .inwfdn. I would like to make sure that it is
correct. I would greatly appreciate your help.

Best,
Jianpeng
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier with SOC in WIEN2k 16.1

[Peter Blaha]

I've corrected the version on the web. Just download SRC.tar.gz.

It also contains a small fix for all run*_lapw scripts (VERSION in scf 
files corrected).


On 12/15/2016 08:44 PM, Elias Assmann wrote:

Dear Kefeng Wang,

On 12/15/2016 06:01 PM, Kefeng Wang wrote:

2.   Then I run “init_w2w –up”, after k mesh (10 10 10) and find
band, “write_inwf” shows “error: unrecognized arguments: -up” and
init_w2w exit.  I also found the help file did not include [-up/dn]
option for write_inwf command. So I manually run write_inwf and then
copy case.inwf to case.inwfup and case.inwfdn.  Is this right?


Oops, this isn't right!  For some reason, the latest version of that
script did not make it into the 16.1 distribution.  You can get the
correct version from .

Otherwise, here are step-by-step instructions for wien2wannier with SOC:
.


1.   Then I run *prepare_w2wdir WANN, but this command cannot
recognize Case.spaghettiup_ene and Case.Spaghettidn_ene file,
instead it shows “cannot find spaghetti_ene file”. I copy them
manually. Is something wrong?


I don't know.  Help me help you by showing the precise error message.


3.   After that, x lapw1 –up; x lapw1 –dn; x lapwso –up; x w2w
–so –up; xw2w –so –dn; and finally x wannier90 –so. Everything goes
smooth, I got reasonable band structure except that there is only one
Case_band.dat file. I tried run “x wannier90 –so  -up”, but it shows
“wannier90: -so should be used without –up/-dn”. Shall we expect two
band data file for two spin channels or somehow I am stupid?


This seems right.  Why do you expect separate bands for up and down?
With SOC, that is not a good quantum number anymore.


Also, I found a recipe for SOC case without spin polarization, but it
seems outdated. What should I do with this new version for the SOC
case without spin polarization?


Which one?  Why do you think it is outdated?


Elias



--

  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] wien2wannier with SOC in WIEN2k 16.1

[Fecher, Gerhard]

With SO each wave function will still have  a "up" and a ""down" part, but they 
are connected and cannot be separated,
(indeed not s(1/2,+1/2) or s(1/2,-1/2), at least in the 2 component version 
they are purely up or down, as well as all others with j=l+s, mj=+-j).
how does Wannier deal with the |j, m_j> or say better with the relativistic 
|kappa, mu> wave functions ?

Ciao
Gerhard

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


Dr. Gerhard H. Fecher
Institut of Inorganic and Analytical Chemistry
Johannes Gutenberg - University
55099 Mainz
and
Max Planck Institute for Chemical Physics of Solids
01187 Dresden

Von: Wien [wien-boun...@zeus.theochem.tuwien.ac.at] im Auftrag von Elias 
Assmann [elias.assm...@gmail.com]
Gesendet: Freitag, 16. Dezember 2016 06:56
An: A Mailing list for WIEN2k users
Betreff: Re: [Wien] wien2wannier with SOC in WIEN2k 16.1

On 12/15/2016 10:13 PM, Kefeng Wang wrote:
> Thanks a lot for your help and explanation. With the new script
> write_inwf_lapw, everything works fine now.

Great.

> ->For this one, the exact error message is  “recommended file
> ‘GaAs.spaghetti_ene’ not found (will continue)”. But it does not affect
> the calculation since spaghetti file is only for reference. I believe
> the command did not recognize the “spaghettiup_ene” and
> “spaghettidn_ene” file.

If I am not mistaken (certainly people on this list can correct me if I
am), with SOC you should have called spaghetti as ‘x spaghetti -so’,
which would have produced GaAs.spaghetti_ene.  In the presence of SOC, a
priori it does not make sense to talk of separate “↑” and “↓” states.

Elias


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier with SOC in WIEN2k 16.1

[Elias Assmann]

On 12/15/2016 10:13 PM, Kefeng Wang wrote:
> Thanks a lot for your help and explanation. With the new script
> write_inwf_lapw, everything works fine now.

Great.

> ->For this one, the exact error message is  “recommended file
> ‘GaAs.spaghetti_ene’ not found (will continue)”. But it does not affect
> the calculation since spaghetti file is only for reference. I believe
> the command did not recognize the “spaghettiup_ene” and
> “spaghettidn_ene” file.

If I am not mistaken (certainly people on this list can correct me if I
am), with SOC you should have called spaghetti as ‘x spaghetti -so’,
which would have produced GaAs.spaghetti_ene.  In the presence of SOC, a
priori it does not make sense to talk of separate “↑” and “↓” states.

Elias




signature.asc
Description: OpenPGP digital signature
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier with SOC in WIEN2k 16.1

[Kefeng Wang]

Dear Elias, 

 

Thanks a lot for your help and explanation. With the new script
write_inwf_lapw, everything works fine now.

 

> 1.   Then I run *prepare_w2wdir WANN, but this command cannot 

> recognize Case.spaghettiup_ene and Case.Spaghettidn_ene file,

> instead it shows "cannot find spaghetti_ene file". I copy them

> manually. Is something wrong?

 

I don't know.  Help me help you by showing the precise error message.

 

 

->For this one, the exact error message is  "recommended file
'GaAs.spaghetti_ene' not found (will continue)". But it does not affect the
calculation since spaghetti file is only for reference. I believe the
command did not recognize the "spaghettiup_ene" and "spaghettidn_ene" file.

 

 
> 3.   After that, x lapw1 -up; x lapw1 -dn; x lapwso -up; x w2w 
> -so -up; xw2w -so -dn; and finally x wannier90 -so. Everything goes 
> smooth, I got reasonable band structure except that there is only one
> Case_band.dat file. I tried run "x wannier90 -so  -up", but it shows
> "wannier90: -so should be used without -up/-dn". Shall we expect two
> band data file for two spin channels or somehow I am stupid?
 
This seems right.  Why do you expect separate bands for up and down?
With SOC, that is not a good quantum number anymore.
 
->I did not realize that. Thanks for pointing out. But if so, what happens
to the wannier function? After getting reasonable band structure, I tried to
plot wannier function. But It seems messed up.
I copied case.inwplot to case.inwplotup, and could ran "x wplot -up -so -wf
1" successfully ("x wplot -so -wf 1" did not work since there is ony *.vspup
file instead of *.vsp).
After that, if I try to run "wplot2xsf -up", it shows "wplot2xsf: Could not
open file `GaAs-WANN_centres.xyzup'.  Will proceed without shift." And if I
ran "wplot2xsf", it shows "No Wannier functions given and no `psink' files
found.  Nothing to do.".
 
Thanks again for your help.
 
Best
Kefeng
 

 

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier with SOC in WIEN2k 16.1

[Elias Assmann]

On 12/15/2016 06:01 PM, Kefeng Wang wrote:
> 2.   Then I run “init_w2w –up”, after k mesh (10 10 10) and find
> band, “write_inwf” shows “error: unrecognized arguments: -up” and
> init_w2w exit.  I also found the help file did not include [-up/dn]
> option for write_inwf command. So I manually run write_inwf and then
> copy case.inwf to case.inwfup and case.inwfdn.  Is this right?

PS: You did the right thing (provided you want to have the same trial
orbitals for both spins, of course).

Elias




signature.asc
Description: OpenPGP digital signature
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier with SOC in WIEN2k 16.1

[Elias Assmann]

Dear Kefeng Wang,

On 12/15/2016 06:01 PM, Kefeng Wang wrote:
> 2.   Then I run “init_w2w –up”, after k mesh (10 10 10) and find 
> band, “write_inwf” shows “error: unrecognized arguments: -up” and 
> init_w2w exit.  I also found the help file did not include [-up/dn] 
> option for write_inwf command. So I manually run write_inwf and then 
> copy case.inwf to case.inwfup and case.inwfdn.  Is this right?

Oops, this isn't right!  For some reason, the latest version of that
script did not make it into the 16.1 distribution.  You can get the
correct version from .

Otherwise, here are step-by-step instructions for wien2wannier with SOC:
.

> 1.   Then I run *prepare_w2wdir WANN, but this command cannot 
> recognize Case.spaghettiup_ene and Case.Spaghettidn_ene file,
> instead it shows “cannot find spaghetti_ene file”. I copy them
> manually. Is something wrong?

I don't know.  Help me help you by showing the precise error message.

> 3.   After that, x lapw1 –up; x lapw1 –dn; x lapwso –up; x w2w 
> –so –up; xw2w –so –dn; and finally x wannier90 –so. Everything goes 
> smooth, I got reasonable band structure except that there is only one
> Case_band.dat file. I tried run “x wannier90 –so  -up”, but it shows
> “wannier90: -so should be used without –up/-dn”. Shall we expect two
> band data file for two spin channels or somehow I am stupid?

This seems right.  Why do you expect separate bands for up and down?
With SOC, that is not a good quantum number anymore.

> Also, I found a recipe for SOC case without spin polarization, but it
> seems outdated. What should I do with this new version for the SOC 
> case without spin polarization?

Which one?  Why do you think it is outdated?


Elias

-- 
Elias Assmann

Wien2Wannier: maximally localized Wannier functions
  from linearized augmented plane waves

 http://wien2wannier.github.io/
  https://github.com/wien2wannier/wien2wannier/
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier with SOC in WIEN2k 16.1

[Kefeng Wang]

Dear developers and user community,

 

I am trying to run wien2wannier in the new WIEN2k 16.1 on a simple case GaAs
with spin polarization and spin orbital coupling. I met some problems.

 

My platform and other information:

WIEN2k 16.1, x86_64, linux, intel compiler ifort and mkl (2016.1)

 

After the spin polarized scf run with SOC 

*runsp_c_lapw -so -ec 0.0001

 

I got the band structure for both spin channel.  Following is the procedure
I run wien2annier and the problem I met:

 

1.   Then I run *prepare_w2wdir WANN, but this command cannot recognize
Case.spaghettiup_ene and Case.Spaghettidn_ene file, instead it shows "cannot
find spaghetti_ene file". I copy them manually. Is something wrong?

 

2.   Then I run "init_w2w -up", after k mesh (10 10 10) and find band,
"write_inwf" shows "error: unrecognized arguments: -up" and init_w2w exit.
I also found the help file did not include [-up/dn] option for write_inwf
command. So I manually run write_inwf and then copy case.inwf to case.inwfup
and case.inwfdn.  Is this right?

 

3.   After that, x lapw1 -up; x lapw1 -dn; x lapwso -up; x w2w -so -up;
xw2w -so -dn; and finally x wannier90 -so. Everything goes smooth, I got
reasonable band structure except that there is only one Case_band.dat file.
I tried run "x wannier90 -so  -up", but it shows "wannier90: -so should be
used without -up/-dn". Shall we expect two band data file for two spin
channels or somehow I am stupid?

 

 

Also, I found a recipe for SOC case without spin polarization, but it seems
outdated. What should I do with this new version for the SOC case without
spin polarization?

 

Thanks a lot for your help in advance.

 

Best

Kefeng Wang

 

 

 

 

 

 

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] [wien2wannier] unit of |w(r)|^2 in case.xsf and case.psink

[Elias Assmann]

Dear Wenhu Xu,

On 12/12/2016 08:10 PM, Xu Wenhu wrote:
> Then I want to check the normalization of the wannier function, so I
> integrate the grid and assume the unit of |w(r)|^2 to be 1/A^3, as
> the unit parameter set in my case.inwplot file. But the number turns
> to be ~450, too much larger than the expected 1.

The most important factor is likely the number of k-points.  You are
probably using wien2wannier 1.0 (as included in Wien2k 14.2), where an
erroneous factor of sqrt(#k-points) was included in the WFs (see
wien2wannier issue #2 at https://git.io/wf-norm).  To fix this issue,
best upgrade to the brand-new Wien2k 16.1
.

Then, depending on what you did, you might see a remaining factor of
Å/Bohr.  To get that right, keep in mind:

 * the unit of distance you selected in case.inwplot (in the template,
   Å is selected, contrary to Wien2k convention);

 * the proper “dV” factor (in the header of case_i.psink, the lengths
   of the plot axes are always given in Bohr, regardless of the units
   option -- I should probably change that).

> Please see below the case.inwplot I used. The length of grid axes is
> twice of the lattice vectors, and the number of mesh points is
> 100x100x100.

Normally, you do not need to worry about WF normalization.  If for
some reason you do, then you need to be very careful about the
integration.  In my experience from one project [1], you may need to
go to surprisingly large plot regions (2×2×2 may or may not suffice,
depending on your unit cell and the shape of your WFs).

But to do a convergence study in the r-mesh, you also have to make
sure your r-meshes are commensurate.  That is to say, if the r-points
are slightly shifted from one mesh to another, you will pick up
contributions from different regions of the (sharply peaked) WFs and
converge to a different integral.

In summary: If possible, it is best to treat the r-integral over the
WFs as an arbitrary constant.


Elias


[1] T. Ribic, E. Assmann, A. Tóth, and K. Held, Phys. Rev. B 90,
165105 (2014)



signature.asc
Description: OpenPGP digital signature
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier in WIEN2k_16

[Elias Assmann]

Dear wien2wannier users,

Please take note of the following *backward-incompatible changes* in
your favorite LAPW → MLWF interface:

 * The format of `case.inwplot' changed. Several outdated options have
   been removed, as has `write_inwplot'.  The new script
   `checkinwplot' converts old-style input files.  `x wplot' calls
   this script automatically, but to use a converted file, you must
   re-run `wplot':

  $ x wplot  # prints notification about converted file
  $ x wplot  # use converted file

 * In spin-polarized cases, `x w2w -up|-dn' now expects separate input
   files case.inwfup and case.inwfdn.  To re-run `w2w' in an existing
   directory, copy `case.inwf':

  $ cp -vi $(basename $PWD).inwf $(basename $PWD).inwfup \
&& mv -vi $(basename $PWD).inwf $(basename $PWD).inwfdn


This release incorporates a number of fixes and enhancements that have
accumulated since Wien2k 14.2.  For more details, see
https://git.io/w2w-NEWS-2.0 or the file $WIENROOT/SRC_w2w/NEWS.

Many of those changes were the direct result of users' feedback.  In
particular, I would like to thank Marc Höppner, Hong Jiang, Okan
Köksal, Gernot Kraberger, Laurence Marks, Oleg Rubel, Liang Si, Yundi
Quan, Ulrich Wedig, Jiaxu Yan, Jianxin Zhu, and Manuel Zingl for their
valuable comments on past versions.


Elias Assmann

-- 
Elias Assmann

Wien2Wannier: maximally localized Wannier functions
  from linearized augmented plane waves

 http://wien2wannier.github.io/
  https://github.com/wien2wannier/wien2wannier/



signature.asc
Description: OpenPGP digital signature
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] [wien2wannier] unit of |w(r)|^2 in case.xsf and case.psink

[Xu Wenhu]

Dear wien2wannier developers/users,

I am using wien2wannier to generate and plot the wannier orbitals of an Fe
compound. The wannier functions plotted in XCrySDen look reasonable and
have the correct shape/symmetry of d orbitals.

Then I want to check the normalization of the wannier function, so I
integrate the grid and assume the unit of |w(r)|^2 to be 1/A^3, as the unit
parameter set in my case.inwplot file. But the number turns to be ~450, too
much larger than the expected 1.

Please see below the case.inwplot I used. The length of grid axes is twice
of the lattice vectors, and the number of mesh points is 100x100x100.

I understand that the density of mesh points could have an effect on the
precision of numerical integration, but I would not expect such a huge
difference... Maybe I am wrong... For now I think more likely I am using a
wrong unit of the density. But I didn't find this information from the
wien2wannier userguide. I would appreciate it if you can give any advice or
suggestion on this issue. Thank you very much!

Best,
Wenhu Xu



3D ORTHO# mode O(RTHOGONAL)|N(ON-ORTHOGONAL)

-176 -126 -147 100  #x, y, z, divisor of orig

24 -126 -147 100  #x, y, z, divisor of x-end

-176 74 -147 100  #x, y, z, divisor of y-end

-176 -126 53 100  #x, y, z, divisor of z-end

100 100 100  0 0 0 # grid points and echo increments

NO  # DEP(HASING)|NO (POST-PROCESSING)

WAN ANG LARGE   # switch ANG|ATU|AU LARGE|SMALL

1  1# k-point, Wannier index


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier with SOC

[Elias Assmann]

Dear Jianxin,

Normally, wien2wannier usage questions should go to the Wien2k mailing
list for the possible benefit of other users.  I am copying to the list now.

On 09/16/2016 09:38 PM, Zhu, Jianxin wrote:
> x lapw1 –p
> x lapwso –p
> cp fccYb-W.fermi fccYb-W.fermiup
> cp fccYb-W.fermi fccYb-W.fermidn
> cp fccYb-W.vsp fccYb-W.vspup
> cp fccYb-W.vsp fccYb-W.vspdn
> x w2w –so –up –p
> x w2w –so –dn –p
> x wannier90 -so

This sounds like the “old” prescription -- copying vsp files should no
longer be necessary.  See also this page

(I just edited that to make it hopefully a little easier to understand).

> (I am using the
> wien2wannier coming with wien2k 14.2. I notice that you also post the
> program on the Github but I hope there is no severe change.)

In fact, that is the first thing I have to recommend: please get the
latest “master“ version from GitHub and try again.  There have been
important changes especially with regards to SOC.

If you have the same problems (“wiggly” Wannier bands) with the master
version and the procedure from the Wiki, please report back.


Elias






signature.asc
Description: OpenPGP digital signature
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier

[Elias Assmann]

Dear Subhasis,

Sorry for the delayed reply.

On 06/20/2016 11:51 AM, Subhasis Samanta wrote:
> I want to plot the wannier f orbitals for Yb doped inverse
> spinel ferrite. I have performed the spin polarized calculation. Can you
> please give some suggestions how to choose the origin of in this system?
> The case.woutup file is written below.
> 
>  Final State
>   WF centre and spread1  (  1.043108,  1.049474,  1.086064 )
>   WF centre and spread2  ( -0.999792, -1.018269, -1.070017 )
>   WF centre and spread3  (  0.995676,  1.038278,  1.047774 )
>   WF centre and spread4  ( -0.72, -0.32,  4.170776 )
>   WF centre and spread5  ( -1.038806,  3.101160,  3.106850 )
>   WF centre and spread6  ( -2.085413, -0.43,  2.085452 )
>   WF centre and spread7  (  0.000261,  0.14,  4.170773 )

Without knowing the lattice parameter, I cannot tell what these numbers
mean in fractional coordinates.  But anyway, notice that the centers
have both positive coordinates (which would be in the home unit cell)
and negative coordinates.

To choose one window to plot them all, make sure that all the centers
are contained in the window, plus some room around them to cover all the
relevant features of the WFs.  Of course, you are also free to use
different windows for the different functions.  This may be a good idea
if you have a large unit cell.

If you go on to transform your .psi{nk,arg} files to .xsf files, the
results may also depend on whether you have used the Wannier90 options
‘write_xyz’ and ‘translate_home_cell’.

Hope this helps,

Elias




signature.asc
Description: OpenPGP digital signature
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier

[Subhasis Samanta]

Dear Elias,

I want to plot the wannier f orbitals for Yb doped inverse
spinel ferrite. I have performed the spin polarized calculation. Can you
please give some suggestions how to choose the origin of in this system?
The case.woutup file is written below.

 Final State
  WF centre and spread1  (  1.043108,  1.049474,  1.086064 )
2.71201306
  WF centre and spread2  ( -0.999792, -1.018269, -1.070017 )
2.75082423
  WF centre and spread3  (  0.995676,  1.038278,  1.047774 )
2.72734541
  WF centre and spread4  ( -0.72, -0.32,  4.170776 )
4.32238676
  WF centre and spread5  ( -1.038806,  3.101160,  3.106850 )
2.69825573
  WF centre and spread6  ( -2.085413, -0.43,  2.085452 )
4.33566401
  WF centre and spread7  (  0.000261,  0.14,  4.170773 )
5.60081572
  Sum of centres and spreads ( -2.085038,  4.170581, 14.597674 )
 25.14730492

-- 
best wishes

Subhasis
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier interface

[Elias Assmann]

On 03/17/2015 09:58 AM, Kyohn Ahn wrote:

Maybe I can share my experiences.
I'm a user of v0.96.


Thank you for the report.  The problem is most likely related to 
‘xsfAll.sh’ looking for a string “_N” in the filename, where N is a 
number.  I believe this is already fixed in the new version, where 
‘wplot2xsf_lapw’ by default simply looks for all ‘*.psink‘ files, and 
does not care about the filenames except for the extensions.



Elias



The problem occurs when "_" exists in the filename.
More specifically, the trouble appears when I tried to get Wannier plots.
I think that the key is in either [prepare_plots.sh] or [xsfAll.sh].
(I could not find any problem with other operations, such as
write_w2win, write_win, w2w, ..., etc.)

My filename was, for example, [SrVO3_super.~~~].
Then the outputs (~xsf files, etc,) were strange.

I deleted "_" in the name of input files,
i.e., [SrVO3_super.~~~] → [SrVO3super.~~~].
Then the problem disappeared.

Have a nice day.!

- Kyohn


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier interface

[Kyohn Ahn]

Hi, Elias.

Maybe I can share my experiences.
I'm a user of v0.96.

The problem occurs when "_" exists in the filename.
More specifically, the trouble appears when I tried to get Wannier plots.
I think that the key is in either [prepare_plots.sh] or [xsfAll.sh].
(I could not find any problem with other operations, such as write_w2win,
write_win, w2w, ..., etc.)

My filename was, for example, [SrVO3_super.~~~].
Then the outputs (~xsf files, etc,) were strange.

I deleted "_" in the name of input files,
i.e., [SrVO3_super.~~~] → [SrVO3super.~~~].
Then the problem disappeared.

Have a nice day.!

- Kyohn
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier interface

[Elias Assmann]

On 03/12/2015 03:14 PM, wasim raja Mondal wrote:

  Going through the script, I found it is related with case.


Sorry, but I do not understand that.  Which script, precisely?  What is 
“case”, the Wien2k “case name”, or character case (big/little)?


Thanks,

Elias


PS: For the reference, I tried this with a directory named “W_test” 
using the current wien2wannier version; everything seems to work fine. 
If it works for you as well, we can put this issue to rest.  The 
following is straight from my terminal:


elias@hupuntu ~/W/SrVO3> prepare_w2wdir W_test
elias@hupuntu ~/W/SrVO3> cd W_test
elias@hupuntu ~/W/S/W_test> init_w2w -b -bands 21 23 -proj V:dt2g
next is kgen

  kgen -fbz ( 100 0 )   (13:51:57)

   1  symmetry operations without inversion
  NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
 length of reciprocal lattice vectors:   0.865   0.865   0.865   4.642 
  4.642   4.642

  Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
  64  k-points generated, ndiv=   4   4   4
KGEN ENDS
0.003u 0.000s 0:00.00 0.0%  0+0k 0+104io 0pf+0w

  /home/elias/wien2k/write_inwf -f W_test -bands 21 23 V:dt2g   (13:51:57)
  write_win (13:51:58)
  wannier90 -pp (13:51:58)

0.035u 0.024s 0:00.10 50.0% 0+0k 18728+72io 53pf+0w
elias@hupuntu ~/W/S/W_test> x lapw1; x w2w; x wannier90
 LAPW1 END
9.752u 0.179s 0:09.96 99.5% 0+0k 8192+21296io 30pf+0w
W2W END
3.507u 0.012s 0:03.52 99.7% 0+0k 0+416io 0pf+0w
0.065u 0.018s 0:00.09 77.7% 0+0k 4752+488io 24pf+0w
elias@hupuntu ~/W/S/W_test> write_inwplot W_test
 From wannier90 output W_test.wout(in Angstrom):
  WF centre and spread1  ( -1.921251, -1.921251, -1.921251 ) 
1.65655335
  WF centre and spread2  ( -1.921251, -1.921251, -1.921251 ) 
1.65655337
  WF centre and spread3  ( -1.921251, -1.921251, -1.921251 ) 
1.65655337
  Sum of centres and spreads ( -5.763753, -5.763753, -5.763753 ) 
4.96966010


Enter origin of spatial mesh in fractions of the  conv. unit vectors [n1 
n2 n3 ndiv]

-1 -1 -1 1
Enter endpoint on x-axis [n1 n2 n3 ndiv]
0 -1 -1 1
Enter endpoint on y-axis [n1 n2 n3 ndiv]
-1 0 -1 1
Enter endpoint on z-axis [n1 n2 n3 ndiv]
-1 -1 0 1
Enter number of mesh points, [nx ny nz]
10 10 10
elias@hupuntu ~/W/S/W_test> x wplot -wf 1; x wplot -wf 2; x wplot -wf 3
 written on 16Mar2015 at 13:52:22
0.810u 0.011s 0:00.82 100.0%0+0k 0+128io 0pf+0w
 written on 16Mar2015 at 13:52:22
0.802u 0.019s 0:00.82 98.7% 0+0k 0+128io 0pf+0w
 written on 16Mar2015 at 13:52:22
1.000u 0.019s 0:01.02 99.0% 0+0k 0+128io 0pf+0w
elias@hupuntu ~/W/S/W_test> wplot2xsf -v
 + wplot2xsf converting 3 Wannier functions +

Will print |w(r)|^2*sgn(Re w(r)).

Reading atoms info from `W_test.struct':
   atom 1 ``Sr'', Z: 38.0
   atom 2 ``V'', Z: 23.0
   atom 3 ``O'', Z: 8.0

Read offsets: [ 3.84250188  3.84250188  3.84250188]
  [ 3.84250188  3.84250188  3.84250188]
  [ 3.84250188  3.84250188  3.84250188]
from `W_test_centres.xyz' - `W_test.wout'.

Converting WF   #3: (W_test_3.psink, W_test_3.psiarg) -> W_test_3.xsf
   reading `W_test_3.psink'
   reading `W_test_3.psiarg'

Converting WF   #2: (W_test_2.psink, W_test_2.psiarg) -> W_test_2.xsf
   reading `W_test_2.psink'
   reading `W_test_2.psiarg'

Converting WF   #1: (W_test_1.psink, W_test_1.psiarg) -> W_test_1.xsf
   reading `W_test_1.psink'
   reading `W_test_1.psiarg'
elias@hupuntu ~/W/S/W_test> ls -l W_test*.{psink,psiarg,xsf}
-rw-rw-r-- 1 elias elias 16100 Mar 16 13:54 W_test_1.psiarg
-rw-rw-r-- 1 elias elias 16307 Mar 16 13:54 W_test_1.psink
-rw-rw-r-- 1 elias elias 16792 Mar 16 13:54 W_test_1.xsf
-rw-rw-r-- 1 elias elias 16100 Mar 16 13:54 W_test_2.psiarg
-rw-rw-r-- 1 elias elias 16307 Mar 16 13:54 W_test_2.psink
-rw-rw-r-- 1 elias elias 16792 Mar 16 13:54 W_test_2.xsf
-rw-rw-r-- 1 elias elias 16100 Mar 16 13:54 W_test_3.psiarg
-rw-rw-r-- 1 elias elias 16307 Mar 16 13:54 W_test_3.psink
-rw-rw-r-- 1 elias elias 16792 Mar 16 13:54 W_test_3.xsf
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier interface

[wasim raja Mondal]

Hi Ellias,
 Going through the script, I found it is related with case.

Regards
wasim

On Wed, Mar 11, 2015 at 5:20 PM, Elias Assmann 
wrote:

> Glad you could solve the problem.
>
> Could you clarify what happened?  If a bug like this exists in the current
> version of wplot2xsf, I would like to fix it.
>
>
> Elias
>
>
> On 03/11/2015 09:33 AM, wasim raja Mondal wrote:
>
>> Hi Kyhon,
>>  Just now I have solved the issue this way. Thanks a lot.
>>
>> Regards
>> wasim
>>
>> On Wed, Mar 11, 2015 at 2:01 PM, Kyohn Ahn > > wrote:
>>
>> Hi, Mondal.
>>
>> Could you try to delete "_" in the name of your files?
>> for example..,
>> [abc_qwe.vector] → [abcqwe.vector]
>>
>> I had a similar experience to you (for old version of w2wan).
>>
>> Have a nice day.!
>>
>> - Kyohn
>>
>> ___
>> Wien mailing list
>> Wien@zeus.theochem.tuwien.ac.at > tuwien.ac.at>
>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>> SEARCH the MAILING-LIST at:
>> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.
>> at/index.html
>>
>>
>>
>>
>> ___
>> Wien mailing list
>> Wien@zeus.theochem.tuwien.ac.at
>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>> SEARCH the MAILING-LIST at:  http://www.mail-archive.com/
>> wien@zeus.theochem.tuwien.ac.at/index.html
>>
>>
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:  http://www.mail-archive.com/
> wien@zeus.theochem.tuwien.ac.at/index.html
>
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] wien2wannier interface

[Elias Assmann]

Glad you could solve the problem.

Could you clarify what happened?  If a bug like this exists in the 
current version of wplot2xsf, I would like to fix it.



Elias


On 03/11/2015 09:33 AM, wasim raja Mondal wrote:

Hi Kyhon,
 Just now I have solved the issue this way. Thanks a lot.

Regards
wasim

On Wed, Mar 11, 2015 at 2:01 PM, Kyohn Ahn mailto:kyohn1...@gmail.com>> wrote:

Hi, Mondal.

Could you try to delete "_" in the name of your files?
for example..,
[abc_qwe.vector] → [abcqwe.vector]

I had a similar experience to you (for old version of w2wan).

Have a nice day.!

- Kyohn

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at 
http://zeus.theochem.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] wien2wannier interface

[wasim raja Mondal]

Hi Kyhon,
Just now I have solved the issue this way. Thanks a lot.

Regards
wasim

On Wed, Mar 11, 2015 at 2:01 PM, Kyohn Ahn  wrote:

> Hi, Mondal.
>
> Could you try to delete "_" in the name of your files?
> for example..,
> [abc_qwe.vector] → [abcqwe.vector]
>
> I had a similar experience to you (for old version of w2wan).
>
> Have a nice day.!
>
> - Kyohn
>
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> http://zeus.theochem.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] wien2wannier interface

[Kyohn Ahn]

Hi, Mondal.

Could you try to delete "_" in the name of your files?
for example..,
[abc_qwe.vector] → [abcqwe.vector]

I had a similar experience to you (for old version of w2wan).

Have a nice day.!

- Kyohn
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier interface

[wasim raja Mondal]

yes, but for newer version 1.0,  I am using wplot2xsf. I have attached two
file.


On Tue, Mar 10, 2015 at 5:05 PM, Elias Assmann 
wrote:

> On 03/10/2015 10:09 AM, wasim raja Mondal wrote:
>
>> *xsfAll.sh subdir_final*
>>
>
> If you are using wien2wannier 1.0 now, note that xsfAll.sh is no longer
> part of that.  The new version of wplot2xsf can convert all your plots in
> one step.
>
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:  http://www.mail-archive.com/
> wien@zeus.theochem.tuwien.ac.at/index.html
>


subdir_final.psiarg.tar.gz
Description: GNU Zip compressed data
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] wien2wannier interface

[Elias Assmann]

On 03/11/2015 07:24 AM, wasim raja Mondal wrote:

wplot2xsf.py subdir_final 2 >>o.out


I think wplot2xsf.py is still the pre-1.0 incarnation of wplot2xsf_lapw 
(as it is known in the new Wien2k distribution).  Two suggestions if you 
want to use the new version now:


* Remove the old wien2wannier from your $PATH.

*  Read the documentation.  Yes, even if you are an experienced pre-1.0 
user; a lot of things have changed.  You may get away with only looking 
at the file CHEATSHEET.



Is this o.out file is in xsf format which I have to see in xcrysden?


That does look like an xsf file (just look at another xsf and compare — 
there is also a good description of the format on the XCrySDen homepage 
http://lmgtfy.com/?q=xsf+format&l=1).



Elias


CC: Wien2k list for the archives.
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier interface

[Elias Assmann]

On 03/10/2015 10:09 AM, wasim raja Mondal wrote:

*xsfAll.sh subdir_final*


If you are using wien2wannier 1.0 now, note that xsfAll.sh is no longer part of 
that.  The new version of wplot2xsf can convert all your plots in one step.
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier interface

[wasim raja Mondal]

Dear Ellias,
 Thanks. yes that issue is solved. I am facing problem
which is described below


 My case is subdir_final.
 I am able to produce the following

   *write_wplotdef subdir_final*


*write_wplotin subdir_final*
   *prepare_plots.sh subdir_final*

   I have got the following files:

subdir_final_1.psiarg


subdir_final_1.psink


subdir_final_2.psiarg


subdir_final_2.psink


subdir_final_3.psiarg

   subdir_final_3.psink

 * xsfAll.sh subdir_final*
  I have got the following files:
  subdir_final_1.xsf.gz
  subdir_final_2.xsf.gz
  subdir_final_3.xsf.gz

  When I open these file in xcrysden, I am not finding anything.
 I gunzip one file

* gunzip subdir_final_1.xsf.gz*
 Inside this file it is showing

  [E] Could not find file subdir_final_final.psink





version1:
  To transform xsf file I use the command

   * wplot2xsf subdir_final*

   I am getting following error message

  Traceback (most recent call last):
  File "/home/wasim/wien2k_14_
installation/wplot2xsf", line 112, in 
args = parser.parse_args()
  File "/usr/lib/python2.7/argparse.py", line 1688, in parse_args
args, argv = self.parse_known_args(args, namespace)
  File "/usr/lib/python2.7/argparse.py", line 1720, in parse_known_args
namespace, args = self._parse_known_args(args, namespace)
  File "/usr/lib/python2.7/argparse.py", line 1929, in _parse_known_args
stop_index = consume_positionals(start_index)
  File "/usr/lib/python2.7/argparse.py", line 1885, in consume_positionals
take_action(action, args)
  File "/usr/lib/python2.7/argparse.py", line 1778, in take_action
argument_values = self._get_values(action, argument_strings)
  File "/usr/lib/python2.7/argparse.py", line 2218, in _get_values
value = [self._get_value(action, v) for v in arg_strings]
  File "/usr/lib/python2.7/argparse.py", line 2233, in _get_value
result = type_func(arg_string)
  File "/home/wasim/wien2k_14_installation/wplot2xsf", line 58, in
int_or_file
else:return open(x)
IOError: [Errno 2] No such file or directory: 'subdir_final'

On Tue, Mar 10, 2015 at 1:44 PM, Elias Assmann 
wrote:

> On 03/09/2015 04:52 PM, wasim raja Mondal wrote:
>
>> Hi Ellias,
>>Thanks. In 1.0 version when I am using write_inwf , it
>> tells to give
>> next proj. (3 to go; Ctrl-D if done)? V 2
>> didn't catch that: SITE and ORB must be given
>>
>
> This is a question that the ‘-h’ switch of write_inwf (or the wien2wanner
> user's guide) should really answer.  Please look at that again, and if it
> does not become clear, get back to me and tell me what you intend “V 2” to
> mean.
>
>
> Elias
>
>
>> what I have to give for SrVO3?
>>
>> Regards
>> wasim
>>
>> On Mon, Mar 9, 2015 at 8:06 PM, Elias Assmann > > wrote:
>>
>> Hi Wasim,
>>
>> Of course it is possible to produce plots (in psink+psiarg but also
>> xsf format) using pre-1.0 wien2wannier (the last version was 0.97).
>> If the problem is really the conversion to xsf, you should also be
>> able to use the wplot2xsf script from the new wien2wannier version
>> to do this conversion, regardless of where your psink/psiarg files
>> came from. (That script is one of the things that changed a lot)
>>
>> However, I would recommend upgrading to Wien2k 14.2.  This is of
>> course the standard advice, but I think it applies especially to
>> wien2wannier since so much has changed from 0.x to 1.0, and it is
>> probably more trouble than it would ever be worth to “backport”
>> wien2wannier 1.0 to Wien2k 13.
>>
>>  Elias
>>
>>
>>
>> On 03/09/2015 02:27 PM, wasim raja Mondal wrote:
>>
>> Dear Ellias,
>>I was using wien2k version 13 and
>> wien2wannier version
>> 0.96. With this version of wienwannier interface I am not able
>> to plot
>> wannier function. I am using SrVO3 example. I able to create
>>  case
>> m.psiarg and case.psink but not creat XSF file to visualize in
>> xcrsden.
>> So my question is following
>>
>>
>> 1. Is this bugs with version 0.96 of wien2wannier interface?
>>
>> 2. I have to install new veriosn (1.0)? If yes, then I have to
>> install
>> wienk_14? With wien2k_14 , wien2k_wannier interface will be
>> automatically install? Wannier90 also? or I have to install
>> separately
>> install wannier90?
>>
>>
>> 3. Is it possible to install this interface with wanneir13?
>>
>>
>> Regards
>> wasim
>>
>>
>> _
>> Wien mailing list
>> w...@zeus.theochem.tuwien.ac.__at
>> 

Re: [Wien] wien2wannier interface

[Elias Assmann]

On 03/09/2015 04:52 PM, wasim raja Mondal wrote:

Hi Ellias,
   Thanks. In 1.0 version when I am using write_inwf , it
tells to give
next proj. (3 to go; Ctrl-D if done)? V 2
didn't catch that: SITE and ORB must be given


This is a question that the ‘-h’ switch of write_inwf (or the 
wien2wanner user's guide) should really answer.  Please look at that 
again, and if it does not become clear, get back to me and tell me what 
you intend “V 2” to mean.



Elias



what I have to give for SrVO3?

Regards
wasim

On Mon, Mar 9, 2015 at 8:06 PM, Elias Assmann mailto:elias.assm...@gmail.com>> wrote:

Hi Wasim,

Of course it is possible to produce plots (in psink+psiarg but also
xsf format) using pre-1.0 wien2wannier (the last version was 0.97).
If the problem is really the conversion to xsf, you should also be
able to use the wplot2xsf script from the new wien2wannier version
to do this conversion, regardless of where your psink/psiarg files
came from. (That script is one of the things that changed a lot)

However, I would recommend upgrading to Wien2k 14.2.  This is of
course the standard advice, but I think it applies especially to
wien2wannier since so much has changed from 0.x to 1.0, and it is
probably more trouble than it would ever be worth to “backport”
wien2wannier 1.0 to Wien2k 13.

 Elias



On 03/09/2015 02:27 PM, wasim raja Mondal wrote:

Dear Ellias,
   I was using wien2k version 13 and
wien2wannier version
0.96. With this version of wienwannier interface I am not able
to plot
wannier function. I am using SrVO3 example. I able to create   case
m.psiarg and case.psink but not creat XSF file to visualize in
xcrsden.
So my question is following


1. Is this bugs with version 0.96 of wien2wannier interface?

2. I have to install new veriosn (1.0)? If yes, then I have to
install
wienk_14? With wien2k_14 , wien2k_wannier interface will be
automatically install? Wannier90 also? or I have to install
separately
install wannier90?


3. Is it possible to install this interface with wanneir13?


Regards
wasim


_
Wien mailing list
w...@zeus.theochem.tuwien.ac.__at

http://zeus.theochem.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
w...@zeus.theochem.tuwien.ac.__at

http://zeus.theochem.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] wien2wannier interface

[Elias Assmann]

On 03/09/2015 06:54 PM, wasim raja Mondal wrote:

Hi,
  In wein2k_14 version, wannier90 also compiled with wien2k?
At the stage of wanner90.x -pp
 I am getting this error
/home/wien2k_14_installation/wannier90: line 156: wannier90.x: command
not found
0.0u 0.0s 0:00.00 0.0% 0+0k 0+0io 0pf+0w

I have to separately download and install wannier90 and add the path in
bashrc?


On Mon, Mar 9, 2015 at 9:22 PM, wasim raja Mondal
mailto:wasimr.mon...@gmail.com>> wrote:

Hi Ellias,
   Thanks. In 1.0 version when I am using write_inwf ,
it tells to give
next proj. (3 to go; Ctrl-D if done)? V 2
didn't catch that: SITE and ORB must be given

what I have to give for SrVO3?

Regards
wasim

On Mon, Mar 9, 2015 at 8:06 PM, Elias Assmann
mailto:elias.assm...@gmail.com>> wrote:

Hi Wasim,

Of course it is possible to produce plots (in psink+psiarg but
also xsf format) using pre-1.0 wien2wannier (the last version
was 0.97).  If the problem is really the conversion to xsf, you
should also be able to use the wplot2xsf script from the new
wien2wannier version to do this conversion, regardless of where
your psink/psiarg files came from. (That script is one of the
things that changed a lot)

However, I would recommend upgrading to Wien2k 14.2.  This is of
course the standard advice, but I think it applies especially to
wien2wannier since so much has changed from 0.x to 1.0, and it
is probably more trouble than it would ever be worth to
“backport” wien2wannier 1.0 to Wien2k 13.

 Elias



On 03/09/2015 02:27 PM, wasim raja Mondal wrote:

Dear Ellias,
   I was using wien2k version 13 and
wien2wannier version
0.96. With this version of wienwannier interface I am not
able to plot
wannier function. I am using SrVO3 example. I able to
create   case
m.psiarg and case.psink but not creat XSF file to visualize
in xcrsden.
So my question is following


1. Is this bugs with version 0.96 of wien2wannier interface?

2. I have to install new veriosn (1.0)? If yes, then I have
to install
wienk_14? With wien2k_14 , wien2k_wannier interface will be
automatically install? Wannier90 also? or I have to install
separately
install wannier90?


3. Is it possible to install this interface with wanneir13?


Regards
wasim


_
Wien mailing list
w...@zeus.theochem.tuwien.ac.__at

http://zeus.theochem.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
w...@zeus.theochem.tuwien.ac.__at

http://zeus.theochem.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


Yes.
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier interface

[wasim raja Mondal]

Hi,
 In wein2k_14 version, wannier90 also compiled with wien2k?
At the stage of wanner90.x -pp
I am getting this error
/home/wien2k_14_installation/wannier90: line 156: wannier90.x: command not
found
0.0u 0.0s 0:00.00 0.0% 0+0k 0+0io 0pf+0w

I have to separately download and install wannier90 and add the path in
bashrc?


On Mon, Mar 9, 2015 at 9:22 PM, wasim raja Mondal 
wrote:

> Hi Ellias,
>   Thanks. In 1.0 version when I am using write_inwf , it tells
> to give
> next proj. (3 to go; Ctrl-D if done)? V 2
> didn't catch that: SITE and ORB must be given
>
> what I have to give for SrVO3?
>
> Regards
> wasim
>
> On Mon, Mar 9, 2015 at 8:06 PM, Elias Assmann 
> wrote:
>
>> Hi Wasim,
>>
>> Of course it is possible to produce plots (in psink+psiarg but also xsf
>> format) using pre-1.0 wien2wannier (the last version was 0.97).  If the
>> problem is really the conversion to xsf, you should also be able to use the
>> wplot2xsf script from the new wien2wannier version to do this conversion,
>> regardless of where your psink/psiarg files came from. (That script is one
>> of the things that changed a lot)
>>
>> However, I would recommend upgrading to Wien2k 14.2.  This is of course
>> the standard advice, but I think it applies especially to wien2wannier
>> since so much has changed from 0.x to 1.0, and it is probably more trouble
>> than it would ever be worth to “backport” wien2wannier 1.0 to Wien2k 13.
>>
>> Elias
>>
>>
>>
>> On 03/09/2015 02:27 PM, wasim raja Mondal wrote:
>>
>>> Dear Ellias,
>>>   I was using wien2k version 13 and wien2wannier version
>>> 0.96. With this version of wienwannier interface I am not able to plot
>>> wannier function. I am using SrVO3 example. I able to create   case
>>> m.psiarg and case.psink but not creat XSF file to visualize in xcrsden.
>>> So my question is following
>>>
>>>
>>> 1. Is this bugs with version 0.96 of wien2wannier interface?
>>>
>>> 2. I have to install new veriosn (1.0)? If yes, then I have to install
>>> wienk_14? With wien2k_14 , wien2k_wannier interface will be
>>> automatically install? Wannier90 also? or I have to install separately
>>> install wannier90?
>>>
>>>
>>> 3. Is it possible to install this interface with wanneir13?
>>>
>>>
>>> Regards
>>> wasim
>>>
>>>
>>> ___
>>> Wien mailing list
>>> Wien@zeus.theochem.tuwien.ac.at
>>> http://zeus.theochem.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] wien2wannier interface

[wasim raja Mondal]

Hi Ellias,
  Thanks. In 1.0 version when I am using write_inwf , it tells
to give
next proj. (3 to go; Ctrl-D if done)? V 2
didn't catch that: SITE and ORB must be given

what I have to give for SrVO3?

Regards
wasim

On Mon, Mar 9, 2015 at 8:06 PM, Elias Assmann 
wrote:

> Hi Wasim,
>
> Of course it is possible to produce plots (in psink+psiarg but also xsf
> format) using pre-1.0 wien2wannier (the last version was 0.97).  If the
> problem is really the conversion to xsf, you should also be able to use the
> wplot2xsf script from the new wien2wannier version to do this conversion,
> regardless of where your psink/psiarg files came from. (That script is one
> of the things that changed a lot)
>
> However, I would recommend upgrading to Wien2k 14.2.  This is of course
> the standard advice, but I think it applies especially to wien2wannier
> since so much has changed from 0.x to 1.0, and it is probably more trouble
> than it would ever be worth to “backport” wien2wannier 1.0 to Wien2k 13.
>
> Elias
>
>
>
> On 03/09/2015 02:27 PM, wasim raja Mondal wrote:
>
>> Dear Ellias,
>>   I was using wien2k version 13 and wien2wannier version
>> 0.96. With this version of wienwannier interface I am not able to plot
>> wannier function. I am using SrVO3 example. I able to create   case
>> m.psiarg and case.psink but not creat XSF file to visualize in xcrsden.
>> So my question is following
>>
>>
>> 1. Is this bugs with version 0.96 of wien2wannier interface?
>>
>> 2. I have to install new veriosn (1.0)? If yes, then I have to install
>> wienk_14? With wien2k_14 , wien2k_wannier interface will be
>> automatically install? Wannier90 also? or I have to install separately
>> install wannier90?
>>
>>
>> 3. Is it possible to install this interface with wanneir13?
>>
>>
>> Regards
>> wasim
>>
>>
>> ___
>> Wien mailing list
>> Wien@zeus.theochem.tuwien.ac.at
>> http://zeus.theochem.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] wien2wannier interface

[Elias Assmann]

Hi Wasim,

Of course it is possible to produce plots (in psink+psiarg but also xsf 
format) using pre-1.0 wien2wannier (the last version was 0.97).  If the 
problem is really the conversion to xsf, you should also be able to use 
the wplot2xsf script from the new wien2wannier version to do this 
conversion, regardless of where your psink/psiarg files came from. 
(That script is one of the things that changed a lot)


However, I would recommend upgrading to Wien2k 14.2.  This is of course 
the standard advice, but I think it applies especially to wien2wannier 
since so much has changed from 0.x to 1.0, and it is probably more 
trouble than it would ever be worth to “backport” wien2wannier 1.0 to 
Wien2k 13.


Elias


On 03/09/2015 02:27 PM, wasim raja Mondal wrote:

Dear Ellias,
  I was using wien2k version 13 and wien2wannier version
0.96. With this version of wienwannier interface I am not able to plot
wannier function. I am using SrVO3 example. I able to create   case
m.psiarg and case.psink but not creat XSF file to visualize in xcrsden.
So my question is following


1. Is this bugs with version 0.96 of wien2wannier interface?

2. I have to install new veriosn (1.0)? If yes, then I have to install
wienk_14? With wien2k_14 , wien2k_wannier interface will be
automatically install? Wannier90 also? or I have to install separately
install wannier90?


3. Is it possible to install this interface with wanneir13?


Regards
wasim


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier interface

[wasim raja Mondal]

Dear Ellias,
 I was using wien2k version 13 and wien2wannier version
0.96. With this version of wienwannier interface I am not able to plot
wannier function. I am using SrVO3 example. I able to create   case
m.psiarg and case.psink but not creat XSF file to visualize in xcrsden. So
my question is following


1. Is this bugs with version 0.96 of wien2wannier interface?

2. I have to install new veriosn (1.0)? If yes, then I have to install
wienk_14? With wien2k_14 , wien2k_wannier interface will be automatically
install? Wannier90 also? or I have to install separately install wannier90?


3. Is it possible to install this interface with wanneir13?


Regards
wasim
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier and gfortran for complex cases

[Elias Assmann]

Dear wien2wannier users,

The problem with w2wc and gfortran reported previously appeared because 
the makefile did not keep the real and complex module files separate.


I include a detailed explanation below, but the easy fix is to compile 
the complex version before the real one, i.e.


===

cd $WIENROOT/SRC_w2w
make clean
make complex
make real
cp -v w2w{,c} ..

cd ../SRC_wplot
make clean
make complex
make real
cp -v wplot{,c} ..

===

If this fix does not work for you, please report.

‘wplot’ should also be affected because it uses the same real/complex 
system.  The problem was (probably) introduced with the first 1.0-beta 
version.


Detailed explanation: The source files that do not differentiate between 
real and complex are compiled with


   gfortran -Ilib -c $OBJ.f -olib/$OBJ.o -J lib

the “complex” ones with

   gfortran -Ilib -c $OBJ.F -olibc/$OBJ.o -J libc -D_COMPLEX_

but the “real” ones are compiled with

   gfortran -c $OBJ.F -olibr/latgen.o -J lib

instead of -Jlibr.

This means that the ‘.mod’ files for the “real” modules end up in lib/ 
instead of libr/.  If they are already there, they are then used in 
compiling the complex executable, which is inconsistent.  Unfortunately, 
the compiler does not catch this problem.  As for ifort, it is the same 
in principle (just replace -J by -module), but it seems that ifort does 
not mind the inconsistent ‘.mod’s, or maybe it uses the correct ones by 
chance or design.


I tested all of this with gcc 4.8.2.


Elias


PS: Should this be considered a bug in gfortran?  I am wondering if I 
should submit a bug report.


--
Elias Assmann (TU Wien)

Wien2Wannier: maximally localized Wannier functions
  from linearized augmented plane waves

<http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/> 


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier for non-spinpolarized SOC cases

[Elias Assmann]

On 10/24/2014 05:56 PM, Zhu, Jianxin wrote:

Hi Elias,

In the earlier versions, I did

$x w2w -so
$cp CASE.eig CASE.eigup
$cp CASE.eig CASE.eigdn

Will it work still?


For w2w, -so only makes sense together with -up or -dn.



Jianxin



On 10/24/14 7:00 AM, "Elias Assmann"  wrote:


Dear wien2wannier users,

There is a minor problem in the Œwannier90¹ script for cases with
spin-orbit coupling but without spin polarization.  It looks for Œeigup¹
and Œeigdn¹ files which do not exist.  The easiest solution is simply to
copy the Œeig¹ file:

$ x w2w -so -up && x w2w -so -dn
$ cp CASE.eig CASE.eigup
$ cp CASE.eig CASE.eigdn
$ x wannier90 -so

--
Elias Assmann (TU Wien)

Wien2Wannier: maximally localized Wannier functions
   from linearized augmented plane waves

<http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-downloa
d/wien2wannier/>

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier for non-spinpolarized SOC cases

[Zhu, Jianxin]

Hi Elias, 

In the earlier versions, I did

$x w2w -so
$cp CASE.eig CASE.eigup
$cp CASE.eig CASE.eigdn

Will it work still?

Jianxin



On 10/24/14 7:00 AM, "Elias Assmann"  wrote:

>Dear wien2wannier users,
>
>There is a minor problem in the Œwannier90¹ script for cases with
>spin-orbit coupling but without spin polarization.  It looks for Œeigup¹
>and Œeigdn¹ files which do not exist.  The easiest solution is simply to
>copy the Œeig¹ file:
>
>$ x w2w -so -up && x w2w -so -dn
>$ cp CASE.eig CASE.eigup
>$ cp CASE.eig CASE.eigdn
>$ x wannier90 -so
>
>-- 
>Elias Assmann (TU Wien)
>
>Wien2Wannier: maximally localized Wannier functions
>   from linearized augmented plane waves
>
><http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-downloa
>d/wien2wannier/> 
>
>___
>Wien mailing list
>Wien@zeus.theochem.tuwien.ac.at
>http://zeus.theochem.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] wien2wannier for non-spinpolarized SOC cases

[Elias Assmann]

Dear wien2wannier users,

There is a minor problem in the ‘wannier90’ script for cases with 
spin-orbit coupling but without spin polarization.  It looks for ‘eigup’ 
and ‘eigdn’ files which do not exist.  The easiest solution is simply to 
copy the ‘eig’ file:


$ x w2w -so -up && x w2w -so -dn
$ cp CASE.eig CASE.eigup
$ cp CASE.eig CASE.eigdn
$ x wannier90 -so

--
Elias Assmann (TU Wien)

Wien2Wannier: maximally localized Wannier functions
  from linearized augmented plane waves

<http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/> 


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier and gfortran for complex cases

[Elias Assmann]

Dear wien2wannier users,

Unfortunately, there is a problem with wien2wannier (specifically, the 
‘w2wc’ program) for complex cases which appears when it is compiled with 
gfortran.


The symptoms are similar to the problem discussed in this thread 
<http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg09109.html>: 
‘x w2w’ finishes normally, but Wannier90 fails to converge with the 
generated ‘amn’ and ‘mmn’ files.


This problem appears at least with Wien2k_14.2 compiled with gfortran 
4.4 and 4.8 with ATLAS and OpenBLAS libraries.  Executables compiled 
with ifort and MKL have worked fine in my tests.


Currently I do not know what causes this problem and would appreciate 
any feedback.  I apologize for the inconvenience to gfortran users and 
will post back here if there are any new developments.


--
Elias Assmann (TU Wien)

Wien2Wannier: maximally localized Wannier functions
  from linearized augmented plane waves

<http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/> 


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier with wien2k.14.1

[Elias Assmann]

On 09/24/2014 03:32 AM, Zhu, Jianxin wrote:

Sorry for disturbing you this afternoon.


It is for me to apologize for inflicting this problem on you (and on 
other wien2wannier users, I fear) through my choice to use UTF-8 
characters in some wien2wannier messages.  I chose to use those 
characters because they were nice for formatting the names of orbitals 
for the initial projections in `write_inwf' (like Peter's example `z²'), 
and because I thought that support for them should be pretty much 
universal on any modern system.


Of course I was aware that there might be a few people it would fail 
for, but not that it would fail so badly.  (You showed that not only are 
the Unicode characters displayed wrongly, but ASCII character between 
them are deleted: "`-emin X -emax Y'" [substituting apostrophes for the 
offending Unicode quote marks] becomes "â"!)


I will shortly provide an ASCIIized version of wien2wannier, and avoid 
non-ASCII characters in future versions.  (Of course, the Right Thing 
would be to make the programs aware of the locale settings and adjust 
the messages accordingly, as many tools do these days ...)



After a few more times of struggling, I pinned down the root cause to be
with the setting of xterm under x11.
With the correction, the problem disappears. Of course, we still need to

setenv LANG en_US.UTF-8


on the linux cluster if the UTF-8 is not set as default, if we remotely
log onto it.


On my machine, experimentation shows that it is a question of the locale 
settings in effect when the terminal is started.  I.e.,


$ unset LANG
$ xterm

gives me a terminal that displays the characters wrongly, but just 
changing it in the current shell


[old terminal] $ xterm
[new xterm]$ unset LANG

does not change the behavior.

Also, xterm showed the problem while my standard terminal application 
does not.



Elias

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier with wien2k.14.1

[Peter Blaha]

It is a matter of taste how one wants to do it.

The UTF-8 character set has nice features with special characters, for 
instance displays z^2 really with a superscript "2".


On the other hand, when using   "putty"  from home, I had the same 
problem as you and unreadable characters appear as output and sometimes 
the messages are completely scrambled.


It should not affect basic functionality (except when you cannot read 
some help-instruction).


On 09/24/2014 03:32 AM, Zhu, Jianxin wrote:

All,

Sorry for disturbing you this afternoon.

After a few more times of struggling, I pinned down the root cause to be
with the setting of xterm under x11.
With the correction, the problem disappears. Of course, we still need to

setenv LANG en_US.UTF-8


on the linux cluster if the UTF-8 is not set as default, if we remotely
log onto it.

Cheers,

Jianxin




On 9/23/14 12:22 PM, "Zhu, Jianxin"  wrote:


Hi Elias,

As you suggested earlier, I pulled this issue to the mailing list.

After I downloaded wien2k.14.1 integrated with wien2wannier, even before
compilation/installation, I noticed many strange characters displayed
inside the wien2wannier90 script files, for example, near the end of
init_w2w_lapw

OPTIONS:
-b  ->  batch mode (do not ask questions)
-numk   ->  number of k-points (default: 100; can also use â~@~\Nx Ny
Nzâ~@~])
-emin,-emax ->  select bands by energy (needs â~@~Xoutput1â~@~Y file;
careful!)
-all X Y->  synonym for â~@~X-emin X -emax Yâ~@~Y
-bands I J  ->  select bands directly (more robust)
-proj   ->  specification of initial projections (â~@~\Amnâ~@~])
-w90->  Wannier90 options to set

â~@~XOPTIONSâ~@~Y  are only  operative  in batch  mode,  except
â~@~X-w90â~@~Y,  which
accepts as arguments  key-value pairs to be put  into â~@~Xcase.winâ~@~Y.
The
sp/so  switches  are  usually  unnecessary  (detected  automatically).
theend

exit 0



I did some file type check (with the suggestion of Matt Jones at Univ.
Buffalo) ---

/wien2k.14.1] jxzhu% file --mime init_lapw
init_lapw: text/x-shellscript; charset=us-ascii


/wien2k.14.1] jxzhu% file --mime init_w2w_lapw
init_w2w_lapw: text/x-shellscript; charset=utf-8



It looks the charset used for wien2wannier90 scripts is different than the
rest of wien2k scripts.

As such, I manually set

setenv LANG en_US.UTF-8

in the login shell script file. Then I see the following ---

OPTIONS:
-b  ->  batch mode (do not ask questions)
-numk   ->  number of k-points (default: 100; can also use âNx Ny Nzâ
file; careful!)
-all X Y->  synonym for â
-bands I J  ->  select bands directly (more robust)
-proj   ->  specification of initial projections (âAmnâ  are only
operative  in batch  mode,  except â,  which
accepts as arguments  key-value pairs to be put  into â.  The
sp/so  switches  are  usually  unnecessary  (detected  automatically).
theend

exit 0



With the manual setting of UTF-8, I still see characters like hat{a} and
the item like -w90 is missing in the display.
As such, I am not sure what I get in whatever way is correct.


I tested this issue on my Mac OSX machine, but also saw the strange
characters on my linux cluster.


Kevin, I appreciate if you can help me check this on your mac osx machine.


Cheers,

Jianxin




On 7/1/14 5:34 AM, "Elias Assmann"  wrote:


Dear wien2wannier Users!

A new version of the package is available at
<http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-downlo
a
d/wien2wannier/>.

This is a minor update that fixes a few bugs, including one in
Œwplot2xsf¹ that caused it to crash.

--
Elias Assmann (TU Wien)

Wien2Wannier: maximally localized Wannier functions
   from linearized augmented plane waves

<http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-downlo
a
d/wien2wannier/>

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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



--

  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

Re: [Wien] wien2wannier with wien2k.14.1

[Zhu, Jianxin]

All, 

Sorry for disturbing you this afternoon.

After a few more times of struggling, I pinned down the root cause to be
with the setting of xterm under x11.
With the correction, the problem disappears. Of course, we still need to

setenv LANG en_US.UTF-8


on the linux cluster if the UTF-8 is not set as default, if we remotely
log onto it.

Cheers, 

Jianxin 




On 9/23/14 12:22 PM, "Zhu, Jianxin"  wrote:

>Hi Elias, 
>
>As you suggested earlier, I pulled this issue to the mailing list.
>
>After I downloaded wien2k.14.1 integrated with wien2wannier, even before
>compilation/installation, I noticed many strange characters displayed
>inside the wien2wannier90 script files, for example, near the end of
>init_w2w_lapw
>
>OPTIONS:
>-b  ->  batch mode (do not ask questions)
>-numk   ->  number of k-points (default: 100; can also use â~@~\Nx Ny
>Nzâ~@~])
>-emin,-emax ->  select bands by energy (needs â~@~Xoutput1â~@~Y file;
>careful!)
>-all X Y->  synonym for â~@~X-emin X -emax Yâ~@~Y
>-bands I J  ->  select bands directly (more robust)
>-proj   ->  specification of initial projections (â~@~\Amnâ~@~])
>-w90->  Wannier90 options to set
>
>â~@~XOPTIONSâ~@~Y  are only  operative  in batch  mode,  except
>â~@~X-w90â~@~Y,  which
>accepts as arguments  key-value pairs to be put  into â~@~Xcase.winâ~@~Y.
>The
>sp/so  switches  are  usually  unnecessary  (detected  automatically).
>theend
>
>exit 0
>
>
>
>I did some file type check (with the suggestion of Matt Jones at Univ.
>Buffalo) ---
>
>/wien2k.14.1] jxzhu% file --mime init_lapw
>init_lapw: text/x-shellscript; charset=us-ascii
>
>
>/wien2k.14.1] jxzhu% file --mime init_w2w_lapw
>init_w2w_lapw: text/x-shellscript; charset=utf-8
>
>
>
>It looks the charset used for wien2wannier90 scripts is different than the
>rest of wien2k scripts.
>
>As such, I manually set
>
>setenv LANG en_US.UTF-8
>
>in the login shell script file. Then I see the following ---
>
>OPTIONS:
>-b  ->  batch mode (do not ask questions)
>-numk   ->  number of k-points (default: 100; can also use âNx Ny Nzâ
>file; careful!)
>-all X Y->  synonym for â
>-bands I J  ->  select bands directly (more robust)
>-proj   ->  specification of initial projections (âAmnâ  are only
>operative  in batch  mode,  except â,  which
>accepts as arguments  key-value pairs to be put  into â.  The
>sp/so  switches  are  usually  unnecessary  (detected  automatically).
>theend
>
>exit 0
>
>
>
>With the manual setting of UTF-8, I still see characters like hat{a} and
>the item like -w90 is missing in the display.
>As such, I am not sure what I get in whatever way is correct.
>
>
>I tested this issue on my Mac OSX machine, but also saw the strange
>characters on my linux cluster.
>
>
>Kevin, I appreciate if you can help me check this on your mac osx machine.
>
>
>Cheers,
>
>Jianxin
>
>
>
>
>On 7/1/14 5:34 AM, "Elias Assmann"  wrote:
>
>>Dear wien2wannier Users!
>>
>>A new version of the package is available at
>><http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-downlo
>>a
>>d/wien2wannier/>.
>>
>>This is a minor update that fixes a few bugs, including one in
>>Œwplot2xsf¹ that caused it to crash.
>>
>>-- 
>>Elias Assmann (TU Wien)
>>
>>Wien2Wannier: maximally localized Wannier functions
>>   from linearized augmented plane waves
>>
>><http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-downlo
>>a
>>d/wien2wannier/> 
>>
>>___
>>Wien mailing list
>>Wien@zeus.theochem.tuwien.ac.at
>>http://zeus.theochem.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] wien2wannier with wien2k.14.1

[Zhu, Jianxin]

Hi Elias, 

As you suggested earlier, I pulled this issue to the mailing list.

After I downloaded wien2k.14.1 integrated with wien2wannier, even before
compilation/installation, I noticed many strange characters displayed
inside the wien2wannier90 script files, for example, near the end of
init_w2w_lapw

OPTIONS:
-b  ->  batch mode (do not ask questions)
-numk   ->  number of k-points (default: 100; can also use â~@~\Nx Ny
Nzâ~@~])
-emin,-emax ->  select bands by energy (needs â~@~Xoutput1â~@~Y file;
careful!)
-all X Y->  synonym for â~@~X-emin X -emax Yâ~@~Y
-bands I J  ->  select bands directly (more robust)
-proj   ->  specification of initial projections (â~@~\Amnâ~@~])
-w90->  Wannier90 options to set

â~@~XOPTIONSâ~@~Y  are only  operative  in batch  mode,  except
â~@~X-w90â~@~Y,  which
accepts as arguments  key-value pairs to be put  into â~@~Xcase.winâ~@~Y.
The
sp/so  switches  are  usually  unnecessary  (detected  automatically).
theend

exit 0



I did some file type check (with the suggestion of Matt Jones at Univ.
Buffalo) ---

/wien2k.14.1] jxzhu% file --mime init_lapw
init_lapw: text/x-shellscript; charset=us-ascii


/wien2k.14.1] jxzhu% file --mime init_w2w_lapw
init_w2w_lapw: text/x-shellscript; charset=utf-8



It looks the charset used for wien2wannier90 scripts is different than the
rest of wien2k scripts.

As such, I manually set

setenv LANG en_US.UTF-8

in the login shell script file. Then I see the following ---

OPTIONS:
-b  ->  batch mode (do not ask questions)
-numk   ->  number of k-points (default: 100; can also use âNx Ny Nzâ
file; careful!)
-all X Y->  synonym for â
-bands I J  ->  select bands directly (more robust)
-proj   ->  specification of initial projections (âAmnâ  are only
operative  in batch  mode,  except â,  which
accepts as arguments  key-value pairs to be put  into â.  The
sp/so  switches  are  usually  unnecessary  (detected  automatically).
theend

exit 0



With the manual setting of UTF-8, I still see characters like hat{a} and
the item like -w90 is missing in the display.
As such, I am not sure what I get in whatever way is correct.


I tested this issue on my Mac OSX machine, but also saw the strange
characters on my linux cluster.


Kevin, I appreciate if you can help me check this on your mac osx machine.


Cheers,

Jianxin


#
Jian-Xin Zhu, Ph.D
Theoretical Division, MS B262
Los Alamos National Laboratory
Los Alamos, New Mexico 87545
Phone: (505) 667 2363 (T-4);
(505) 667 6602 (CINT)
Fax: (505) 665 4063
Email (main): jx...@lanl.gov
Email (backup): physjx...@gmail.com
URL: http://theory.lanl.gov
#




On 7/1/14 5:34 AM, "Elias Assmann"  wrote:

>Dear wien2wannier Users!
>
>A new version of the package is available at
><http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-downloa
>d/wien2wannier/>.
>
>This is a minor update that fixes a few bugs, including one in
>Œwplot2xsf¹ that caused it to crash.
>
>-- 
>Elias Assmann (TU Wien)
>
>Wien2Wannier: maximally localized Wannier functions
>   from linearized augmented plane waves
>
><http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-downloa
>d/wien2wannier/> 
>
>___
>Wien mailing list
>Wien@zeus.theochem.tuwien.ac.at
>http://zeus.theochem.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] wien2wannier version 1.0-β4

[Elias Assmann]

Dear wien2wannier Users!

A new version of the package is available at 
<http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/>.


This is a minor update that fixes a few bugs, including one in 
‘wplot2xsf’ that caused it to crash.


--
Elias Assmann (TU Wien)

Wien2Wannier: maximally localized Wannier functions
  from linearized augmented plane waves

<http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/> 


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier 1.0-β3

[Elias Assmann]

Dear Wien2k Users,

A new version of wien2wannier (1.0-β3) is available for download at 
<http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/>.


It includes an important fix to ‘convham’, which produced wrong results 
in the last version.  If you use this program, you should definitely 
upgrade.


--
Elias Assmann (TU Wien)

Wien2Wannier: maximally localized Wannier functions
  from linearized augmented plane waves

<http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/> 


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] [wien2wannier] wplot error

[wasim raja Mondal]

Dear Elias,
 I also same problem in the older version. It was related
also in the number of wannier function.

Regards
wasim


On Mon, May 12, 2014 at 2:07 PM, Elias Assmann wrote:

> On 05/09/2014 10:27 PM, Kefeng Wang wrote:
>
>> Dear All,
>>
>> I tried to follow the SrVO3 example in wien2wannier 1.0 beta2 and
>> Wannier90 1.2. Everything went well until the command ‘x wplot –wf –m”
>> failed. The error message  is “forrtl: severe (59): list-directed I/O
>> syntax error, unit -5, file Internal List-Directed Read”. Before that, I
>> compared the bandstructures and it is good. Could anybody help me out?
>>
>
> Sorry, I see I was a bit too fast there -- it is an “internal read”, i.e.
> it is trying to read from a string.  My guess is that it is the ‘-m’ in
> your command line.  The option is ‘-wf M’ where M is a number; ‘-m’ is not
> a valid option.
>
>
> Elias
>
>
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> http://zeus.theochem.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] [wien2wannier] wplot error

[Elias Assmann]

On 05/09/2014 10:27 PM, Kefeng Wang wrote:

Dear All,

I tried to follow the SrVO3 example in wien2wannier 1.0 beta2 and
Wannier90 1.2. Everything went well until the command ‘x wplot –wf –m”
failed. The error message  is “forrtl: severe (59): list-directed I/O
syntax error, unit -5, file Internal List-Directed Read”. Before that, I
compared the bandstructures and it is good. Could anybody help me out?


Sorry, I see I was a bit too fast there -- it is an “internal read”, 
i.e. it is trying to read from a string.  My guess is that it is the 
‘-m’ in your command line.  The option is ‘-wf M’ where M is a number; 
‘-m’ is not a valid option.


Elias


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] [wien2wannier] wplot error

[Elias Assmann]

Dear Kefeng,

On 05/09/2014 10:27 PM, Kefeng Wang wrote:

I tried to follow the SrVO3 example in wien2wannier 1.0 beta2 and
Wannier90 1.2. Everything went well until the command ‘x wplot –wf –m”
failed. The error message  is “forrtl: severe (59): list-directed I/O
syntax error, unit -5, file Internal List-Directed Read”. Before that, I
compared the bandstructures and it is good. Could anybody help me out?


We are going to need more info.  That error message only says some read 
failed.  On which file, for starters?


Elias


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] [wien2wannier] wplot error

[Kefeng Wang]

Dear All,

 

I tried to follow the SrVO3 example in wien2wannier 1.0 beta2 and Wannier90
1.2. Everything went well until the command 'x wplot -wf -m" failed. The
error message  is "forrtl: severe (59): list-directed I/O syntax error, unit
-5, file Internal List-Directed Read". Before that, I compared the
bandstructures and it is good. Could anybody help me out?

 

Thanks in advance

 

Kefeng

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier release 1.0-beta2

[Elias Assmann]

Dear wien2wannier users,

A minor update of the package is available at

http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/

It fixes a couple of bugs that have turned up in the 1.0-beta release.

--
Elias Assmann (TU Wien)

Wien2Wannier: maximally localized Wannier functions
  from linearized augmented plane waves

<http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/>

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier release 1.0-beta

[Oleg Rubel]

A new version of BerryPI (v1.2) is released at
https://github.com/spichardo/BerryPI/releases
in order to keep up with the changes in wien2wannier

As always, reports are very welcome.

Oleg Rubel


On Thu, Feb 13, 2014 at 10:56 AM, Elias Assmann 
wrote:
>
> Dear Wien2k users,
>
> A new version of wien2wannier (1.0-beta), the interface from Wien2k to
Wannier90, is available at
>
>
>
http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/
>
> The new version is tagged as a "beta" release until it has been more
thoroughly tested.  Nonetheless, it is fully functional and you are
encouraged to use this version.  Bug reports to <
wien2wann...@ifp.tuwien.ac.at> will be appreciated.
>
> New features include:
>
>  * more flexible and powerful specification of initial projections (e.g.,
arbitrary rotations are supported)
>
>  * fix handling of k-points for various lattice types
>
>  * wien2wannier may now be used under the terms of the GNU GPL
>
> Please see the file 'NEWS' in the distribution for more information.
>
> --
> Elias Assmann (TU Wien)
>
> Wien2Wannier: maximally localized Wannier functions
>   from linearized augmented plane waves
>
> <
http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/
>
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> http://zeus.theochem.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] wien2wannier release 1.0-beta

[Elias Assmann]

Dear Wien2k users,

A new version of wien2wannier (1.0-beta), the interface from Wien2k to 
Wannier90, is available at



http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/

The new version is tagged as a “beta” release until it has been more 
thoroughly tested.  Nonetheless, it is fully functional and you are 
encouraged to use this version.  Bug reports to 
 will be appreciated.


New features include:

 * more flexible and powerful specification of initial projections 
(e.g., arbitrary rotations are supported)


 * fix handling of k-points for various lattice types

 * wien2wannier may now be used under the terms of the GNU GPL

Please see the file ‘NEWS’ in the distribution for more information.

--
Elias Assmann (TU Wien)

Wien2Wannier: maximally localized Wannier functions
  from linearized augmented plane waves

<http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/> 


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] Wien2Wannier with spin-orbit coupling

[Kyohn Ahn]

Dear Elias,

I'm really sorry for my late response,
and appreciate your fruitful report (about ifort+ATLAS).

My problem was solved:
It was just the problem of reading "lapw2 -c" in dayfile.
(and also I'm thankful for the discussion,
http://zeus.theochem.tuwien.ac.at/pipermail/wien/2013-August/019639.html)



==



At present, my trouble is that "how to treat the real and imaginary part of
Wannier functions (FWs)".
(especially, in case of including spin-orbit coupling)

I think that either or both of the up and down WFs can (should?) be complex.
(For example, Fig. 4. in Comp. Phys. Commun. 181, 1888 (2010))

Q) Could anyone give me some comments for treating the real/imaginary of
WFs?
Par exemple,
[1] Do I need to touch up the source code to separate them in outputs?
[2] or I have to do special handle the basis WF orbits in w2win files?
[3] or they have already been separately in outputs? (in each xsf files)

If [3] is the right way, I have another question.
Q) There should be twelve xsf files for SrVO3 (incl SO): Does which file
have which part of real/imaginary?
case_1.xsfup ┐
case_2.xsfup ┤ⓐ
case_3.xsfup ┘
case_4.xsfup ┐
case_5.xsfup ┤ⓑ
case_6.xsfup ┘
case_1.xsfdn ┐
case_2.xsfdn ┤ⓒ
case_3.xsfdn ┘
case_4.xsfdn ┐
case_5.xsfdn ┤ⓓ
case_6.xsfdn ┘



==



Here are my additional questions:
To reproduce the example of Sr2IrO4 in Comp. Phys. Commun. 181, 1888 (2010),
I tried to construct the WFs by eq. 14.

Q) Could you check whether the below information is right..?
= .w2winup =
BOTH
  73  74 # min band Nmin, max band Nmax
  3  2   # LJMAX max in exp(ibr) expansion, #Wannier functions
1 # d-xz + id-yz orbital, i.e., Y(2,1)
 2 2  1   1.   0.   # index of atom, L, M, coefficient
(complex)
2 # d-xy orbital, i.e., Y(2,-2) - Y(2,2)
 2 2 -2   0.   0.70710677   # index of atom, L, M, coefficient
(complex)
 2 2  2   0.  -0.70710677   # index of atom, L, M, coefficient
(complex)
=.w2windn =
BOTH
  73  74 # min band Nmin, max band Nmax
  3  2   # LJMAX max in exp(ibr) expansion, #Wannier functions
2 #d-xy orbital, i.e., Y(2,-2) - Y(2,2)
 2 2 -2   0.   0.70710677   # index of atom, L, M, coefficient
(complex)
 2 2  2   0.  -0.70710677   # index of atom, L, M, coefficient
(complex)
1 #d-xz - id-yz orbital, i.e., Y(2,-1)
 2 2 -1   1.   0.   # index of atom, L, M, coefficient
(complex)

If they are right, I will get the four xsf files.
case_1.xsfup.gz
case_2.xsfup.gz
case_1.xsfdn.gz
caxe_2.xsfdn.gz

Q) Does which file have which part of real/imaginary?



Thank you for giving me your time and consideration.

With best regards

Kyohn
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] Wien2Wannier with spin-orbit coupling

[Elias Assmann]

Dear Kyohn,

I finally got a chance to look into your problem, and I can reproduce 
the behavior you describe. Without SO everything worked fine.  With SO, 
the projection clearly went awry: The spreads were too large (~16 Ų vs 
~4 Ų in the non-SO case), the centers were off, and the Wannier 
bandstructure was bad also.  Is that what you saw?


I then tried the example on a different machine, because I had a 
different Wien2k version there -- I thought maybe something about SO had 
changed and broken the w2w procedure.  There, I really did get good 
results, but it turns out that the key difference was the compiler and 
LAPACK library used for wannier90.


The problem happened when I used ‘ifort’ together with the ATLAS 
library.  I tried various combinations of ifort/gfortran and 
MKL/ATLAS/netlib, but only ifort+ATLAS seems to have this problem.


Can you please try if a similar strategy works in your case?


Elias
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] WIEN2WANNIER: real/compex case

[Peter Blaha]

Dear Wien2Wannier users!

A new version (0.97) of w2w is available at

   http://www.wien2k.at/reg_user/unsupported/wien2wannier/

This is a minor update, which includes a fix for the real/complex 
detection bug in `w2w´ kindly reported by Oleg Rubel, as well as a 
version of `update_FermiEnergy.sh´ that works with recent `scf´ files.



Elias Assmann


On 07/31/2013 04:56 PM, Oleg Rubel wrote:

Dear Users of Wien2k and WIEN2WANNIER:

We came across a minor compatibility issue between WIEN2WANNIER and a
newer version Wien2k (v12 and above).

Apparently, the complex calculation is not resolved properly by w2w. The
following line in 'w2w' script searches for a pattern "lapw1  -c" in a
dayfile

tmp="$(grep "lapw1  -c" "$SEEDNAME.dayfile")"

However, the number of spaces between 'lapw1' and '-c' has changes in
wien2k while going from v11 to v12 and higher. As a result, the complex
calculation is not identified properly.

I suggest to change the line to the following (note the space between 1
and *)

tmp="$(grep "lapw1 *-c" "$SEEDNAME.dayfile")"

This code is compatible with any number of spaces.

The modification is absolutely critical for proper calculation of
polarization with BerryPi.

Best regards
Oleg



___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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.atWWW: 
http://info.tuwien.ac.at/theochem/

--
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] WIEN2WANNIER: real/compex case

[Oleg Rubel]

Dear Users of Wien2k and WIEN2WANNIER:

We came across a minor compatibility issue between WIEN2WANNIER and a newer
version Wien2k (v12 and above).

Apparently, the complex calculation is not resolved properly by w2w. The
following line in 'w2w' script searches for a pattern "lapw1  -c" in a
dayfile

tmp="$(grep "lapw1  -c" "$SEEDNAME.dayfile")"

However, the number of spaces between 'lapw1' and '-c' has changes in
wien2k while going from v11 to v12 and higher. As a result, the complex
calculation is not identified properly.

I suggest to change the line to the following (note the space between 1 and
*)

tmp="$(grep "lapw1 *-c" "$SEEDNAME.dayfile")"

This code is compatible with any number of spaces.

The modification is absolutely critical for proper calculation of
polarization with BerryPi.

Best regards
Oleg
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] Wien2Wannier with spin-orbit coupling

[Kyohn Ahn]

Dear WIEN2k users,

Can I ask you some questions about Wien2Wannier calculation with spin-orbit
coupling (SO)?

I have checked the examples in /w2w_install_dir/templates/, then I found
that
the Wannier function plots for "spin-polarized case (testcase2)" and
"spin-polarized with SO case (testcase3)" are quite different.

There are two questions I have:

1. The meaning of SO in Wannier function plots:
The SO effects are not essential to SrVO3 in examples.
However, the two plots (testcase2 and testcase3) look very different.
So I wonder how SO effects make the differences.

2. The meaning of up/down in spin-polarized with SO case:
The data of spin-up and down should be mixed during w2w calculations,
but the xsf files are written respectively for up and down.

So I think that in spin-polarized with SO case (testcase3), for example
SrVO3_1.xsfup.gz is for real-part and SrVO3_1.xsfdn.gz is for imaginary
part ...
Is this true?

Thank you for reading this mail.
Any response in this regard will be very helpful for me.

With best regards

Kyohn
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier error

[SheikhJamil Ahmed]

Dear Gerhard,

We seems to have solved the issue with compatibility issue between BerryPI
and WIEN2WANNIER 0.96.(Thanks to Elias for his comments on case.klist_w90)

We have released a newer version of BerryPI (Version 1.0) which is
compatible with both WIEN2K12.1 and  WIEN2WANNIER 0.96. This newer version
also fixes some bugs in pi wrapping of the electronic phase (when it is
close to zero). It can be downloaded from the unsupported softwares page.

Thanks for pointing the issue.

PS: However we haven't tested BerryPI with the latest version of
WIEN2K(13.1) since it was just released today. But we believe it should be
compatible.


Sheikh

===
Sheikh Jamil Ahmed
B.Sc in Materials and Metallurgical Engineering
Graduate Research Assistant, Thunder Bay Regional Research Institute
M.Sc Candidate in Physics(Thesis), Lakehead University
290 Munro St, Thunder Bay, Ontario, P7A 7T1, Canada
Email :  sahm...@lakeheadu.ca



On 14 June 2013 11:47, Elias Assmann  wrote:

> On 06/13/2013 09:42 AM, Fecher, Gerhard wrote:
>
>> Recently I was playing with BerryPI and realizd that not all Versions
>> work together straight forward.
>> The latest BerryPI Version was not working together with wien2wannier
>> 0.96 and Wien2k_12
>>
>> one thing was that one of the routines was looking for case.klist_w90 ut
>> berry PI creates only case.klist.
>> This can be solved by copying the files or by changing the wien2wannier
>> 0.96 script back to use case.klist.
>>
>
> Just a brief comment on "klist_w90" (unfortunately I know nothing
> whatsoever about BerryPI): The different "klists" "kgens" and "outputkgens"
> that wien2wannier tries to maintain can be confusing.  In particular, I
> understand "klist_w90" as a backup of the k-mesh that was used for the
> projection; the "case.klist" may be changed later on if you do a
> Hamiltonian interpolation / woptic calculation / Wien-SCF / ...
>
>
> Elias
>
> __**_
> Wien mailing list
> w...@zeus.theochem.tuwien.ac.**at 
> http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:  http://www.mail-archive.com/**
> w...@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] wien2wannier error

[Elias Assmann]

On 06/13/2013 07:31 AM, wasim raja Mondal wrote:

(1) For the generating of *.nkp file, after running Write_win, one has
to run wannier90.x - -pp subdir which will creat the *.nnkp file if you
have used prepare_w2w case subdir. This is not mentioned in the user
guide. only wannier90.x will not work. This is a small thingh. But it
creates lot of tension in the first time user mind like me.


What user guide are you reading?  The one I downloaded from 
 
says (p. 3, under "Initialization (init_w2w)"):


wannier90.x(preliminary run): wannier90 requires the input data to be 
given on a special k-mesh which includes information with respect to 
nearest-neighbor k-points. A preliminary call of wannier90 with the 
option -pp stores this mesh to the file case.nnkp.




(2) Before running init_w2w, one hast to do subdir.sym file. In the file
one has to set number of symmetry operation is 1 and first operation has
to to be identity. This is discussed by phillip in the wien2k forum and
in the UG also. I think this symmetry is strongly related with k-points
generation. I may be wrong.


I assume you mean the "case.ksym" file.  This is generated (rather, you 
are asked to generate it) in init_w2w.




(3) I am felling that we are generating k-points in the init_w2w, which
is showing the number of k-points for LAPW computation. There is
previous generated k-points also which is called k-points for band
structure calculation. The number k-points for LAPW should be less than
the number of k-point for band structure k-point. In this point I may be
completely wrong. I want some experts comment on that.


The Wannier projection is done on a full-BZ unshifted k-mesh as 
generated in init_w2w.  This k-mesh can be rather sparse (8x8x8 already 
gives well-converged results for SrVO3, for example), but since no 
symmetries are considered, you still tend to end up with a lot of 
k-points to run lapw1 on compared to your standard Wien2k run.


write_win also reads the case.klist_band file, tries to sift out the 
"special" points (it takes those that have labels) and writes those to 
case.win (section kpoint_path).  Wannier90 will then (if bands_plot is 
True) make a band structure for a BZ path generated from those points. 
The discretization of that path is controlled by the variable 
bands_num_points.




(4)If third point is right, than one has to increase the number of
k-point in the band structure . In this point I am struggling at the
moment. For example I have run SrVO3 example in wien2k. In the scf I
have used 8000 k-points. In the band structure calculation I have
generated k-points in the simple cubic not with xcrysden. In the
init_w2w run, it is showing 10 k-points for band structure calculation.
Now the point is that how can I increase the k-point for band structure
calculation?


Note the last thing I said above -- the number of k-points in 
case_band.dat is independent of all the "klist" files; it is instead 
controlled by bands_num_points in case.win.



HTH,

Elias

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

[Elias Assmann]

On 06/12/2013 09:35 PM, wasim raja Mondal wrote:

(1) There was NaN . This was my mistake. I have not given the k-path. I
donot think it is related to any bug. I have given k-mesh. Now Nan is
not coming.


Okay.  There is a bug like that in write_win (where under some 
circumstances reading of case.klist_band will fail, and NaNs may appear 
in case.win).  But maybe in your case the cause was something else.



(2) when some body is doing init_w2w, "*.win" file is automatically
created. In the *.win file it is selecting hr_plot=true. which should be
commented out initially.


Why should it be commented out?


(3)In UG, in the init_w2w section (quick start), it is written after
write_win, run wannier90.x. with this you one cannot create *.nnkp file
which is the aim of the this preliminary run. One should run wannier90.x
--pp (subdir). then it will create the *.nnkp file.


"wannier90.x -pp $case" will normally be run by init_w2w.  If case.nnkp 
is not there, it means something went wrong in init_w2w.



(4) In the Ug, it is written w2w caes. It should be subdir. Because we
are doing prepare_w2w  caes subdir.


The "case" terminology, as well as the idea that (almost) all files are 
called "$case.$suffix" stems from Wien2k, but in Wien2k you do not give 
the "case" explicitly as an argument -- it is inferred from the working 
directory.  On the other hand, in Wannier90 you have to give a "case" 
argument, but I do not think it needs to match the CWD.


On the third hand, in wien2wannier, Philipp decided to follow 
Wannier90's lead in that you give a "case" argument to most of the 
programs he wrote.  But, since we also need to call Wien2k programs, 
effectively "case" also has to match the CWD.


History aside, it is up to you whether you want to run wien2wannier in 
your Wien2k "case" directory, or in a subdirectory (or a 
subsubdirectory, or in /tmp, or on a machine on the other side of the 
Earth).  While I would strongly advise using prepare_w2wdir, it is not 
mandatory.  So do not get hung up on this usage of the word "case" -- 
you can simply substitute $(basename $PWD) [at least if you use bash].



Elias

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

[Elias Assmann]

On 06/13/2013 09:42 AM, Fecher, Gerhard wrote:

Recently I was playing with BerryPI and realizd that not all Versions work 
together straight forward.
The latest BerryPI Version was not working together with wien2wannier 0.96 and 
Wien2k_12

one thing was that one of the routines was looking for case.klist_w90 ut berry 
PI creates only case.klist.
This can be solved by copying the files or by changing the wien2wannier 0.96 
script back to use case.klist.


Just a brief comment on "klist_w90" (unfortunately I know nothing 
whatsoever about BerryPI): The different "klists" "kgens" and 
"outputkgens" that wien2wannier tries to maintain can be confusing.  In 
particular, I understand "klist_w90" as a backup of the k-mesh that was 
used for the projection; the "case.klist" may be changed later on if you 
do a Hamiltonian interpolation / woptic calculation / Wien-SCF / ...


Elias

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

[Madhav Ghimire]

Dear wien2wannier users,
I met with an error while performing the spin-orbit coupled
wien2wannier calculations as shown below:

asahi01 banou135/banou135wann> w2wsp -so banou135wann
++ w2w for spin-orbit calculation ++
 ++ Preparing a spin-polarized def file for SO:up ++
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image  PCRoutineLineSource
libmkl_mc.so   2AAAB09B4B70  Unknown   Unknown  Unknown
++ w2w done for spin up component ++
 ++ Preparing a spin-polarized def file for SO:dn ++
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image  PCRoutineLineSource
libmkl_mc.so   2AAAB09B4B70  Unknown   Unknown  Unknown
++ w2w done for spin dn component ++
++ add up spin components ++
 case is:banou135wann
forrtl: severe (24): end-of-file during read, unit 1, file
/data1/ghimire123/Calculation_wien2k/perovskites/bnos/WANNIER/banou135/banou135wann/banou135wann.mmnup
Image  PCRoutineLineSource
combine_spinfiles  00488B31  Unknown   Unknown  Unknown
combine_spinfiles  00487B05  Unknown   Unknown  Unknown
combine_spinfiles  0044321A  Unknown   Unknown  Unknown
combine_spinfiles  004094D2  Unknown   Unknown  Unknown
combine_spinfiles  00408D01  Unknown   Unknown  Unknown
combine_spinfiles  004222AE  Unknown   Unknown  Unknown
combine_spinfiles  004058F4  Unknown   Unknown  Unknown
combine_spinfiles  00402B1C  Unknown   Unknown  Unknown
libc.so.6  2AE52184  Unknown   Unknown  Unknown
combine_spinfiles  00402A49  Unknown   Unknown  Unknown

The error file shows:
Error in LAPW2DM.

I fail to identify the section where the error comes from.
Your guidance to solve this problem will be greatly appreciated.
Thanks for your kind cooperation.
Best regards
Madhav



On Thu, Jun 13, 2013 at 10:19 PM, SheikhJamil Ahmed wrote:

> Dear Gerhard,
>
> We have tested BerryPI with Wien2k_12 and wien2wannier 0.92 before where
> it worked fine. However, we didn't test with wien2wannier 0.96
> and Wien2k_12.
>
> Sorry for this inconvenience. We will try to fix this issue as soon as
> possible. Possibly, we will have to release a new version of BerryPI which
> is compatible with wien2wannier 0.96.
>
> Thanks for your interest in BerryPI.
>
> Regards
>
> Sheikh
>
>
> ===
> Sheikh Jamil Ahmed
> B.Sc in Materials and Metallurgical Engineering
> Graduate Research Assistant, Thunder Bay Regional Research Institute
> M.Sc Candidate in Physics(Thesis), Lakehead University
> 290 Munro St, Thunder Bay, Ontario, P7A 7T1, Canada
> Email :  sahm...@lakeheadu.ca
>
>  
>
>
>
>
> On 13 June 2013 08:50, Oleg Rubel  wrote:
>
>> Dear Gerhard,
>>
>> thank you very much for mentioning the incompatibility. We just recently
>> installed Wien2k_12. I will make sure that BerryPI is compatible with the
>> latest versions of w2w and Wien2k.
>>
>> Best regards
>> Oleg
>>
>>
>> On 13-06-13 3:42 AM, Fecher, Gerhard wrote:
>>
>>> Dear Oleg,
>>> this is concerning your PS.
>>>
>>> Recently I was playing with BerryPI and realizd that not all Versions
>>> work together straight forward.
>>> The latest BerryPI Version was not working together with wien2wannier
>>> 0.96 and Wien2k_12
>>>
>>> one thing was that one of the routines was looking for case.klist_w90 ut
>>> berry PI creates only case.klist.
>>> This can be solved by copying the files or by changing the wien2wannier
>>> 0.96 script back to use case.klist.
>>>
>>> After that BerryPI was working together with Wien2k_11, but not with
>>> Wien2k_12
>>>
>>> Maybe someone has an idea
>>>
>>> Ciao
>>> Gerhard
>>>
>>>
>>> ==**==
>>> Dr. Gerhard H. Fecher
>>> Institut of Inorganic and Analytical Chemistry
>>> Johannes Gutenberg - University
>>> 55099 Mainz
>>> __**__
>>> Von: 
>>> wien-bounces@zeus.theochem.**tuwien.ac.at[
>>> wien-bounces@zeus.theochem.**tuwien.ac.at]"
>>> im Auftrag von "Oleg Rubel [oru...@lakeheadu.ca]
>>> Gesendet: Mittwoch, 12. Juni 2013 18:05
>>> An: w...@zeus.theochem.tuwien.ac.**at 
>>> Betreff: Re: [Wien] wien2wannier error
>>>
>>> Dear Elias,
>>>
>>> Thank

Re: [Wien] wien2wannier error

[SheikhJamil Ahmed]

Dear Gerhard,

We have tested BerryPI with Wien2k_12 and wien2wannier 0.92 before where it
worked fine. However, we didn't test with wien2wannier 0.96 and Wien2k_12.

Sorry for this inconvenience. We will try to fix this issue as soon as
possible. Possibly, we will have to release a new version of BerryPI which
is compatible with wien2wannier 0.96.

Thanks for your interest in BerryPI.

Regards

Sheikh


===
Sheikh Jamil Ahmed
B.Sc in Materials and Metallurgical Engineering
Graduate Research Assistant, Thunder Bay Regional Research Institute
M.Sc Candidate in Physics(Thesis), Lakehead University
290 Munro St, Thunder Bay, Ontario, P7A 7T1, Canada
Email :  sahm...@lakeheadu.ca






On 13 June 2013 08:50, Oleg Rubel  wrote:

> Dear Gerhard,
>
> thank you very much for mentioning the incompatibility. We just recently
> installed Wien2k_12. I will make sure that BerryPI is compatible with the
> latest versions of w2w and Wien2k.
>
> Best regards
> Oleg
>
>
> On 13-06-13 3:42 AM, Fecher, Gerhard wrote:
>
>> Dear Oleg,
>> this is concerning your PS.
>>
>> Recently I was playing with BerryPI and realizd that not all Versions
>> work together straight forward.
>> The latest BerryPI Version was not working together with wien2wannier
>> 0.96 and Wien2k_12
>>
>> one thing was that one of the routines was looking for case.klist_w90 ut
>> berry PI creates only case.klist.
>> This can be solved by copying the files or by changing the wien2wannier
>> 0.96 script back to use case.klist.
>>
>> After that BerryPI was working together with Wien2k_11, but not with
>> Wien2k_12
>>
>> Maybe someone has an idea
>>
>> Ciao
>> Gerhard
>>
>>
>> ==**==
>> Dr. Gerhard H. Fecher
>> Institut of Inorganic and Analytical Chemistry
>> Johannes Gutenberg - University
>> 55099 Mainz
>> __**__
>> Von: 
>> wien-bounces@zeus.theochem.**tuwien.ac.at[
>> wien-bounces@zeus.theochem.**tuwien.ac.at]"
>> im Auftrag von "Oleg Rubel [oru...@lakeheadu.ca]
>> Gesendet: Mittwoch, 12. Juni 2013 18:05
>> An: w...@zeus.theochem.tuwien.ac.**at 
>> Betreff: Re: [Wien] wien2wannier error
>>
>> Dear Elias,
>>
>> Thank you for the reply.
>>
>> Here is one more guess: mixed units in the provided *win
>>
>> The following line (begin unit_cell_cart, ang) suggests [Angstr] units,
>> whereas the numbers are definitely in [Bohr].
>>
>> Latter (begin atoms_cart), the atomic positions appear in [A].
>>
>>
>> Thank you
>> Oleg
>>
>> P.S. I am particularly interested in wien2wannier because it works with
>> BerryPI for polarization calculation. We did not have a problem with
>> BaTiO3 and other perovskite structures. However, I should admit that we
>> stop at w2w and do not proceed with wannier90.
>>
>>
>> On 12/06/2013 11:47 AM, Elias Assmann wrote:
>>
>>> Dear Oleg,
>>>
>>> On 06/12/2013 04:11 PM, Oleg Rubel wrote:
>>>
>>>> I am certainly not an expert in w2w, but I noticed some "NaN" in the
>>>> kpoint_path. This is usually not a good sign. Is it normal?
>>>>
>>>
>>> Good catch, but that cannot explain the error as reported.
>>>
>>> These NaNs are in fact due to a bug in write_win (sorry!).  It will be
>>> fixed in the next wien2wannier version, until then it is probably best
>>> to put in the right coordinates by hand.
>>>
>>> In any case, the actual Wannier projection should be independent of
>>> these NaNs.  I expect them to show up only in the band structure
>>> (“_band.dat”), but I am not sure exactly how.
>>>
>>>   Elias
>>>
>>> __**_
>>> Wien mailing list
>>> w...@zeus.theochem.tuwien.ac.**at 
>>> http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wien<http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien>
>>> SEARCH the MAILING-LIST at:
>>> http://www.mail-archive.com/**w...@zeus.theochem.tuwien.ac.**
>>> at/index.html<http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html>
>>>
>> __**_
>> Wien mailing list
>> w...@zeus.theochem.tuwien.ac.**at 
>> http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wien<http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien>
>> SEARCH the MAILING-LIST at:  http://www.mail-archive.com/**
>> w...

Re: [Wien] wien2wannier error

[Oleg Rubel]

Dear Gerhard,

thank you very much for mentioning the incompatibility. We just recently 
installed Wien2k_12. I will make sure that BerryPI is compatible with 
the latest versions of w2w and Wien2k.


Best regards
Oleg

On 13-06-13 3:42 AM, Fecher, Gerhard wrote:

Dear Oleg,
this is concerning your PS.

Recently I was playing with BerryPI and realizd that not all Versions work 
together straight forward.
The latest BerryPI Version was not working together with wien2wannier 0.96 and 
Wien2k_12

one thing was that one of the routines was looking for case.klist_w90 ut berry 
PI creates only case.klist.
This can be solved by copying the files or by changing the wien2wannier 0.96 
script back to use case.klist.

After that BerryPI was working together with Wien2k_11, but not with Wien2k_12

Maybe someone has an idea

Ciao
Gerhard



Dr. Gerhard H. Fecher
Institut of Inorganic and Analytical Chemistry
Johannes Gutenberg - University
55099 Mainz

Von: wien-boun...@zeus.theochem.tuwien.ac.at 
[wien-boun...@zeus.theochem.tuwien.ac.at]" im Auftrag von "Oleg Rubel 
[oru...@lakeheadu.ca]
Gesendet: Mittwoch, 12. Juni 2013 18:05
An: wien@zeus.theochem.tuwien.ac.at
Betreff: Re: [Wien] wien2wannier error

Dear Elias,

Thank you for the reply.

Here is one more guess: mixed units in the provided *win

The following line (begin unit_cell_cart, ang) suggests [Angstr] units,
whereas the numbers are definitely in [Bohr].

Latter (begin atoms_cart), the atomic positions appear in [A].


Thank you
Oleg

P.S. I am particularly interested in wien2wannier because it works with
BerryPI for polarization calculation. We did not have a problem with
BaTiO3 and other perovskite structures. However, I should admit that we
stop at w2w and do not proceed with wannier90.


On 12/06/2013 11:47 AM, Elias Assmann wrote:

Dear Oleg,

On 06/12/2013 04:11 PM, Oleg Rubel wrote:

I am certainly not an expert in w2w, but I noticed some "NaN" in the
kpoint_path. This is usually not a good sign. Is it normal?


Good catch, but that cannot explain the error as reported.

These NaNs are in fact due to a bug in write_win (sorry!).  It will be
fixed in the next wien2wannier version, until then it is probably best
to put in the right coordinates by hand.

In any case, the actual Wannier projection should be independent of
these NaNs.  I expect them to show up only in the band structure
(“_band.dat”), but I am not sure exactly how.

  Elias

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

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


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

Re: [Wien] wien2wannier error

[Oleg Rubel]

I would suggest to explore 'x kgen -fbz'
According to the UG: -fbz -> runs kgen and generates a full mesh in the BZ

Possibly, it will help to avoid editing of the structure file.

Oleg


On 13-06-13 2:36 AM, wasim raja Mondal wrote:

Hi Madhav

I can generate 64 k-points in klist but in that case *.win file will not
be generated because it is telling 10-kpoints for band structure
calculation. If band structure k-points are more than 64, I can generate
64 k-point and create win file also. I am talking about SrVO3 example.
May be I am wrong, not an expert For generation you can do following thing:

In the lower part, put 1 instead of 12 in number of symmetry operation.

Just above 1 you have following in your ksym.

  -1 0 0 0.
  0-1 0 0.
  0 0-1 0.
1

Make this as following:
  1 0 0 0.
  0 1 0 0.
  0 0 1 0.
1

In tha last part
..
...
...

I think this lines you have deleted. Keep this line as it is.

I am also waiting for some expert comment.

Regards
wasim



On Thu, Jun 13, 2013 at 11:55 AM, Madhav Ghimire mailto:ghimire@gmail.com>> wrote:

Dear wasim,
Thanks for the immediate response.
Keeping your second point in mind, I regenerated the subdirectory
with case.ksym.
The structure file generated by wien2k reads 12 symmetry for my
studied fcc system as shown below:
ba2naoso6
F4 25_F
  RELA
  15.660167 15.660167 15.660167 90.00 90.00 90.00
ATOM   1: X=0.2500 Y=0.2500 Z=0.2500
   MULT= 2  ISPLIT= 2
1: X=0.7500 Y=0.7500 Z=0.7500
Ba NPT=  781  R0=.1 RMT=   2.5   Z:  56.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.5000 Y=0.5000 Z=0.5000
   MULT= 1  ISPLIT= 2
Na NPT=  781  R0=.00010 RMT=   2.14  Z:  11.0
LOCAL ROT MATRIX:1.000 0.000 0.000
  0.000 1.000 0.000
  0.000 0.000 1.000
ATOM   3: X=0. Y=0. Z=0.
   MULT= 1  ISPLIT= 2
Os NPT=  781  R0=.05000 RMT=   1.86  Z:  76.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.22566000 Y=0. Z=0.
   MULT= 6  ISPLIT=-2
   -4: X=0.77434000 Y=0. Z=0.
   -4: X=0. Y=0.22566000 Z=0.
   -4: X=0. Y=0.77434000 Z=0.
   -4: X=0. Y=0. Z=0.22566000
   -4: X=0. Y=0. Z=0.77434000
O  NPT=  781  R0=.00010 RMT=   1.65  Z:   8.0
LOCAL ROT MATRIX:0.000 0.000 1.000
  0.000 1.000 0.000
 -1.000 0.000 0.000
   12  NUMBER OF SYMMETRY OPERATIONS
-1 0 0 0.
  0-1 0 0.
  0 0-1 0.
1
..
...
...

Then I replaced 12 with 1 symmetry operation in case.ksym file. This
generates 47 kpoints (instead of 64).

It seems very complicated.
Let's expect some expert response too.
Thanks .
Request: Pls see if you can generate 64 kpoints using the above
structure.
Best regards
Madhav


On Thu, Jun 13, 2013 at 2:31 PM, wasim raja Mondal
mailto:wasimr.mon...@gmail.com>> wrote:

Hi Madhav

Thanks for taking part in this discussion. The following four
thing should be noticed:

(1) For the generating of *.nkp file, after running Write_win,
one has to run wannier90.x - -pp subdir which will creat the
*.nnkp file if you have used prepare_w2w case subdir. This is
not mentioned in the user guide. only wannier90.x will not work.
This is a small thingh. But it creates lot of tension in the
first time user mind like me.

(2) Before running init_w2w, one hast to do subdir.sym file. In
the file one has to set number of symmetry operation is 1 and
first operation has to to be identity. This is discussed by
phillip in the wien2k forum and in the UG also. I think this
symmetry is strongly related with k-points generation. I may be
wrong.

(3) I am felling that we are generating k-points in the
init_w2w, which is showing the number of k-points for LAPW
computation. There is previous generated k-points also which is
called k-points for band structur

Re: [Wien] wien2wannier error

[Fecher, Gerhard]

Dear Oleg,
this is concerning your PS.

Recently I was playing with BerryPI and realizd that not all Versions work 
together straight forward.
The latest BerryPI Version was not working together with wien2wannier 0.96 and 
Wien2k_12

one thing was that one of the routines was looking for case.klist_w90 ut berry 
PI creates only case.klist.
This can be solved by copying the files or by changing the wien2wannier 0.96 
script back to use case.klist.

After that BerryPI was working together with Wien2k_11, but not with Wien2k_12

Maybe someone has an idea

Ciao
Gerhard



Dr. Gerhard H. Fecher
Institut of Inorganic and Analytical Chemistry
Johannes Gutenberg - University
55099 Mainz

Von: wien-boun...@zeus.theochem.tuwien.ac.at 
[wien-boun...@zeus.theochem.tuwien.ac.at]" im Auftrag von "Oleg Rubel 
[oru...@lakeheadu.ca]
Gesendet: Mittwoch, 12. Juni 2013 18:05
An: wien@zeus.theochem.tuwien.ac.at
Betreff: Re: [Wien] wien2wannier error

Dear Elias,

Thank you for the reply.

Here is one more guess: mixed units in the provided *win

The following line (begin unit_cell_cart, ang) suggests [Angstr] units,
whereas the numbers are definitely in [Bohr].

Latter (begin atoms_cart), the atomic positions appear in [A].


Thank you
Oleg

P.S. I am particularly interested in wien2wannier because it works with
BerryPI for polarization calculation. We did not have a problem with
BaTiO3 and other perovskite structures. However, I should admit that we
stop at w2w and do not proceed with wannier90.


On 12/06/2013 11:47 AM, Elias Assmann wrote:
> Dear Oleg,
>
> On 06/12/2013 04:11 PM, Oleg Rubel wrote:
>> I am certainly not an expert in w2w, but I noticed some "NaN" in the
>> kpoint_path. This is usually not a good sign. Is it normal?
>
> Good catch, but that cannot explain the error as reported.
>
> These NaNs are in fact due to a bug in write_win (sorry!).  It will be
> fixed in the next wien2wannier version, until then it is probably best
> to put in the right coordinates by hand.
>
> In any case, the actual Wannier projection should be independent of
> these NaNs.  I expect them to show up only in the band structure
> (“_band.dat”), but I am not sure exactly how.
>
>  Elias
>
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> http://zeus.theochem.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] wien2wannier error

[Madhav Ghimire]

Dear Wasim,
Thank you so much.
It worked perfectly well.

Best regards.
Madhav

On Thu, Jun 13, 2013 at 3:36 PM, wasim raja Mondal
wrote:

> Hi Madhav
>
> I can generate 64 k-points in klist but in that case *.win file will not
> be generated because it is telling 10-kpoints for band structure
> calculation. If band structure k-points are more than 64, I can generate 64
> k-point and create win file also. I am talking about SrVO3 example. May be
> I am wrong, not an expert For generation you can do following thing:
>
> In the lower part, put 1 instead of 12 in number of symmetry operation.
>
> Just above 1 you have following in your ksym.
>
>  -1 0 0 0.
>  0-1 0 0.
>  0 0-1 0.
>1
>
> Make this as following:
>  1 0 0 0.
>  0 1 0 0.
>  0 0 1 0.
>1
>
> In tha last part
> ..
> ...
> ...
>
> I think this lines you have deleted. Keep this line as it is.
>
> I am also waiting for some expert comment.
>
> Regards
> wasim
>
>
>
> On Thu, Jun 13, 2013 at 11:55 AM, Madhav Ghimire wrote:
>
>> Dear wasim,
>>Thanks for the immediate response.
>> Keeping your second point in mind, I regenerated the subdirectory with
>> case.ksym.
>> The structure file generated by wien2k reads 12 symmetry for my studied
>> fcc system as shown below:
>> ba2naoso6
>> F4 25_F
>>  RELA
>>  15.660167 15.660167 15.660167 90.00 90.00 90.00
>> ATOM   1: X=0.2500 Y=0.2500 Z=0.2500
>>   MULT= 2  ISPLIT= 2
>>1: X=0.7500 Y=0.7500 Z=0.7500
>> Ba NPT=  781  R0=.1 RMT=   2.5   Z:  56.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.5000 Y=0.5000 Z=0.5000
>>   MULT= 1  ISPLIT= 2
>> Na NPT=  781  R0=.00010 RMT=   2.14  Z:  11.0
>> LOCAL ROT MATRIX:1.000 0.000 0.000
>>  0.000 1.000 0.000
>>  0.000 0.000 1.000
>> ATOM   3: X=0. Y=0. Z=0.
>>   MULT= 1  ISPLIT= 2
>> Os NPT=  781  R0=.05000 RMT=   1.86  Z:  76.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.22566000 Y=0. Z=0.
>>   MULT= 6  ISPLIT=-2
>>   -4: X=0.77434000 Y=0. Z=0.
>>   -4: X=0. Y=0.22566000 Z=0.
>>   -4: X=0. Y=0.77434000 Z=0.
>>   -4: X=0. Y=0. Z=0.22566000
>>   -4: X=0. Y=0. Z=0.77434000
>> O  NPT=  781  R0=.00010 RMT=   1.65  Z:   8.0
>> LOCAL ROT MATRIX:0.000 0.000 1.000
>>  0.000 1.000 0.000
>> -1.000 0.000 0.000
>>   12  NUMBER OF SYMMETRY OPERATIONS
>> -1 0 0 0.
>>  0-1 0 0.
>>  0 0-1 0.
>>1
>> ..
>> ...
>> ...
>>
>> Then I replaced 12 with 1 symmetry operation in case.ksym file. This
>> generates 47 kpoints (instead of 64).
>>
>> It seems very complicated.
>> Let's expect some expert response too.
>> Thanks .
>> Request: Pls see if you can generate 64 kpoints using the above structure.
>> Best regards
>> Madhav
>>
>>
>> On Thu, Jun 13, 2013 at 2:31 PM, wasim raja Mondal <
>> wasimr.mon...@gmail.com> wrote:
>>
>>> Hi Madhav
>>>
>>> Thanks for taking part in this discussion. The following four thing
>>> should be noticed:
>>>
>>> (1) For the generating of *.nkp file, after running Write_win, one has
>>> to run wannier90.x - -pp subdir which will creat the *.nnkp file if you
>>> have used prepare_w2w case subdir. This is not mentioned in the user guide.
>>> only wannier90.x will not work. This is a small thingh. But it creates lot
>>> of tension in the first time user mind like me.
>>>
>>> (2) Before running init_w2w, one hast to do subdir.sym file. In the file
>>> one has to set number of symmetry operation is 1 and first operation has to
>>> to be identity. This is discussed by phillip in the wien2k forum and in the
>>> UG also. I think this symmetry is strongly related with k-points
>>> generation. I may be wrong.
>>>
>>> (3) I am felling that we are generating k-points in the init_w2w, which
>>> is showing the number of k-points for LAPW computation. There is previous
>>> generated k-points also which is called k-points for band structure
>>> calculation. The number k-points for LAPW should be less than the number of
>>> k-point for band structure k-point. In this point I may be completely
>>> wrong. I want some experts comment on that.
>>>
>>> (4)If third po

Re: [Wien] wien2wannier error

[wasim raja Mondal]

Hi Madhav

I can generate 64 k-points in klist but in that case *.win file will not be
generated because it is telling 10-kpoints for band structure calculation.
If band structure k-points are more than 64, I can generate 64 k-point and
create win file also. I am talking about SrVO3 example. May be I am wrong,
not an expert For generation you can do following thing:

In the lower part, put 1 instead of 12 in number of symmetry operation.

Just above 1 you have following in your ksym.

 -1 0 0 0.
 0-1 0 0.
 0 0-1 0.
   1

Make this as following:
 1 0 0 0.
 0 1 0 0.
 0 0 1 0.
   1

In tha last part
..
...
...

I think this lines you have deleted. Keep this line as it is.

I am also waiting for some expert comment.

Regards
wasim



On Thu, Jun 13, 2013 at 11:55 AM, Madhav Ghimire wrote:

> Dear wasim,
>Thanks for the immediate response.
> Keeping your second point in mind, I regenerated the subdirectory with
> case.ksym.
> The structure file generated by wien2k reads 12 symmetry for my studied
> fcc system as shown below:
> ba2naoso6
> F4 25_F
>  RELA
>  15.660167 15.660167 15.660167 90.00 90.00 90.00
> ATOM   1: X=0.2500 Y=0.2500 Z=0.2500
>   MULT= 2  ISPLIT= 2
>1: X=0.7500 Y=0.7500 Z=0.7500
> Ba NPT=  781  R0=.1 RMT=   2.5   Z:  56.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.5000 Y=0.5000 Z=0.5000
>   MULT= 1  ISPLIT= 2
> Na NPT=  781  R0=.00010 RMT=   2.14  Z:  11.0
> LOCAL ROT MATRIX:1.000 0.000 0.000
>  0.000 1.000 0.000
>  0.000 0.000 1.000
> ATOM   3: X=0. Y=0. Z=0.
>   MULT= 1  ISPLIT= 2
> Os NPT=  781  R0=.05000 RMT=   1.86  Z:  76.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.22566000 Y=0. Z=0.
>   MULT= 6  ISPLIT=-2
>   -4: X=0.77434000 Y=0. Z=0.
>   -4: X=0. Y=0.22566000 Z=0.
>   -4: X=0. Y=0.77434000 Z=0.
>   -4: X=0. Y=0. Z=0.22566000
>   -4: X=0. Y=0. Z=0.77434000
> O  NPT=  781  R0=.00010 RMT=   1.65  Z:   8.0
> LOCAL ROT MATRIX:0.000 0.000 1.000
>  0.000 1.000 0.000
> -1.000 0.000 0.000
>   12  NUMBER OF SYMMETRY OPERATIONS
> -1 0 0 0.
>  0-1 0 0.
>  0 0-1 0.
>1
> ..
> ...
> ...
>
> Then I replaced 12 with 1 symmetry operation in case.ksym file. This
> generates 47 kpoints (instead of 64).
>
> It seems very complicated.
> Let's expect some expert response too.
> Thanks .
> Request: Pls see if you can generate 64 kpoints using the above structure.
> Best regards
> Madhav
>
>
> On Thu, Jun 13, 2013 at 2:31 PM, wasim raja Mondal <
> wasimr.mon...@gmail.com> wrote:
>
>> Hi Madhav
>>
>> Thanks for taking part in this discussion. The following four thing
>> should be noticed:
>>
>> (1) For the generating of *.nkp file, after running Write_win, one has to
>> run wannier90.x - -pp subdir which will creat the *.nnkp file if you have
>> used prepare_w2w case subdir. This is not mentioned in the user guide. only
>> wannier90.x will not work. This is a small thingh. But it creates lot of
>> tension in the first time user mind like me.
>>
>> (2) Before running init_w2w, one hast to do subdir.sym file. In the file
>> one has to set number of symmetry operation is 1 and first operation has to
>> to be identity. This is discussed by phillip in the wien2k forum and in the
>> UG also. I think this symmetry is strongly related with k-points
>> generation. I may be wrong.
>>
>> (3) I am felling that we are generating k-points in the init_w2w, which
>> is showing the number of k-points for LAPW computation. There is previous
>> generated k-points also which is called k-points for band structure
>> calculation. The number k-points for LAPW should be less than the number of
>> k-point for band structure k-point. In this point I may be completely
>> wrong. I want some experts comment on that.
>>
>> (4)If third point is right, than one has to increase the number of
>> k-point in the band structure . In this point I am struggling at the
>> moment. For example I have run SrVO3 example in wien2k. In the scf I have
>> used 8000 k-points. In the band structure calculation I have generated
>> k-points in the s

Re: [Wien] wien2wannier error

[Madhav Ghimire]

Dear wasim,
   Thanks for the immediate response.
Keeping your second point in mind, I regenerated the subdirectory with
case.ksym.
The structure file generated by wien2k reads 12 symmetry for my studied fcc
system as shown below:
ba2naoso6
F4 25_F
 RELA
 15.660167 15.660167 15.660167 90.00 90.00 90.00
ATOM   1: X=0.2500 Y=0.2500 Z=0.2500
  MULT= 2  ISPLIT= 2
   1: X=0.7500 Y=0.7500 Z=0.7500
Ba NPT=  781  R0=.1 RMT=   2.5   Z:  56.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.5000 Y=0.5000 Z=0.5000
  MULT= 1  ISPLIT= 2
Na NPT=  781  R0=.00010 RMT=   2.14  Z:  11.0
LOCAL ROT MATRIX:1.000 0.000 0.000
 0.000 1.000 0.000
 0.000 0.000 1.000
ATOM   3: X=0. Y=0. Z=0.
  MULT= 1  ISPLIT= 2
Os NPT=  781  R0=.05000 RMT=   1.86  Z:  76.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.22566000 Y=0. Z=0.
  MULT= 6  ISPLIT=-2
  -4: X=0.77434000 Y=0. Z=0.
  -4: X=0. Y=0.22566000 Z=0.
  -4: X=0. Y=0.77434000 Z=0.
  -4: X=0. Y=0. Z=0.22566000
  -4: X=0. Y=0. Z=0.77434000
O  NPT=  781  R0=.00010 RMT=   1.65  Z:   8.0
LOCAL ROT MATRIX:0.000 0.000 1.000
 0.000 1.000 0.000
-1.000 0.000 0.000
  12  NUMBER OF SYMMETRY OPERATIONS
-1 0 0 0.
 0-1 0 0.
 0 0-1 0.
   1
..
...
...

Then I replaced 12 with 1 symmetry operation in case.ksym file. This
generates 47 kpoints (instead of 64).

It seems very complicated.
Let's expect some expert response too.
Thanks .
Request: Pls see if you can generate 64 kpoints using the above structure.
Best regards
Madhav

On Thu, Jun 13, 2013 at 2:31 PM, wasim raja Mondal
wrote:

> Hi Madhav
>
> Thanks for taking part in this discussion. The following four thing should
> be noticed:
>
> (1) For the generating of *.nkp file, after running Write_win, one has to
> run wannier90.x - -pp subdir which will creat the *.nnkp file if you have
> used prepare_w2w case subdir. This is not mentioned in the user guide. only
> wannier90.x will not work. This is a small thingh. But it creates lot of
> tension in the first time user mind like me.
>
> (2) Before running init_w2w, one hast to do subdir.sym file. In the file
> one has to set number of symmetry operation is 1 and first operation has to
> to be identity. This is discussed by phillip in the wien2k forum and in the
> UG also. I think this symmetry is strongly related with k-points
> generation. I may be wrong.
>
> (3) I am felling that we are generating k-points in the init_w2w, which is
> showing the number of k-points for LAPW computation. There is previous
> generated k-points also which is called k-points for band structure
> calculation. The number k-points for LAPW should be less than the number of
> k-point for band structure k-point. In this point I may be completely
> wrong. I want some experts comment on that.
>
> (4)If third point is right, than one has to increase the number of k-point
> in the band structure . In this point I am struggling at the moment. For
> example I have run SrVO3 example in wien2k. In the scf I have used 8000
> k-points. In the band structure calculation I have generated k-points in
> the simple cubic not with xcrysden. In the init_w2w run, it is showing 10
> k-points for band structure calculation. Now the point is that how can I
> increase the k-point for band structure calculation?
>
>
> Regards
> wasim
>
>
>
>
>
>
>
>
> On Thu, Jun 13, 2013 at 10:30 AM, Madhav Ghimire wrote:
>
>> Dear wien2wannier users & experts,
>>   Let me add my problem too in Wasim's mail:
>>
>> I am facing problems in generating case.nnkp files from wien2wannier even
>> for a simple perovskites with fcc structure:
>> Starting from init_w2w, I follow all the steps given in userguide. It
>> generates the case.win file but not the case.nnkp. On the case.error file I
>> found:
>>
>> Wannier90: Execution started on 13Jun2013 at 13:16:19
>>  Exiting...
>>  Error: Wrong number of lines in block kpoints
>>
>> From the above information I understand that case.nnkp could not be
>> generated due to inconsistent kpoints:
>>
>> For confirmation I performed the test calculation of SrVO3 separately and
>> noted the same error.
>>
>> When I looked on the test examples of SrVO3 given in source co

Re: [Wien] wien2wannier error

[wasim raja Mondal]

Hi Madhav

Thanks for taking part in this discussion. The following four thing should
be noticed:

(1) For the generating of *.nkp file, after running Write_win, one has to
run wannier90.x - -pp subdir which will creat the *.nnkp file if you have
used prepare_w2w case subdir. This is not mentioned in the user guide. only
wannier90.x will not work. This is a small thingh. But it creates lot of
tension in the first time user mind like me.

(2) Before running init_w2w, one hast to do subdir.sym file. In the file
one has to set number of symmetry operation is 1 and first operation has to
to be identity. This is discussed by phillip in the wien2k forum and in the
UG also. I think this symmetry is strongly related with k-points
generation. I may be wrong.

(3) I am felling that we are generating k-points in the init_w2w, which is
showing the number of k-points for LAPW computation. There is previous
generated k-points also which is called k-points for band structure
calculation. The number k-points for LAPW should be less than the number of
k-point for band structure k-point. In this point I may be completely
wrong. I want some experts comment on that.

(4)If third point is right, than one has to increase the number of k-point
in the band structure . In this point I am struggling at the moment. For
example I have run SrVO3 example in wien2k. In the scf I have used 8000
k-points. In the band structure calculation I have generated k-points in
the simple cubic not with xcrysden. In the init_w2w run, it is showing 10
k-points for band structure calculation. Now the point is that how can I
increase the k-point for band structure calculation?


Regards
wasim








On Thu, Jun 13, 2013 at 10:30 AM, Madhav Ghimire wrote:

> Dear wien2wannier users & experts,
>   Let me add my problem too in Wasim's mail:
>
> I am facing problems in generating case.nnkp files from wien2wannier even
> for a simple perovskites with fcc structure:
> Starting from init_w2w, I follow all the steps given in userguide. It
> generates the case.win file but not the case.nnkp. On the case.error file I
> found:
>
> Wannier90: Execution started on 13Jun2013 at 13:16:19
>  Exiting...
>  Error: Wrong number of lines in block kpoints
>
> From the above information I understand that case.nnkp could not be
> generated due to inconsistent kpoints:
>
> For confirmation I performed the test calculation of SrVO3 separately and
> noted the same error.
>
> When I looked on the test examples of SrVO3 given in source code:
> There exist two files debug.klista and debug.klistb. For bandstructure
> calculation with Wien2k, debug.klista file with shift k-mesh having only 10
> kpoints in Irreducible Brillouin zone generated with 4x4x4 were used.
> Whereas for wien2wannier calculations, debug.klistb file were used which
> was also generated using 4x4x4 but corresponding to total of 64 points in
> full BZ.
>
> (a) What is the reason for different k-points in wien2k bandstructure
> calculations and wien2wannier
> (b) While running init_w2w and selecting kgen 4x4x4, the total k-points is
> only 13 [not 64]. Why?
> (c) How to generate 64  or 1000 k-points from init_w2w  when 4x4x4 or
> 10x10x10 were selected.
>
> I will be very glad for your good response to solve this issue.
> Thanks in advance
> Madhav Ghimire
> NIMS
> -
>
>
>
> On Thu, Jun 13, 2013 at 4:35 AM, wasim raja Mondal <
> wasimr.mon...@gmail.com> wrote:
>
>> Hi oleg
>>
>>  I solved the problem.  I am first time using this. Thats why I wanted
>> some help.  correct me if I am wrong. According to me the reason of the
>> errors are following :
>>
>> (1) There was NaN . This was my mistake. I have not given the k-path. I
>> donot think it is related to any bug. I have given k-mesh. Now Nan is not
>> coming.
>>
>> (2) when some body is doing init_w2w, "*.win" file is automatically
>> created. In the *.win file it is selecting hr_plot=true. which should be
>> commented out initially.
>>
>> (3)In UG, in the init_w2w section (quick start), it is written after
>> write_win, run wannier90.x. with this you one cannot create *.nnkp file
>> which is the aim of the this preliminary run. One should run wannier90.x
>> --pp (subdir). then it will create the *.nnkp file.
>>
>> (4) In the Ug, it is written w2w caes. It should be subdir. Because we
>> are doing prepare_w2w  caes subdir.
>>
>> (5) To get the hr_dat file, you at last uncomment the hr_plot=true and
>> make one final run with all the necessary file.
>>wannier90.x subdir
>>
>>
>>
>> Still I have some doubt about the k-point. I am trying this. But with 2 2
>> 2 k-point I am able to generate the hr_dat file.
>>
>>
>> Regards
>> wasim
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Jun 12, 2013 at 10:34 PM, wasim raja Mondal <
>> wasimr.mon...@gmail.com> wrote:
>>
>>> Hi oleg
>>>Thanks.
>>>
>>>
>>> On Wed, Jun 12, 2013 at 9:35 PM, Oleg Rubel  wrote:
>>>
 Dear Elias,

 Thank you for the reply.

 Here is one more guess: mi

Re: [Wien] wien2wannier error

[Madhav Ghimire]

Dear wien2wannier users & experts,
  Let me add my problem too in Wasim's mail:

I am facing problems in generating case.nnkp files from wien2wannier even
for a simple perovskites with fcc structure:
Starting from init_w2w, I follow all the steps given in userguide. It
generates the case.win file but not the case.nnkp. On the case.error file I
found:

Wannier90: Execution started on 13Jun2013 at 13:16:19
 Exiting...
 Error: Wrong number of lines in block kpoints

>From the above information I understand that case.nnkp could not be
generated due to inconsistent kpoints:

For confirmation I performed the test calculation of SrVO3 separately and
noted the same error.

When I looked on the test examples of SrVO3 given in source code:
There exist two files debug.klista and debug.klistb. For bandstructure
calculation with Wien2k, debug.klista file with shift k-mesh having only 10
kpoints in Irreducible Brillouin zone generated with 4x4x4 were used.
Whereas for wien2wannier calculations, debug.klistb file were used which
was also generated using 4x4x4 but corresponding to total of 64 points in
full BZ.

(a) What is the reason for different k-points in wien2k bandstructure
calculations and wien2wannier
(b) While running init_w2w and selecting kgen 4x4x4, the total k-points is
only 13 [not 64]. Why?
(c) How to generate 64  or 1000 k-points from init_w2w  when 4x4x4 or
10x10x10 were selected.

I will be very glad for your good response to solve this issue.
Thanks in advance
Madhav Ghimire
NIMS
-


On Thu, Jun 13, 2013 at 4:35 AM, wasim raja Mondal
wrote:

> Hi oleg
>
>  I solved the problem.  I am first time using this. Thats why I wanted
> some help.  correct me if I am wrong. According to me the reason of the
> errors are following :
>
> (1) There was NaN . This was my mistake. I have not given the k-path. I
> donot think it is related to any bug. I have given k-mesh. Now Nan is not
> coming.
>
> (2) when some body is doing init_w2w, "*.win" file is automatically
> created. In the *.win file it is selecting hr_plot=true. which should be
> commented out initially.
>
> (3)In UG, in the init_w2w section (quick start), it is written after
> write_win, run wannier90.x. with this you one cannot create *.nnkp file
> which is the aim of the this preliminary run. One should run wannier90.x
> --pp (subdir). then it will create the *.nnkp file.
>
> (4) In the Ug, it is written w2w caes. It should be subdir. Because we are
> doing prepare_w2w  caes subdir.
>
> (5) To get the hr_dat file, you at last uncomment the hr_plot=true and
> make one final run with all the necessary file.
>wannier90.x subdir
>
>
>
> Still I have some doubt about the k-point. I am trying this. But with 2 2
> 2 k-point I am able to generate the hr_dat file.
>
>
> Regards
> wasim
>
>
>
>
>
>
>
>
> On Wed, Jun 12, 2013 at 10:34 PM, wasim raja Mondal <
> wasimr.mon...@gmail.com> wrote:
>
>> Hi oleg
>>Thanks.
>>
>>
>> On Wed, Jun 12, 2013 at 9:35 PM, Oleg Rubel  wrote:
>>
>>> Dear Elias,
>>>
>>> Thank you for the reply.
>>>
>>> Here is one more guess: mixed units in the provided *win
>>>
>>> The following line (begin unit_cell_cart, ang) suggests [Angstr] units,
>>> whereas the numbers are definitely in [Bohr].
>>>
>>> Latter (begin atoms_cart), the atomic positions appear in [A].
>>>
>>>
>>> Thank you
>>> Oleg
>>>
>>> P.S. I am particularly interested in wien2wannier because it works with
>>> BerryPI for polarization calculation. We did not have a problem with BaTiO3
>>> and other perovskite structures. However, I should admit that we stop at
>>> w2w and do not proceed with wannier90.
>>>
>>>
>>>
>>> On 12/06/2013 11:47 AM, Elias Assmann wrote:
>>>
 Dear Oleg,

 On 06/12/2013 04:11 PM, Oleg Rubel wrote:

> I am certainly not an expert in w2w, but I noticed some "NaN" in the
> kpoint_path. This is usually not a good sign. Is it normal?
>

 Good catch, but that cannot explain the error as reported.

 These NaNs are in fact due to a bug in write_win (sorry!).  It will be
 fixed in the next wien2wannier version, until then it is probably best
 to put in the right coordinates by hand.

 In any case, the actual Wannier projection should be independent of
 these NaNs.  I expect them to show up only in the band structure
 (“_band.dat”), but I am not sure exactly how.

  Elias

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

>>> __**_
>>> Wien mailing list
>>> w...@zeus.theochem.tuwien.ac.**at 
>>> http://zeus.theochem.tuw

Re: [Wien] wien2wannier error

[wasim raja Mondal]

Hi oleg

 I solved the problem.  I am first time using this. Thats why I wanted some
help.  correct me if I am wrong. According to me the reason of the errors
are following :

(1) There was NaN . This was my mistake. I have not given the k-path. I
donot think it is related to any bug. I have given k-mesh. Now Nan is not
coming.

(2) when some body is doing init_w2w, "*.win" file is automatically
created. In the *.win file it is selecting hr_plot=true. which should be
commented out initially.

(3)In UG, in the init_w2w section (quick start), it is written after
write_win, run wannier90.x. with this you one cannot create *.nnkp file
which is the aim of the this preliminary run. One should run wannier90.x
--pp (subdir). then it will create the *.nnkp file.

(4) In the Ug, it is written w2w caes. It should be subdir. Because we are
doing prepare_w2w  caes subdir.

(5) To get the hr_dat file, you at last uncomment the hr_plot=true and make
one final run with all the necessary file.
   wannier90.x subdir



Still I have some doubt about the k-point. I am trying this. But with 2 2 2
k-point I am able to generate the hr_dat file.


Regards
wasim








On Wed, Jun 12, 2013 at 10:34 PM, wasim raja Mondal  wrote:

> Hi oleg
>Thanks.
>
>
> On Wed, Jun 12, 2013 at 9:35 PM, Oleg Rubel  wrote:
>
>> Dear Elias,
>>
>> Thank you for the reply.
>>
>> Here is one more guess: mixed units in the provided *win
>>
>> The following line (begin unit_cell_cart, ang) suggests [Angstr] units,
>> whereas the numbers are definitely in [Bohr].
>>
>> Latter (begin atoms_cart), the atomic positions appear in [A].
>>
>>
>> Thank you
>> Oleg
>>
>> P.S. I am particularly interested in wien2wannier because it works with
>> BerryPI for polarization calculation. We did not have a problem with BaTiO3
>> and other perovskite structures. However, I should admit that we stop at
>> w2w and do not proceed with wannier90.
>>
>>
>>
>> On 12/06/2013 11:47 AM, Elias Assmann wrote:
>>
>>> Dear Oleg,
>>>
>>> On 06/12/2013 04:11 PM, Oleg Rubel wrote:
>>>
 I am certainly not an expert in w2w, but I noticed some "NaN" in the
 kpoint_path. This is usually not a good sign. Is it normal?

>>>
>>> Good catch, but that cannot explain the error as reported.
>>>
>>> These NaNs are in fact due to a bug in write_win (sorry!).  It will be
>>> fixed in the next wien2wannier version, until then it is probably best
>>> to put in the right coordinates by hand.
>>>
>>> In any case, the actual Wannier projection should be independent of
>>> these NaNs.  I expect them to show up only in the band structure
>>> (“_band.dat”), but I am not sure exactly how.
>>>
>>>  Elias
>>>
>>> __**_
>>> Wien mailing list
>>> w...@zeus.theochem.tuwien.ac.**at 
>>> http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wien
>>> SEARCH the MAILING-LIST at:
>>> http://www.mail-archive.com/**w...@zeus.theochem.tuwien.ac.**
>>> at/index.html
>>>
>> __**_
>> Wien mailing list
>> w...@zeus.theochem.tuwien.ac.**at 
>> http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wien
>> SEARCH the MAILING-LIST at:  http://www.mail-archive.com/**
>> w...@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] wien2wannier error

[wasim raja Mondal]

Hi oleg
   Thanks.


On Wed, Jun 12, 2013 at 9:35 PM, Oleg Rubel  wrote:

> Dear Elias,
>
> Thank you for the reply.
>
> Here is one more guess: mixed units in the provided *win
>
> The following line (begin unit_cell_cart, ang) suggests [Angstr] units,
> whereas the numbers are definitely in [Bohr].
>
> Latter (begin atoms_cart), the atomic positions appear in [A].
>
>
> Thank you
> Oleg
>
> P.S. I am particularly interested in wien2wannier because it works with
> BerryPI for polarization calculation. We did not have a problem with BaTiO3
> and other perovskite structures. However, I should admit that we stop at
> w2w and do not proceed with wannier90.
>
>
>
> On 12/06/2013 11:47 AM, Elias Assmann wrote:
>
>> Dear Oleg,
>>
>> On 06/12/2013 04:11 PM, Oleg Rubel wrote:
>>
>>> I am certainly not an expert in w2w, but I noticed some "NaN" in the
>>> kpoint_path. This is usually not a good sign. Is it normal?
>>>
>>
>> Good catch, but that cannot explain the error as reported.
>>
>> These NaNs are in fact due to a bug in write_win (sorry!).  It will be
>> fixed in the next wien2wannier version, until then it is probably best
>> to put in the right coordinates by hand.
>>
>> In any case, the actual Wannier projection should be independent of
>> these NaNs.  I expect them to show up only in the band structure
>> (“_band.dat”), but I am not sure exactly how.
>>
>>  Elias
>>
>> __**_
>> Wien mailing list
>> w...@zeus.theochem.tuwien.ac.**at 
>> http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wien
>> SEARCH the MAILING-LIST at:
>> http://www.mail-archive.com/**w...@zeus.theochem.tuwien.ac.**
>> at/index.html
>>
> __**_
> Wien mailing list
> w...@zeus.theochem.tuwien.ac.**at 
> http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:  http://www.mail-archive.com/**
> w...@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] wien2wannier error

[Oleg Rubel]

Dear Elias,

Thank you for the reply.

Here is one more guess: mixed units in the provided *win

The following line (begin unit_cell_cart, ang) suggests [Angstr] units, 
whereas the numbers are definitely in [Bohr].


Latter (begin atoms_cart), the atomic positions appear in [A].


Thank you
Oleg

P.S. I am particularly interested in wien2wannier because it works with 
BerryPI for polarization calculation. We did not have a problem with 
BaTiO3 and other perovskite structures. However, I should admit that we 
stop at w2w and do not proceed with wannier90.



On 12/06/2013 11:47 AM, Elias Assmann wrote:

Dear Oleg,

On 06/12/2013 04:11 PM, Oleg Rubel wrote:

I am certainly not an expert in w2w, but I noticed some "NaN" in the
kpoint_path. This is usually not a good sign. Is it normal?


Good catch, but that cannot explain the error as reported.

These NaNs are in fact due to a bug in write_win (sorry!).  It will be
fixed in the next wien2wannier version, until then it is probably best
to put in the right coordinates by hand.

In any case, the actual Wannier projection should be independent of
these NaNs.  I expect them to show up only in the band structure
(“_band.dat”), but I am not sure exactly how.

 Elias

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

[Elias Assmann]

Dear Oleg,

On 06/12/2013 04:11 PM, Oleg Rubel wrote:

I am certainly not an expert in w2w, but I noticed some "NaN" in the
kpoint_path. This is usually not a good sign. Is it normal?


Good catch, but that cannot explain the error as reported.

These NaNs are in fact due to a bug in write_win (sorry!).  It will be 
fixed in the next wien2wannier version, until then it is probably best 
to put in the right coordinates by hand.


In any case, the actual Wannier projection should be independent of 
these NaNs.  I expect them to show up only in the band structure 
(“_band.dat”), but I am not sure exactly how.


Elias

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

[wasim raja Mondal]

Hi Rubel

Thanks for your support. I am trying. If I will get success I will let know.

Regards
wasim


On Wed, Jun 12, 2013 at 7:41 PM, Oleg Rubel  wrote:

> I am certainly not an expert in w2w, but I noticed some "NaN" in the
> kpoint_path. This is usually not a good sign. Is it normal?
>
> Oleg
>
>
> On 12/06/2013 6:09 AM, wasim raja Mondal wrote:
>
>> Dear experts
>>
>>I have written wien2wannier mail. But I didnot get any reply. So
>> I am writting wien2k mailing list. I am using wien2wannier for BaTiO3. I
>> want to construct 9 wannier function for 3 O p orbital. I am getting the
>> following error:
>>
>>   Wannier90: Execution started on 12Jun2013 at 20:46:02
>>   Exiting...
>>   No subdir.eig file found. Needed for interpolation
>>
>> Below I am giving the win file.
>>
>> iprint = 3
>>   num_bands   =   9
>>   num_wann=   9
>>   num_iter= 1000
>>   num_print_cycles =100
>>   !conv_window = 20
>>   !conv_tol = 0.0001
>>   !conv_noise_amp = 1
>>   !conv_noise_num = 3
>>
>>   !dis_froz_min = 7.
>>   !dis_froz_max = 9.
>>   dis_mix_ratio   = 0.5
>>   write_proj = .true.
>>   write_xyz = .true.
>>   translate_home_cell = .true.
>>
>>   !SYSTEM
>>
>>   begin unit_cell_cart
>>   ang
>> 7.5674680   0.000   0.000
>> 0.000   7.5674680   0.000
>> 0.000   0.000   7.5674680
>>   end unit_cell_cart
>>
>>   begin atoms_cart
>> Ba  0.0  0.0  0.0
>> Ti  2.00227  2.00227  2.00227
>> O   2.00227  0.0  2.00227
>> O   0.0  2.00227  2.00227
>> O   2.00227  2.00227  0.0
>>   end atoms_cart
>>
>>   begin projections
>>   end projections
>>   begin kpoint_path
>>R  0.50   NaN   NaN LAM  0.28  0.28  0.28
>> LAM  0.28  0.28  0.28 GAM  0.00  0.00  0.00
>> GAM  0.00  0.00  0.00 DEL  0.25  0.00  0.00
>> DEL  0.25  0.00  0.00   X  0.50  0.00  0.00
>>X  0.50  0.00  0.00   Z  0.50  0.25  0.00
>>Z  0.50  0.25  0.00   M  0.50  0.50  0.00
>>M  0.50  0.50  0.00 SIG  0.25  0.25  0.00
>> SIG  0.25  0.25  0.00 GAM  0.00  0.00  0.00
>> GAM  0.00  0.00  0.00 END   NaN   NaN   NaN
>>   end kpoint_path
>>
>>   bands_plot = .true.
>>   bands_num_points  =  9
>>   !bands_plot_mode = cut
>>   !bands_plot_project = 1
>> ! wannier_plot = .false.
>>   !restart = plot
>> ! hr_plot = .true.
>>   !dist_cutoff = 10
>>
>>   kmesh_tol = 0.0001
>>
>>   ! KPOINTS
>>
>>   mp_grid :4   4   4
>>
>>   begin kpoints
>>0.0  0.0  0.0
>>0.0  0.0  0.25000
>>0.0  0.0  0.5
>>0.0  0.25000  0.25000
>>0.0  0.25000  0.5
>>0.0  0.5  0.5
>>0.25000  0.25000  0.25000
>>0.25000  0.25000  0.5
>>0.25000  0.5  0.5
>>0.5  0.5  0.5
>>   end kpoints
>>
>>
>>
>>
>> __**_
>> Wien mailing list
>> w...@zeus.theochem.tuwien.ac.**at 
>> http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wien
>> SEARCH the MAILING-LIST at:  http://www.mail-archive.com/**
>> w...@zeus.theochem.tuwien.ac.**at/index.html
>>
>>  __**_
> Wien mailing list
> w...@zeus.theochem.tuwien.ac.**at 
> http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:  http://www.mail-archive.com/**
> w...@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] wien2wannier error

[Oleg Rubel]

I am certainly not an expert in w2w, but I noticed some "NaN" in the 
kpoint_path. This is usually not a good sign. Is it normal?


Oleg

On 12/06/2013 6:09 AM, wasim raja Mondal wrote:

Dear experts

   I have written wien2wannier mail. But I didnot get any reply. So
I am writting wien2k mailing list. I am using wien2wannier for BaTiO3. I
want to construct 9 wannier function for 3 O p orbital. I am getting the
following error:

  Wannier90: Execution started on 12Jun2013 at 20:46:02
  Exiting...
  No subdir.eig file found. Needed for interpolation

Below I am giving the win file.

iprint = 3
  num_bands   =   9
  num_wann=   9
  num_iter= 1000
  num_print_cycles =100
  !conv_window = 20
  !conv_tol = 0.0001
  !conv_noise_amp = 1
  !conv_noise_num = 3

  !dis_froz_min = 7.
  !dis_froz_max = 9.
  dis_mix_ratio   = 0.5
  write_proj = .true.
  write_xyz = .true.
  translate_home_cell = .true.

  !SYSTEM

  begin unit_cell_cart
  ang
7.5674680   0.000   0.000
0.000   7.5674680   0.000
0.000   0.000   7.5674680
  end unit_cell_cart

  begin atoms_cart
Ba  0.0  0.0  0.0
Ti  2.00227  2.00227  2.00227
O   2.00227  0.0  2.00227
O   0.0  2.00227  2.00227
O   2.00227  2.00227  0.0
  end atoms_cart

  begin projections
  end projections
  begin kpoint_path
   R  0.50   NaN   NaN LAM  0.28  0.28  0.28
LAM  0.28  0.28  0.28 GAM  0.00  0.00  0.00
GAM  0.00  0.00  0.00 DEL  0.25  0.00  0.00
DEL  0.25  0.00  0.00   X  0.50  0.00  0.00
   X  0.50  0.00  0.00   Z  0.50  0.25  0.00
   Z  0.50  0.25  0.00   M  0.50  0.50  0.00
   M  0.50  0.50  0.00 SIG  0.25  0.25  0.00
SIG  0.25  0.25  0.00 GAM  0.00  0.00  0.00
GAM  0.00  0.00  0.00 END   NaN   NaN   NaN
  end kpoint_path

  bands_plot = .true.
  bands_num_points  =  9
  !bands_plot_mode = cut
  !bands_plot_project = 1
! wannier_plot = .false.
  !restart = plot
! hr_plot = .true.
  !dist_cutoff = 10

  kmesh_tol = 0.0001

  ! KPOINTS

  mp_grid :4   4   4

  begin kpoints
   0.0  0.0  0.0
   0.0  0.0  0.25000
   0.0  0.0  0.5
   0.0  0.25000  0.25000
   0.0  0.25000  0.5
   0.0  0.5  0.5
   0.25000  0.25000  0.25000
   0.25000  0.25000  0.5
   0.25000  0.5  0.5
   0.5  0.5  0.5
  end kpoints




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

[Oleg Rubel]

I am certainly not an expert in w2w, but I noticed some "NaN" in the 
kpoint_path. This is usually not a good sign. Is it normal?


Oleg

On 12/06/2013 6:09 AM, wasim raja Mondal wrote:

Dear experts

   I have written wien2wannier mail. But I didnot get any reply. So
I am writting wien2k mailing list. I am using wien2wannier for BaTiO3. I
want to construct 9 wannier function for 3 O p orbital. I am getting the
following error:

  Wannier90: Execution started on 12Jun2013 at 20:46:02
  Exiting...
  No subdir.eig file found. Needed for interpolation

Below I am giving the win file.

iprint = 3
  num_bands   =   9
  num_wann=   9
  num_iter= 1000
  num_print_cycles =100
  !conv_window = 20
  !conv_tol = 0.0001
  !conv_noise_amp = 1
  !conv_noise_num = 3

  !dis_froz_min = 7.
  !dis_froz_max = 9.
  dis_mix_ratio   = 0.5
  write_proj = .true.
  write_xyz = .true.
  translate_home_cell = .true.

  !SYSTEM

  begin unit_cell_cart
  ang
7.5674680   0.000   0.000
0.000   7.5674680   0.000
0.000   0.000   7.5674680
  end unit_cell_cart

  begin atoms_cart
Ba  0.0  0.0  0.0
Ti  2.00227  2.00227  2.00227
O   2.00227  0.0  2.00227
O   0.0  2.00227  2.00227
O   2.00227  2.00227  0.0
  end atoms_cart

  begin projections
  end projections
  begin kpoint_path
   R  0.50   NaN   NaN LAM  0.28  0.28  0.28
LAM  0.28  0.28  0.28 GAM  0.00  0.00  0.00
GAM  0.00  0.00  0.00 DEL  0.25  0.00  0.00
DEL  0.25  0.00  0.00   X  0.50  0.00  0.00
   X  0.50  0.00  0.00   Z  0.50  0.25  0.00
   Z  0.50  0.25  0.00   M  0.50  0.50  0.00
   M  0.50  0.50  0.00 SIG  0.25  0.25  0.00
SIG  0.25  0.25  0.00 GAM  0.00  0.00  0.00
GAM  0.00  0.00  0.00 END   NaN   NaN   NaN
  end kpoint_path

  bands_plot = .true.
  bands_num_points  =  9
  !bands_plot_mode = cut
  !bands_plot_project = 1
! wannier_plot = .false.
  !restart = plot
! hr_plot = .true.
  !dist_cutoff = 10

  kmesh_tol = 0.0001

  ! KPOINTS

  mp_grid :4   4   4

  begin kpoints
   0.0  0.0  0.0
   0.0  0.0  0.25000
   0.0  0.0  0.5
   0.0  0.25000  0.25000
   0.0  0.25000  0.5
   0.0  0.5  0.5
   0.25000  0.25000  0.25000
   0.25000  0.25000  0.5
   0.25000  0.5  0.5
   0.5  0.5  0.5
  end kpoints




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



--
Oleg Rubel, PhD
Scientist, Thunder Bay Regional Research Institute
Adjunct Professor, Dept Physics, Lakehead University
290 Munro St, Thunder Bay, P7A 7T1, Ontario, Canada
Phone: +1-807-7663350
Fax: +1-807-3441948
E-mail: oru...@lakeheadu.ca
Homepage: http://www.tbrri.com/~orubel/
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier error

[Elias Assmann]

Dear Wasim,

On 06/12/2013 12:09 PM, wasim raja Mondal wrote:

   I have written wien2wannier mail. But I didnot get any reply. So


It is surely not my place to dispense personal advice, but ... Maybe you 
should be a little more patient?  You wrote me two e-mails *yesterday* 
to  (yes, it is just me behind that 
address, just a lowly grad student).



I am writting wien2k mailing list. I am using wien2wannier for BaTiO3. I
want to construct 9 wannier function for 3 O p orbital. I am getting the
following error:

  Wannier90: Execution started on 12Jun2013 at 20:46:02
  Exiting...
  No subdir.eig file found. Needed for interpolation


Asking good questions is a skill. [1]  Since you no longer talk about 
the problem you mentioned in the personal e-mails, I am going to assume 
you solved that one on your own.


Now, all I can tell you about the error you are seeing is that the 
“.eig” file should be created by “w2w”, so obviously something went 
wrong at that step or before.



Below I am giving the win file.


Unfortunately that does not help me help you.


Elias


[1] 
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] wien2wannier error

[wasim raja Mondal]

Dear experts

  I have written wien2wannier mail. But I didnot get any reply. So I am
writting wien2k mailing list. I am using wien2wannier for BaTiO3. I want to
construct 9 wannier function for 3 O p orbital. I am getting the following
error:

 Wannier90: Execution started on 12Jun2013 at 20:46:02
 Exiting...
 No subdir.eig file found. Needed for interpolation

Below I am giving the win file.

iprint = 3
 num_bands   =   9
 num_wann=   9
 num_iter= 1000
 num_print_cycles =100
 !conv_window = 20
 !conv_tol = 0.0001
 !conv_noise_amp = 1
 !conv_noise_num = 3

 !dis_froz_min = 7.
 !dis_froz_max = 9.
 dis_mix_ratio   = 0.5
 write_proj = .true.
 write_xyz = .true.
 translate_home_cell = .true.

 !SYSTEM

 begin unit_cell_cart
 ang
   7.5674680   0.000   0.000
   0.000   7.5674680   0.000
   0.000   0.000   7.5674680
 end unit_cell_cart

 begin atoms_cart
Ba  0.0  0.0  0.0
Ti  2.00227  2.00227  2.00227
O   2.00227  0.0  2.00227
O   0.0  2.00227  2.00227
O   2.00227  2.00227  0.0
 end atoms_cart

 begin projections
 end projections
 begin kpoint_path
  R  0.50   NaN   NaN LAM  0.28  0.28  0.28
LAM  0.28  0.28  0.28 GAM  0.00  0.00  0.00
GAM  0.00  0.00  0.00 DEL  0.25  0.00  0.00
DEL  0.25  0.00  0.00   X  0.50  0.00  0.00
  X  0.50  0.00  0.00   Z  0.50  0.25  0.00
  Z  0.50  0.25  0.00   M  0.50  0.50  0.00
  M  0.50  0.50  0.00 SIG  0.25  0.25  0.00
SIG  0.25  0.25  0.00 GAM  0.00  0.00  0.00
GAM  0.00  0.00  0.00 END   NaN   NaN   NaN
 end kpoint_path

 bands_plot = .true.
 bands_num_points  =  9
 !bands_plot_mode = cut
 !bands_plot_project = 1
! wannier_plot = .false.
 !restart = plot
! hr_plot = .true.
 !dist_cutoff = 10

 kmesh_tol = 0.0001

 ! KPOINTS

 mp_grid :4   4   4

 begin kpoints
  0.0  0.0  0.0
  0.0  0.0  0.25000
  0.0  0.0  0.5
  0.0  0.25000  0.25000
  0.0  0.25000  0.5
  0.0  0.5  0.5
  0.25000  0.25000  0.25000
  0.25000  0.25000  0.5
  0.25000  0.5  0.5
  0.5  0.5  0.5
 end kpoints
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] WIEN2WANNIER

[Peter Blaha]

Dear wien2k users,

I'm glad to announce a new package in the family of wien2k utility programs:

WIEN2WANNIER from J.Kunes and P.Wissgott

Its capability is to prepare the input files for wannier90, a program to
produce maximally localized Wannier functions.

Some features you can access (starting from a standard wien2k computation):
1) compute hopping parameters from one Wannier orbital to the other
(e.g. for tight-binding models)
2) plot Wannier orbitals conveniently with xcrysden
3) produce the Hamiltonian in the Wannier basis(e.g. for DMFT calculations)
4) fat-band plots in the basis of Wannier orbitals
5) compute Wannier functions for spin-polarized, spin-orbit and LDA+U
calculations(or combinations thereof)
6) use other wannier90 functionalities, such as producing bandstructures
for different hopping cut-offs in real space

The workflow wien2k->wien2wannier->wannier90 is simplified by utility
scripts and a userguide which are included in the download from

http://www.wien2k.at/reg_user/unsupported/wien2wannier/


For a detailed description please take a look at

J. KUNES , R. ARITA , P. WISSGOTT, A.TOSCHI , H. IKEDA , K. HELD
Wien2wannier: From linearized augmented plane waves to maximally
localized Wannier functions,
Comp. Phys. Commun. 181, 1888 (2010).

Please report bugs, anomalies or remarks.

Best regards,

Philipp Wissgott
Institute for Solid State Physics, TU Vienna
email: wissgott at ifp.tuwien.ac.at