Re: [Wien] Segmentation fault in w2w

[Niraj Aryal]

Dear all,

Thank you all for your suggestions and for guiding me to the right
directions.
I was able to solve the problem of segmentation fault in w2w.
It seems like this problem is not reproducible in all the platforms as
verified by Prof. Rubel.

If you encounter such a problem, please apply the following patch for
modules_rc.F file located in the SRC_w2w directory:

434c434,435
<   complex(C16) :: projection(inwf%bmax-inwf%bmin+1, inwf%Nproj, num_kpts)
---
>   ! making the projection array dynamic solved the seg fault
>   complex(C16), allocatable :: projection(:,:,:)
448a450,452
>
>   allocate(projection(Nb,inwf%Nproj, num_kpts))
>
661a666,668
>   !deallocate projection array
>   deallocate(projection)
>

i.e. please make the projection array dynamic.

Thank you.

Sincerely,
Niraj Aryal
Research Associate
Brookhaven National Lab.
Upton, NY



On Sat, Sep 12, 2020 at 5:15 PM Laurence Marks 
wrote:

> ...please add -g ... (not -f, a typo).
>
> On Sat, Sep 12, 2020 at 11:26 AM Laurence Marks 
> wrote:
>
>> Is this compiled with -g ? If not, please add -f, recompile and then
>> repeat. (The reason is that optimizations can lead to segmentation faults
>> appearing at an inappropriate location in the code.) If with -g it is still
>> the same, please add before line 449 of  modules_rc.F a write command, i.e.
>> so it has:
>>
>>   Nb = inwf%bmax-inwf%bmin+1
>>   write(*,*) Nb, inwf%Nproj, num_kpts
>>   projection = 0
>>
>> I suspect that num_kpts is wrong, so the dimensions of projection are
>> incorrect. However, segmentation errors can be hard to locate.
>>
>> On Sat, Sep 12, 2020 at 10:20 AM Niraj Aryal 
>> wrote:
>>
>>> Thank you all for your suggestions.
>>> I tried your suggestions but so far, the problem remains.
>>>
>>> As per Prof. Rubel's request, I will share with you my struct file
>>> privately along with the steps. Please watch out for my email (
>>> aryalnir...@gmail.com).
>>> To simplify, I was able to reproduce the problem for paramagnetic case
>>> without spin orbit case.
>>>
>>> Prof. Marks, I have -traceback option in my compilation.
>>> These are the line numbers where the seg fault occurs:
>>>
>>> w2w00432427  l2amn_m_mp_l2amn_ 449
>>>  modules_rc.F
>>> w2w0042D68E  MAIN__245
>>>  main.f
>>>
>>> This made me believe that the problem is in modules_rc.F file in the amn
>>> routine.
>>>
>>> Thank you for the patch link Gavin.
>>> I applied modules_rc.patch but the problem persists.
>>>
>>> I will continue trying to solve this problem. I will keep you updated if
>>> something new comes up.
>>> I look forward to your suggestions and feedback.
>>>
>>> Sincerely,
>>> Niraj Aryal
>>>
>>> On Fri, Sep 11, 2020 at 8:08 PM Gavin Abo  wrote:
>>>
>>>> Not sure if it is related, but are you using the w2w fix that Jindrich
>>>> previously posted for WIEN2k 19.2 [
>>>> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg19849.html
>>>> <https://urldefense.com/v3/__https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg19849.html__;!!Dq0X2DkFhyF93HkjWTBQKhk!FFIAVc_c4ngUm39TDyFbeI-PXrGkFarvmCfJ7574Kmic-1Y7CJ5QmYsaGUcau_4RW9V9_w$>
>>>> ] .  Or modules_rc.patch and modules_rc_wplot.patch related to w2web if you
>>>> prefer to try them are at:
>>>>
>>>> https://github.com/gsabo/WIEN2k-Patches/tree/master/19.2
>>>> <https://urldefense.com/v3/__https://github.com/gsabo/WIEN2k-Patches/tree/master/19.2__;!!Dq0X2DkFhyF93HkjWTBQKhk!FFIAVc_c4ngUm39TDyFbeI-PXrGkFarvmCfJ7574Kmic-1Y7CJ5QmYsaGUcau_5C93rS3g$>
>>>> On 9/11/2020 12:02 PM, Niraj Aryal wrote:
>>>>
>>>> Dear w2w experts and developers,
>>>>
>>>> I am using Wien2k version 19.2 in scientific linux 7.5 using intel
>>>> compilers (2018).
>>>>
>>>> I am trying to wannierize f-electron system with antiferromagnetic
>>>> magnetic ordering using w2w version 2.0 in the presence of SOC.
>>>>
>>>> After self-consistent calculations, these are the steps I am following
>>>> for the wannierisation:
>>>>
>>>> init_w2w (to write case.klist, case.inwf, case.win etc)
>>>>
>>>>  x lapw1 -up -p
>>>>  x lapw1 -dn -p
>>>>  x lapwso -up -orb -p
>>>>
>>>> x w2w -so -up -p  --> segmentation fault here
>>

Re: [Wien] Segmentation fault in w2w

[Niraj Aryal]

Thank you all for your suggestions.
I tried your suggestions but so far, the problem remains.

As per Prof. Rubel's request, I will share with you my struct file
privately along with the steps. Please watch out for my email (
aryalnir...@gmail.com).
To simplify, I was able to reproduce the problem for paramagnetic case
without spin orbit case.

Prof. Marks, I have -traceback option in my compilation.
These are the line numbers where the seg fault occurs:

w2w00432427  l2amn_m_mp_l2amn_ 449
 modules_rc.F
w2w0042D68E  MAIN__245  main.f

This made me believe that the problem is in modules_rc.F file in the amn
routine.

Thank you for the patch link Gavin.
I applied modules_rc.patch but the problem persists.

I will continue trying to solve this problem. I will keep you updated if
something new comes up.
I look forward to your suggestions and feedback.

Sincerely,
Niraj Aryal

On Fri, Sep 11, 2020 at 8:08 PM Gavin Abo  wrote:

> Not sure if it is related, but are you using the w2w fix that Jindrich
> previously posted for WIEN2k 19.2 [
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg19849.html
> ] .  Or modules_rc.patch and modules_rc_wplot.patch related to w2web if you
> prefer to try them are at:
>
> https://github.com/gsabo/WIEN2k-Patches/tree/master/19.2
> On 9/11/2020 12:02 PM, Niraj Aryal wrote:
>
> Dear w2w experts and developers,
>
> I am using Wien2k version 19.2 in scientific linux 7.5 using intel
> compilers (2018).
>
> I am trying to wannierize f-electron system with antiferromagnetic
> magnetic ordering using w2w version 2.0 in the presence of SOC.
>
> After self-consistent calculations, these are the steps I am following for
> the wannierisation:
>
> init_w2w (to write case.klist, case.inwf, case.win etc)
>
>  x lapw1 -up -p
>  x lapw1 -dn -p
>  x lapwso -up -orb -p
>
> x w2w -so -up -p  --> segmentation fault here
> x w2w -so -dn -p  --> segmentation fault here
> ..
>
> Everything works perfectly if I use small kmesh (about 100 kpoints) for
> the wannierisation.
> I have about 50 bands to wannierize.
> When I increase the number of kpoints, w2w crashes giving segmentation
> fault.
>
> I found that w2w can write case.mmn and case.eig with no problems but the
> seg fault occurred while writing case.amn.
> I confirmed the following hoping that it could help in the debugging
> process:
>
> 1) If I decrease the number of bands to wannierize, the number of kpoints
> in the wannierisation can be slightly increased without seg fault.
> 2)The problem persists without -so and -p (i.e. without parallel
> calculation) flag.
>
> In my opinion, there are some hard coded array size value(s) in the w2w
> program in amn/mmn subroutines which give segmentation fault when the
> number of projections*bands*kpoints exceeds that value.
> This was confirmed by doing calculations in a simpler system like silicon
> with a large number of kpoints and bands.
>
> I tried looking into the w2w source files and found few hard coded values.
> However, I am hesitant to make changes because I am worried this could
> ruin other things.
>
> This problem is similar to the one posted last year:
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18896.html
> which was not solved.
> I would greatly appreciate your suggestion/feedback regarding this
> problem.
> You could also guide me to the right subroutines if you know the details
> of the code.
>
> Thank you.
>
> Sincerely,
> Niraj Aryal
> Research Associate
> Brookhaven National Lab.
> Upton, NY
>
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> http://zeus.theochem.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] Segmentation fault in w2w

[Niraj Aryal]

Dear w2w experts and developers,

I am using Wien2k version 19.2 in scientific linux 7.5 using intel
compilers (2018).

I am trying to wannierize f-electron system with antiferromagnetic magnetic
ordering using w2w version 2.0 in the presence of SOC.

After self-consistent calculations, these are the steps I am following for
the wannierisation:

init_w2w (to write case.klist, case.inwf, case.win etc)

 x lapw1 -up -p
 x lapw1 -dn -p
 x lapwso -up -orb -p

x w2w -so -up -p  --> segmentation fault here
x w2w -so -dn -p  --> segmentation fault here
..

Everything works perfectly if I use small kmesh (about 100 kpoints) for the
wannierisation.
I have about 50 bands to wannierize.
When I increase the number of kpoints, w2w crashes giving segmentation
fault.

I found that w2w can write case.mmn and case.eig with no problems but the
seg fault occurred while writing case.amn.
I confirmed the following hoping that it could help in the debugging
process:

1) If I decrease the number of bands to wannierize, the number of kpoints
in the wannierisation can be slightly increased without seg fault.
2)The problem persists without -so and -p (i.e. without parallel
calculation) flag.

In my opinion, there are some hard coded array size value(s) in the w2w
program in amn/mmn subroutines which give segmentation fault when the
number of projections*bands*kpoints exceeds that value.
This was confirmed by doing calculations in a simpler system like silicon
with a large number of kpoints and bands.

I tried looking into the w2w source files and found few hard coded values.
However, I am hesitant to make changes because I am worried this could ruin
other things.

This problem is similar to the one posted last year:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18896.html
which was not solved.
I would greatly appreciate your suggestion/feedback regarding this problem.
You could also guide me to the right subroutines if you know the details of
the code.

Thank you.

Sincerely,
Niraj Aryal
Research Associate
Brookhaven National Lab.
Upton, NY
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] Manually generate klist file

[Niraj Aryal]

Dear Maciej
Thank you very much for your swift and simple response and please apologize
me for taking forever to thank you!

On Fri, Jul 1, 2016 at 7:05 PM, Maciej Polak <maciej.po...@pwr.edu.pl>
wrote:

> Dear Niraj,
>
> I don't see a simple way of writing them as decimals. However, you can
> quickly adapt to the integer way of creating klist files. There are simple
> algorithms of converting decimals to fractions (
> http://stackoverflow.com/questions/5124743/algorithm-for-simplifying-decimal-to-fractions)
> and even simpler ones to later find the least common multiple (
> http://stackoverflow.com/questions/3154454/what-is-the-most-efficient-way-to-calculate-the-least-common-multiple-of-two-int)
> of the three denominators. The fourth number (the common denominator) can
> be different in each line, it doesn't matter as long as the first three
> numbers divided by the fourth give you your fractional coordinates.
>
> A short script/program will create a perfect klist file for you, it
> shouldn't take long to write one that suits your exact needs.
> As far as I remember klists are fixed format (in bash awk (C would be
> similar) I use something like:
> *printf("%15d%5d%5d%5d%5.1f\n",$x,$y,$z,$common,2.0)*) so keep that in
> mind, and don't forget to put "END" at the end.
>
> Best regards
>
> Maciej Polak
>
>
>
>
>
> On 07/02/2016 12:37 AM, Niraj Aryal wrote:
>
> Dear Wien2k experts
> After successful completion of scf calculation, I would like to find eigen
> values and eigen vectors using dense kmesh only in a small region of
> Brillouin Zone where interesting physics is happenning. I plan to use this
> information to get band structure, fermi surface etc around this region
> which saves a lot of time instead of sampling the whole BZ.  So I am
> wondering if I can make case.klist file by hand to sample only the region
> of interest. However, I found that the kpoints in case.klist file should be
> written as integer and a common divisor which is a pain and even after
> doing so, I don't get exact k-point I want when I confirm by looking at the
> fractional kpoint value (in terms of reciprocal lattice) printed in
> case.energy file. And this is also not a displacement by reciprocal lattice
> vector. So obviously, I don't understand what's going on.
>
> So, my question is:
> Is there a way to make lapw1 take klist expressed as  just 3 number e.g
> (0.021,0.7,0.4)  in the units of reciprocal lattice vectors so that I don't
> have to go through the process of writing in terms of integers and common
> divisor?
>
> Thank you for going through my query. I would appreciate any feedback from
> the community.
>
>
> --
> With regards
>
> Niraj Aryal
> Grad. Student
> Florida State University
> Tallahassee, Florida-32304
>
>
>
> ___
> Wien mailing 
> listw...@zeus.theochem.tuwien.ac.athttp://zeus.theochem.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
>
>


-- 
With regards

Niraj Aryal
Grad. Student
Florida State University
Tallahassee, Florida-32304
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] Error in wien2wannier for spin orbit coupling case

[Niraj Aryal]

Sorry, somehow I did not get the error again. I must have done something
stupid before. I am using intel compiler version 2016.1.150.

However, there is something serious thing I am encountering. When I do
wannier90 calculation after finding case.mmn, case.amn and case.eig (up and
down spins are added using w2waddsp), it gives me negative spread for Omega
I e.g:

 Spreads (Ang^2)   Omega I  = -2549.235637370
   Omega D  =  1558.555122007
   Omega OD =  3178.612948567
Final Spread (Ang^2)   Omega Total  =  2187.932433204

But we know that the spread has to be positive because it is expectation
value of (r- )^2 . I found similar post here:
http://mailman.qe-forge.org/pipermail/wannier/2008-September/000199.html

Since Omega I is only calculated from the case.mmn file, I suspect that
there is some problem in doing so.

I am attaching input file. You are welcome to try this.



On Mon, Jul 4, 2016 at 11:38 AM, Elias Assmann <elias.assm...@gmail.com>
wrote:

> Dear Niraj,
>
> On 07/02/2016 02:57 AM, Niraj Aryal wrote:
> > Thank you Elias. The newer version of w2w ran without giving any
> > errors for test case. I will do more tests and let you know.
>
> Good to hear, and thank you for reporting the compilation error.
>
> > For this, I used the executables from the old SRC_trig directory and
> > they work fine with the new w2w executable.
>
> This should pose no problems, except that there have been some
> bugfixes in write_win_backend.
>
> > write_win_backend.f(292): error #6460: This is not a field name that
> > is defined in the encompassing structure.
>
> L. 292 is the empty line after
>
> do i=1,inwf%Nproj
>print fmt_centers, centers(i)
> end do
>
> I can only assume that the error refers to inwf%Nproj.  This is a bit
> odd because this and other fields of the same structure are used
> throughout that file.  Are there any other errors?  What compiler and
> version are you using?
>
> Also, can you make sure that write_inwf_backend.f is compiled against
> the new util_w2w.F?  For instance, compile it in the wien2wannier
> source directory rather than the Wien2k one (“cd
> wien2wannier/SRC_trig; make write_win_backend”).
>
>
> Elias
>
> --
> Elias Assmann
> Institute of Theoretical and Computational Physics
> TU Graz   <https://itp.tugraz.at/>
>
>
>
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>
>


-- 
With regards

Niraj Aryal
Grad. Student
Florida State University
Tallahassee, Florida-32304


Zr2Te2P.struct_orig
Description: Binary 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] Error in wien2wannier for spin orbit coupling case

[Niraj Aryal]

Thank you Elias. The newer version of w2w ran without giving any errors for
test case. I will do more tests and let you know.

However, the compilation of executables in SRC_trig directory gave
problems. This gives me error like:

write_win_backend.f(292): error #6460: This is not a field name that is
defined in the encompassing structure.

For this, I used the executables from the old SRC_trig directory and they
work fine with the new w2w executable.

Thank you again!

On Fri, Jul 1, 2016 at 8:58 AM, Elias Assmann <elias.assm...@gmail.com>
wrote:

> Dear Niraj,
>
> On 06/30/2016 08:04 PM, Niraj Aryal wrote:
> > Dear Elias
> > Thank you for your reply.
> > This is full error message I get when I run x w2w -up -so -p
> >
> > forrtl: severe (39): error during read, unit 9, file
> > /home/aryal/work_wein2k/lapw/Zr2Te2P/wannier/./wannier.vectorsoup_1
> > Image  PCRoutineLine
> > Source
> > w2wc   0043CB33  Unknown   Unknown
> Unknown
> > w2wc   00465A44  Unknown   Unknown
> Unknown
> > w2wc   00429D82  read_vec_  52
> > read_vec.f
> > w2wc   004238FD  MAIN__159
> main.f
> > w2wc   00403B9E  Unknown   Unknown
> Unknown
> > libc.so.6  0037F501ED5D  Unknown   Unknown
> Unknown
> > w2wc   00403AA9  Unknown   Unknown
> Unknown
> > 0.042u 0.037s 0:00.09 77.7%0+0k 24+32io 0pf+0w
>
> This looks a lot like the error reported recently by Wen Fong Goh on the
> mailing list and here
> <https://github.com/wien2wannier/wien2wannier/issues/10> (as well as by
> others), although this observation:
>
> > However, the program runs smoothly in serial version!
>
> does not fit.
>
> So also in your case, I would advise you to try the latest development
> version.  If you send me your struct file and relevant parameters, I can
> also try it out, if the calculation is not too large.
>
> > Also as I said here:
> >
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14497.html
> ,
> >  I get no error at all when I consider bands starting from band index 1!
>
> Oops, I missed that message.  (In the interest of “netiquette”, if you
> find more information related to a previous e-mail, it is usually better
> to reply to that e-mail rather than starting a new thread.)
>
>
> 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
>
>


-- 
With regards

Niraj Aryal
Grad. Student
Florida State University
Tallahassee, Florida-32304
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] Error in wien2wannier for spin orbit coupling case

[Niraj Aryal]

Thank you for taking part in this discussion Wasim.
No I have not changed symmetry operation to 1.
On Jul 1, 2016 6:50 AM, "Elias Assmann"  wrote:

> On 07/01/2016 07:33 AM, wasim raja Mondal wrote:
> >   Have you change symmetry operation 1 before running
> init_w2w?
>
> Why would you do that?
>
>
>
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> http://zeus.theochem.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] Error in wien2wannier for spin orbit coupling case

[Niraj Aryal]

Dear Elias
Thank you for your reply.
This is full error message I get when I run x w2w -up -so -p

forrtl: severe (39): error during read, unit 9, file
/home/aryal/work_wein2k/lapw/Zr2Te2P/wannier/./wannier.vectorsoup_1
Image  PCRoutineLine
Source
w2wc   0043CB33  Unknown   Unknown  Unknown
w2wc   00465A44  Unknown   Unknown  Unknown
w2wc   00429D82  read_vec_  52
read_vec.f
w2wc   004238FD  MAIN__159  main.f
w2wc   00403B9E  Unknown   Unknown  Unknown
libc.so.6  0037F501ED5D  Unknown   Unknown  Unknown
w2wc   00403AA9  Unknown   Unknown  Unknown
0.042u 0.037s 0:00.09 77.7%0+0k 24+32io 0pf+0w


However, the program runs smoothly in serial version!

Also as I said here:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14497.html ,
 I get no error at all when I consider bands starting from band index 1!



On Wed, Jun 29, 2016 at 12:02 PM, Elias Assmann <elias.assm...@gmail.com>
wrote:

> Dear Niraj Aryal,
>
> Sorry for the delayed reply.  I will give my two Euro cents on your
> report below.  If you have solved the problem in the meantime, please
> tell us what it was.
>
> On 06/15/2016 06:37 AM, Niraj Aryal wrote:
> > The crystal I am working is Zr2Te2P which has rhombohedral lattice
> > structure and has inversion symmetry. First I performed spin polarized
> > with spin orbit coupling DFT calculation and as per the direction in the
> > manual of w2w, I performed following steps:
> >
> >  ->prepare_w2wdir dft_dir wannier_dir
> >
> > ->cd wannier_dir ; then init_w2w
> >
> > -> x lapw1 -up -p ; x lapw1 -dn -p
> >
> > -> x lapwso -up -p
> >
> >  -> x w2w -up -so -p
>
> This appears to be correct.
>
> > /forrtl: severe (39): error during read, unit 9, file
> wannier.vectorsoup_1/
>
> This is not a lot of information to go by.  Are there no other messages?
>
> Does the same thing happen in a non-parallelized calculation?  (If
> necessary use fewer k-points, smaller RKmax etc.)
>
>
> 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
>
>


-- 
With regards

Niraj Aryal
Grad. Student
Florida State University
Tallahassee, Florida-32304
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] Error in wien2wannier for spin orbit coupling case

[Niraj Aryal]

Dear Wien2Wannier developer/ experts

I noticed couple of strange things in w2w . I am reporting this hoping that
it will help the developers /experts to figure out the problem in w2w,
especially for spin orbit coupling case, which has been floating around for
a while.

1)
As I reported here:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg1.html,
x w2w -so works for some crystals and doesn't work at all for others.

Now I found that it works for all the cases if we consider the bands
starting from the lowest bands i.e. the case.inwf file should always
contain bands starting from 1 but we can go to any highest band we want.
But this makes the calculation really inefficient and useless.

2)
 While I was playing with graphene without spin orbit coupling, (actually
graphite with large separation between two layers), w2w failed for parallel
case but worked for serial case for both intel and gfortran compiler. But I
am yet to try the serial calculation for spin orbit coupling case. I don't
know if this has any connection with the error I mentioned above.

I will report if I found something more on this.

-- 
With regards

Niraj Aryal
Grad. Student
Florida State University
Tallahassee, Florida-32304
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] Error in wien2wannier for spin orbit coupling case

[Niraj Aryal]

Dear wien2wannier developer

I am a novice wien2k user. I am running wien2k version 14.2 compiled with
intel compilers on machine with Centos operating system. I am trying to use
wien2wannier interface to get MLWF. I have been struggling with a strange
bug. I know this bug has been floating around for a while.I would really
appreciate your input.
So, here is my problem:

The crystal I am working is Zr2Te2P which has rhombohedral lattice
structure and has inversion symmetry. First I performed spin polarized with
spin orbit coupling DFT calculation and as per the direction in the manual
of w2w, I performed following steps:

 ->prepare_w2wdir dft_dir wannier_dir

->cd wannier_dir ; then init_w2w

-> x lapw1 -up -p ; x lapw1 -dn -p

-> x lapwso -up -p

 -> x w2w -up -so -p

In this step, I get error like:

*forrtl: severe (39): error during read, unit 9, file wannier.vectorsoup_1*

and similar error for the down spin.

Strangely, I did not get this error for bcc iron when I was trying to
reproduce the example 18 result in the Wannier90 manual.

However I tried the similar thing for BaTiO3 crystal (by using the struct
file given in the lambda0 directory of BerryPi package) . And, I got the
same error. I wonder if this error occurs only for crystals with certain
symmetry.

The strange thing is w2w works fine without spin orbit coupling for all of
the above crystals.

I would really appreciate you feedback. Thank you!

-- 
With regards

Niraj Aryal
Grad. Student
Florida State University
Tallahassee, Florida-32304
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html