Re: [Wien] View structure in a remote machine

[delamora]

I have used "zoom" and it works in my machine and the other people that are 
connected, but not in the remote computer.
Maybe there is a trick that I do not see.


Oleg, sorry for my late reply.
When I am working directly on one computer and I would like to see the crystal 
structure then I push the "view structure" button and the structure appears in 
the screen, but when I am in a remote computer working the WIEN2k and I push 
this button then the crystal structure is displayed in the other computer and 
non in mine.
Does VNC corrects or solves this problem?
Cheers

Pablo

De: Wien  en nombre de Rubel, Oleg 

Enviado: viernes, 2 de octubre de 2020 02:59 p. m.
Para: A Mailing list for WIEN2k users 
Asunto: Re: [Wien] View structure in a remote machine

I would suggest trying VNC (https://www.youtube.com/watch?v=EWkrqqnOgdo). It 
has a number of advantages over X11 display forwarding.

Oleg


From: Wien  on behalf of delamora 

Sent: Friday, October 2, 2020 15:39
To: A Mailing list for WIEN2k users
Subject: [Wien] View structure in a remote machine

Dear WIEN2k community,
I am doing calculations in a remote machine ("remote.machine")
I can connect with
remote.machine:7890
and with this I can do calculations in than machine
but when I try to see the crystal structure, xcrysden, the image appears in 
"remote.machine" so I cannot see it in my machine at home
Is there a way to visualize the crystal structure in my machine at home?
The same seems to happen with Electron Density Plots.

Cheers

Pablo
___
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] View structure in a remote machine

[delamora]

Oleg, sorry for my late reply.
When I am working directly on one computer and I would like to see the crystal 
structure then I push the "view structure" button and the structure appears in 
the screen, but when I am in a remote computer working the WIEN2k and I push 
this button then the crystal structure is displayed in the other computer and 
non in mine.
Does VNC corrects or solves this problem?
Cheers

Pablo

De: Wien  en nombre de Rubel, Oleg 

Enviado: viernes, 2 de octubre de 2020 02:59 p. m.
Para: A Mailing list for WIEN2k users 
Asunto: Re: [Wien] View structure in a remote machine

I would suggest trying VNC (https://www.youtube.com/watch?v=EWkrqqnOgdo). It 
has a number of advantages over X11 display forwarding.

Oleg


From: Wien  on behalf of delamora 

Sent: Friday, October 2, 2020 15:39
To: A Mailing list for WIEN2k users
Subject: [Wien] View structure in a remote machine

Dear WIEN2k community,
I am doing calculations in a remote machine ("remote.machine")
I can connect with
remote.machine:7890
and with this I can do calculations in than machine
but when I try to see the crystal structure, xcrysden, the image appears in 
"remote.machine" so I cannot see it in my machine at home
Is there a way to visualize the crystal structure in my machine at home?
The same seems to happen with Electron Density Plots.

Cheers

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

[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] LAPW1 error

[Laurence Marks]

Which version of ifort (do ifort -version)? I know there is a bug with some
2017 and -assume buffered_io that effects the mixer. It might be connected,
or not.

Ifort can be buggy, but it is faster than gfortran with Intel CPUs. It is
good to keep more than one version so one can regress to check problems.
Also the Intel IMPI is buggy with a memory leak that was only recently
fixed.

_
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 Mon, Oct 5, 2020, 07:23 Israel Omar Perez Lopez 
wrote:

> Hi
>
> That same problem happens to me with version 19.1 and 19.2 for some basic
> structures (for instance Li Im-3m) using ifort 2018, that doesn't happen
> with gfortran for version 18 or 19. I do not know why. But when it happens,
> I use the .machines file and set the omp_global to 1 and run in parallel.
> The error no longer appears. Apparently, there is a problem with the
> OMP_NUM_THREADS variable. If during installation of Wien2k the system
> detects 2 cores, but you set it 4 or 8, those kinds of errors show up. In
> my case, I have 4 cores in a laptop. If I set it to 4 the problem shows up
> every time a SCF is executed. Then I set to 2 and works fine for most
> structures but in some fails. In those cases I create the .machines and set
> omp_global to 1 and no error is issued.
>
> Hope this helps
>
> Dr. Israel Pérez
>
> Institute of Engineering and Technology
>
> Department of Physics and Mathematics,
>
> Universidad Autónoma de Ciudad Juárez
>
> Av. del Charro 450 Nte., Col. Partido Romero,
>
> Ciudad Juárez, Juarez Chihuahua. Mexico C. P. 32310
>
> Tel: +52 (656) 688 4887
>
>
> National Council of Science and Technology
>
> Insurgentes Sur No. 1582,
>
> Col. Crédito Constructor,  C.P. 03940
>
> Del. Benito Juárez, México D. F.
>
___
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] LAPW1 error

[Israel Omar Perez Lopez]

Hi

That same problem happens to me with version 19.1 and 19.2 for some basic 
structures (for instance Li Im-3m) using ifort 2018, that doesn't happen with 
gfortran for version 18 or 19. I do not know why. But when it happens, I use 
the .machines file and set the omp_global to 1 and run in parallel. The error 
no longer appears. Apparently, there is a problem with the OMP_NUM_THREADS 
variable. If during installation of Wien2k the system detects 2 cores, but you 
set it 4 or 8, those kinds of errors show up. In my case, I have 4 cores in a 
laptop. If I set it to 4 the problem shows up every time a SCF is executed. 
Then I set to 2 and works fine for most structures but in some fails. In those 
cases I create the .machines and set omp_global to 1 and no error is issued.

Hope this helps

Dr. Israel P?rez

Institute of Engineering and Technology
Department of Physics and Mathematics,
Universidad Aut?noma de Ciudad Ju?rez
Av. del Charro 450 Nte., Col. Partido Romero,
Ciudad Ju?rez, Juarez Chihuahua. Mexico C. P. 32310
Tel: +52 (656) 688 4887

National Council of Science and Technology
Insurgentes Sur No. 1582,
Col. Cr?dito Constructor,  C.P. 03940
Del. Benito Ju?rez, M?xico D. F.

From: Wien  on behalf of Peter Blaha 

Sent: Sunday, October 4, 2020 1:38 PM
To: wien@zeus.theochem.tuwien.ac.at 
Subject: Re: [Wien] LAPW1 error

How do you compile wien2k ?

ifort or gfortran ? Which version ?

Could it be that your compiler was upgraded and you must recompile ?

In any case recompile, maybe with -O1 or even -O0 -C

Am 04.10.2020 um 16:32 schrieb Riyajul Islam:
> I did search in the wien2k mailing list. The suggestions given there is
> related to case.struct and case.in1 files.
>
> On Sun, 4 Oct 2020, 7:59 pm Tran, Fabien,  > wrote:
>
> If not already done, also search for problems/solutions related to
> SECLR4, POTRF, or Scalapack/LAPACK in the WIEN2k mailing list.
>
>
> 
> *From:* Wien  > on behalf of
> Riyajul Islam mailto:riyaju...@gmail.com>>
> *Sent:* Sunday, October 4, 2020 4:25 PM
> *To:* A Mailing list for WIEN2k users
> *Subject:* Re: [Wien] LAPW1 error
> I have tried many times in new directories. Most probably i have to
> install scalapack/lapack and recompile wien2k again.
>
> On Sun, 4 Oct 2020, 7:48 pm Tran, Fabien,  > wrote:
>
> As I said, it works for me. Using your first struct file and
> executing
> init_lapw -b -sp
> runsp_lapw -ec 0.0001 -cc 0.0001 -NI
> the calculation finishes properly.
> Is it really not working if you follow this same procedure in a
> new directory?
> If not, maybe there is a problem/bug with your installed
> Scalapack/LAPACK library?
>
>
> From: Wien  > on behalf of
> Riyajul Islam mailto:riyaju...@gmail.com>>
> Sent: Sunday, October 4, 2020 3:43 PM
> To: A Mailing list for WIEN2k users
> Subject: Re: [Wien] LAPW1 error
>
>
> It crashes during the 1st iteration. Error occurs in
> non-parallel calculation also. I'm using the 19.2 version of
> wien2k. I ran other structures and it works fine.
>
>
> On Sun, 4 Oct 2020, 6:42 pm Tran, Fabien,
> mailto:fabien.t...@tuwien.ac.at>> wrote:
>More questions:
> At which iteration is it crashing? At the first one or not?
> Is it crashing also in non-parallel calculation?
> Which WIEN2k version are you using?
>
> One remark:
> This second structure corresponds to FeNi, while the first one
> was for Fe2Ni.
>
>
> From: Wien  > on behalf of
> Riyajul Islam mailto:riyaju...@gmail.com>>
> Sent: Sunday, October 4, 2020 2:58 PM
> To: A Mailing list for WIEN2k users
> Subject: Re: [Wien] LAPW1 error
>
> Calculations details
> spin-polarized
> PBE functional
> RKmax= changed from 5-9
> After initialization, I tried running the command runsp_lapw -p
> -ec 0.0001 -cc 0.0001 -NI
>
> I tried with another bct structure of FeNi ( case.struct and
> case.in1 files are attached), mentioned in the
> paper 10.1103/PhysRevB.90.014402
>
> On Sun, 4 Oct 2020 at 18:13, Tran, Fabien
> mailto:fabien.t...@tuwien.ac.at>> wrote:
>Hi,
>
> I can not reproduce this error, at least not with default
> parameters and PBE functional.
> You need to provide more information like the functional,
> spin-polarized or non-spin-polarized,
> the command that you executed, etc.
> Besides, are you sure that