Re: [Wien] Segmentation fault in w2w

[Peter Blaha]

Thank you very much for your report.

Next version will include these changes.

Best regards
Peter Blaha

On 10/6/20 1:24 AM, Niraj Aryal wrote:

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
mailto:laurence.ma...@gmail.com>> 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
mailto:debonairni...@gmail.com>> 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:

w2w                00432427  l2amn_m_mp_l2amn_  
   449  modules_rc.F
w2w                0042D68E  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
mailto:gs...@crimson.ua.edu>> 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
 

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
 
 ] .  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, 

Re: [Wien] Segmentation fault in w2w

[Laurence Marks]

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

Re: [Wien] Segmentation fault in w2w

[Laurence Marks]

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

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

Re: [Wien] Segmentation fault in w2w

[Gavin Abo]

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

Re: [Wien] Segmentation fault in w2w

[Laurence Marks]

Did you use -traceback in your compilation options? It may give line
information. Or add -g to the compilation of w2w.

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

On Fri, Sep 11, 2020, 14:21 Rubel, Oleg  wrote:

> Thank you for sharing that!
>
> Would it be possible to share (maybe privately) the case.struct file and
> _exact_ sequence of commands (incl. initialization, scf run, etc.) with all
> options. Then it will be possible to reproduce and debug.
>
> Thank you in advance
> 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:
> https://urldefense.com/v3/__http://olegrubel.mcmaster__;!!Dq0X2DkFhyF93HkjWTBQKhk!D1PDZ4H4yGv1h-epxzlh30UnLvuZYsOSrQyNarRxqeZcD37uFXeXe9aC_XATsEa-hsiBYw$
>
> 
> From: Wien  on behalf of Niraj
> Aryal 
> Sent: Friday, September 11, 2020 14:02
> To: A Mailing list for WIEN2k users
> Subject: [Wien] Segmentation fault in w2w
>
> 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://urldefense.com/v3/__https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18896.html__;!!Dq0X2DkFhyF93HkjWTBQKhk!D1PDZ4H4yGv1h-epxzlh30UnLvuZYsOSrQyNarRxqeZcD37uFXeXe9aC_XATsEamPh9SGQ$
> 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
>
> https://urldefense.com/v3/__http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien__;!!Dq0X2DkFhyF93HkjWTBQKhk!D1PDZ4H4yGv1h-epxzlh30UnLvuZYsOSrQyNarRxqeZcD37uFXeXe9aC_XATsEZj553dpA$
> SEARCH the MAILING-LIST at:
> https://urldefense.com/v3/__http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html__;!!Dq0X2DkFhyF93HkjWTBQKhk!D1PDZ4H4yGv1h-epxzlh30UnLvuZYsOSrQyNarRxqeZcD37uFXeXe9aC_XATsEayRjIvkg$
>
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.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] Segmentation fault in w2w

[Rubel, Oleg]

Thank you for sharing that!

Would it be possible to share (maybe privately) the case.struct file and 
_exact_ sequence of commands (incl. initialization, scf run, etc.) with all 
options. Then it will be possible to reproduce and debug.

Thank you in advance
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


From: Wien  on behalf of Niraj Aryal 

Sent: Friday, September 11, 2020 14:02
To: A Mailing list for WIEN2k users
Subject: [Wien] Segmentation fault in w2w

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