date:20190725

Re: [Wien] Segmentation fault (core dumped) error in w2w with spin-orbit

2019-07-25 Thread Md. Fhokrul Islam

Hi Kyohoon,

1) I think -c switch is default for spin-orbit calculation but I tried both 
with/without -c. Doesn't make any difference.

2) No, there is no case.in1 file, onle case.in1c

3) I did rerun calculation the same way you did but it still doesn't create 
case.amn* or case.mmn* files (these files are empty). It creates the error file 
upw2w.error file right away with single message: "Error in W2W". Again -c 
switch doesn't make any difference.

By the way, these are parallel calculation so I have -p switch in all steps of 
the calculation.


Thanks,
Fhokrul

From: Wien  on behalf of Kyohoon Ahn 

Sent: Thursday, July 25, 2019 8:12 PM
To: A Mailing list for WIEN2k users 
Subject: Re: [Wien] Segmentation fault (core dumped) error in w2w with 
spin-orbit

Dear Fhokrul,

Your procedure looks fine.



Here I have some questions:

(1) Is there no [-c] in your lapwso ..?

(2) Are there both of [in1] and [in1c] in your directory?
If yes, could you delete the [in1], before the [lapw1~lapwso] ?

(3) Could you try to do [x wannier90 -pp], just before [x w2w] ?
And could you try to use [x w2w -up -c -so], instead of [x w2w -up -so] ?
(<<< I think they are the same,,, but just for checking ...)



Best regards,

- Kyohoon

2019년 7월 25일 (목) 오후 6:49, Md. Fhokrul Islam 
mailto:fis...@hotmail.com>>님이 작성:
Dear Kyohoon,

Thank you for your reply. Our procedure are almost the same. First I use 
prepare_w2wdir [dirrecotry name] and then I initialize the calculation with 
init_w2w -up, so it does all the steps you mentioned both for DFT part and 
Wannier90.

After initialization I run:

x lapw1 -c -up   (my system doesn't have inversion symmetry)
x lapw1 -c -dn

x lapwso -up

x w2w -up -so   ---> job crashes here with core dumped error
x w2w -dn -so

x wannier90 -so

I have used this procedure for several other calculation with different systems
and it worked. But for some reason, for this system it is works only up to 
lapwso.
I will check if they problem goes away with smaller k-mesh.


Regards,
Fhokrul







From: Wien 
mailto:wien-boun...@zeus.theochem.tuwien.ac.at>>
 on behalf of Kyohoon Ahn mailto:butz1...@korea.ac.kr>>
Sent: Thursday, July 25, 2019 3:53 PM
To: A Mailing list for WIEN2k users 
mailto:wien@zeus.theochem.tuwien.ac.at>>
Subject: Re: [Wien] Segmentation fault (core dumped) error in w2w with 
spin-orbit

Dear Fhokrul,


I also usually do some calculations with [run_lapw -so].
(i.e., not runsp_lapw)

So I may be I can share my experiences.


In my case, the procedure is following:



### PART 1. WIEN2K   ###


 \cp case.vns case.vnsup
 \cp case.vns case.vnsdn
 \cp case.vsp case.vspup
 \cp case.vsp case.vspdn

 x kgen -fbz (no shift)

 x lapw1 -up (and with the additional options from the dayfile)
 x lapw1 -dn
 x lapwso -up



### PART 2. WIEN2WANNIER & WANNIER90 ###


 write_inwf -up
 write_inwf -dn
 write_win -up

 write case.fermiup and case.fermidn

 x wannier90 -pp
 x w2w -so -up
 x w2w -so -dn
 wannier90 -so


The above procedure works fine for me.
Is there any difference from yours?


Have a nice day.!

Best regards,


- Kyohoon

2019년 7월 23일 (화) 오후 3:04, Md. Fhokrul Islam 
mailto:fis...@hotmail.com>>님이 작성:
Hi Wien2k users and developers,

I encountered couple of problems running w2w with SO for a tetragonal Cd3As2 
(with some impurity). I am using Wien2k18.2.

1. This is a non-magnetic system so I did run spin unpolarized calculations (x 
lapw1, x lapwso) following a note by Elias Assmann but it crashes when starts

x w2w -so -up
x w2w -so -dn

It asks for spin-polarized files vspup and vspdn files etc. I have done several 
non-magnetic calculations with exactly the same approach but I didn't have any 
problem before. But for some reason, in this case the upw2w.def and dnw2w.def 
files are just like the way it creates def files for spin-polarized 
calculations. I tried copying .vsp file to vspup and vspdn, and also other 
files to corresponding spin-polarized extension but it didn't work.

2. Because of this problem in (1) I rerun the DFT calculations with 
spin-polarized setting but this time it crashed with the error:

Segmentation fault (core dumped)
Segmentation fault (core dumped)

There are some segmentation fault in 'w2w -so' reported in mailing list in 2016 
but I understood the issue is resolved for later version of w2w. So I am not 
sure why I am getting the error. There is no other error message.

Note that the bandstructure calculation works fine for this system, so the 
problem is something to do with w2w. I am wondering if anyone has encountered 
similar problem or has any suggestion on how to fix it.


Thanks,
Fhokrul
___
Wien mailing list

Re: [Wien] Segmentation fault (core dumped) error in w2w with spin-orbit

2019-07-25 Thread Kyohoon Ahn

Dear Fhokrul,

Your procedure looks fine.



Here I have some questions:

(1) Is there no [-c] in your lapwso ..?

(2) Are there both of [in1] and [in1c] in your directory?
If yes, could you delete the [in1], before the [lapw1~lapwso] ?

(3) Could you try to do [x wannier90 -pp], just before [x w2w] ?
And could you try to use [x w2w -up -c -so], instead of [x w2w -up -so] ?
(<<< I think they are the same,,, but just for checking ...)



Best regards,

- Kyohoon

2019년 7월 25일 (목) 오후 6:49, Md. Fhokrul Islam 님이 작성:

> Dear Kyohoon,
>
> Thank you for your reply. Our procedure are almost the same. First I use
> prepare_w2wdir [dirrecotry name] and then I initialize the calculation with
> init_w2w -up, so it does all the steps you mentioned both for DFT part and
> Wannier90.
>
> After initialization I run:
>
> x lapw1 -c -up   (my system doesn't have inversion symmetry)
> x lapw1 -c -dn
>
> x lapwso -up
>
> x w2w -up -so   ---> job crashes here with core dumped error
> x w2w -dn -so
>
> x wannier90 -so
>
> I have used this procedure for several other calculation with different
> systems
> and it worked. But for some reason, for this system it is works only up to
> lapwso.
> I will check if they problem goes away with smaller k-mesh.
>
>
> Regards,
> Fhokrul
>
>
>
>
>
>
> --
> *From:* Wien  on behalf of
> Kyohoon Ahn 
> *Sent:* Thursday, July 25, 2019 3:53 PM
> *To:* A Mailing list for WIEN2k users 
> *Subject:* Re: [Wien] Segmentation fault (core dumped) error in w2w with
> spin-orbit
>
> Dear Fhokrul,
>
>
> I also usually do some calculations with [run_lapw -so].
> (i.e., not runsp_lapw)
>
> So I may be I can share my experiences.
>
>
> In my case, the procedure is following:
>
>
> 
> ### PART 1. WIEN2K   ###
> 
>
>  \cp case.vns case.vnsup
>  \cp case.vns case.vnsdn
>  \cp case.vsp case.vspup
>  \cp case.vsp case.vspdn
>
>  x kgen -fbz (no shift)
>
>  x lapw1 -up (and with the additional options from the dayfile)
>  x lapw1 -dn
>  x lapwso -up
>
>
> 
> ### PART 2. WIEN2WANNIER & WANNIER90 ###
> 
>
>  write_inwf -up
>  write_inwf -dn
>  write_win -up
>
>  write case.fermiup and case.fermidn
>
>  x wannier90 -pp
>  x w2w -so -up
>  x w2w -so -dn
>  wannier90 -so
>
>
> The above procedure works fine for me.
> Is there any difference from yours?
>
>
> Have a nice day.!
>
> Best regards,
>
>
> - Kyohoon
>
> 2019년 7월 23일 (화) 오후 3:04, Md. Fhokrul Islam 님이 작성:
>
> Hi Wien2k users and developers,
>
> I encountered couple of problems running w2w with SO for a tetragonal
> Cd3As2 (with some impurity). I am using Wien2k18.2.
>
> 1. This is a non-magnetic system so I did run spin unpolarized
> calculations (x lapw1, x lapwso) following a note by Elias Assmann but it
> crashes when starts
>
> x w2w -so -up
> x w2w -so -dn
>
> It asks for spin-polarized files vspup and vspdn files etc. I have done
> several non-magnetic calculations with exactly the same approach but I
> didn't have any problem before. But for some reason, in this case the
> upw2w.def and dnw2w.def files are just like the way it creates def files
> for spin-polarized calculations. I tried copying .vsp file to vspup and
> vspdn, and also other files to corresponding spin-polarized extension but
> it didn't work.
>
> 2. Because of this problem in (1) I rerun the DFT calculations with
> spin-polarized setting but this time it crashed with the error:
>
> Segmentation fault (core dumped)
> Segmentation fault (core dumped)
>
> There are some segmentation fault in 'w2w -so' reported in mailing list in
> 2016 but I understood the issue is resolved for later version of w2w. So I
> am not sure why I am getting the error. There is no other error message.
>
> Note that the bandstructure calculation works fine for this system, so the
> problem is something to do with w2w. I am wondering if anyone has
> encountered similar problem or has any suggestion on how to fix it.
>
>
> Thanks,
> Fhokrul
> ___
> 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] lapw2c tries to read an anomalous amount of data

2019-07-25 Thread Laurence Marks

How much RAM do you have?

It sounds to me as if on your system the active memory is being paged out,
i.e. you are using swap space and/or you have issues with cached memory not
being released. If you only have 1 9Gb file then there should be no
problem; if you have many there might be. You may want to try
lapw2_vector_split:2 if you are using mpi.

Since nobody else to my knowledge has reported a similar problem, and I for
one have never seen anything similar it seems to be very specific to
whatever you are doing and your OS.

I suspect some incorrect OS parameters, maybe some noisy memory and/or disc.

On Thu, Jul 25, 2019 at 7:12 PM Luc Fruchter  wrote:

> So, my understanding of the situation is that lapw1 may create .vector
> files that are larger than the amount of memory needed by the lapw1 step.
> At the lapw2 step, the program must handle these files with less memory
> than needed, hence these physical / cached unefficient readings.
> This sounds annoying, as one cannot immediately detect the memory need
> for the case, from a try with the beginning of a scf cycle, as I use to do.
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwICAg=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=zVyRqNsJ3IaYoIt3zsG4BuXlCqwyCWaFWNojNEOe1TY=MkBuvyViyVHKizcxYYtmvWcFcmRVDxNVimYKD_pygww=
> SEARCH the MAILING-LIST at:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwICAg=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=zVyRqNsJ3IaYoIt3zsG4BuXlCqwyCWaFWNojNEOe1TY=9INzrH6X_5PrnK3FqMOUluUo3eDgBEtwFhBSZShfG1I=
>


-- 
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu
Corrosion in 4D: www.numis.northwestern.edu/MURI
Co-Editor, Acta Cryst A
"Research is to see what everybody else has seen, and to think what nobody
else has thought"
Albert Szent-Gyorgi
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] lapw2c tries to read an anomalous amount of data

2019-07-25 Thread Luc Fruchter

So, my understanding of the situation is that lapw1 may create .vector 
files that are larger than the amount of memory needed by the lapw1 step.
At the lapw2 step, the program must handle these files with less memory 
than needed, hence these physical / cached unefficient readings.
This sounds annoying, as one cannot immediately detect the memory need 
for the case, from a try with the beginning of a scf cycle, as I use to do.

___
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] lapw2c tries to read an anomalous amount of data

2019-07-25 Thread Luc Fruchter

I was however intrigued by this heavy load of the system, with very 
little CPU use (which means unefficient computation).


Actually, lapw2 routines are still blocked for some I/O most of the 
time. This I/O is however no longer a physical reading from the hard 
disk (and so does not show up in the observation of the disk activity, 
as reported above): these routines spend most of their time reading from 
the .vector files (known from a strace command), but this must have been 
cached in the memory, this time. In my case, the .vector files are ~ 9 
Gb large.

___
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 (core dumped) error in w2w with spin-orbit

2019-07-25 Thread Md. Fhokrul Islam

Dear Kyohoon,

Thank you for your reply. Our procedure are almost the same. First I use 
prepare_w2wdir [dirrecotry name] and then I initialize the calculation with 
init_w2w -up, so it does all the steps you mentioned both for DFT part and 
Wannier90.

After initialization I run:

x lapw1 -c -up   (my system doesn't have inversion symmetry)
x lapw1 -c -dn

x lapwso -up

x w2w -up -so   ---> job crashes here with core dumped error
x w2w -dn -so

x wannier90 -so

I have used this procedure for several other calculation with different systems
and it worked. But for some reason, for this system it is works only up to 
lapwso.
I will check if they problem goes away with smaller k-mesh.


Regards,
Fhokrul







From: Wien  on behalf of Kyohoon Ahn 

Sent: Thursday, July 25, 2019 3:53 PM
To: A Mailing list for WIEN2k users 
Subject: Re: [Wien] Segmentation fault (core dumped) error in w2w with 
spin-orbit

Dear Fhokrul,


I also usually do some calculations with [run_lapw -so].
(i.e., not runsp_lapw)

So I may be I can share my experiences.


In my case, the procedure is following:



### PART 1. WIEN2K   ###


 \cp case.vns case.vnsup
 \cp case.vns case.vnsdn
 \cp case.vsp case.vspup
 \cp case.vsp case.vspdn

 x kgen -fbz (no shift)

 x lapw1 -up (and with the additional options from the dayfile)
 x lapw1 -dn
 x lapwso -up



### PART 2. WIEN2WANNIER & WANNIER90 ###


 write_inwf -up
 write_inwf -dn
 write_win -up

 write case.fermiup and case.fermidn

 x wannier90 -pp
 x w2w -so -up
 x w2w -so -dn
 wannier90 -so


The above procedure works fine for me.
Is there any difference from yours?


Have a nice day.!

Best regards,


- Kyohoon

2019년 7월 23일 (화) 오후 3:04, Md. Fhokrul Islam 
mailto:fis...@hotmail.com>>님이 작성:
Hi Wien2k users and developers,

I encountered couple of problems running w2w with SO for a tetragonal Cd3As2 
(with some impurity). I am using Wien2k18.2.

1. This is a non-magnetic system so I did run spin unpolarized calculations (x 
lapw1, x lapwso) following a note by Elias Assmann but it crashes when starts

x w2w -so -up
x w2w -so -dn

It asks for spin-polarized files vspup and vspdn files etc. I have done several 
non-magnetic calculations with exactly the same approach but I didn't have any 
problem before. But for some reason, in this case the upw2w.def and dnw2w.def 
files are just like the way it creates def files for spin-polarized 
calculations. I tried copying .vsp file to vspup and vspdn, and also other 
files to corresponding spin-polarized extension but it didn't work.

2. Because of this problem in (1) I rerun the DFT calculations with 
spin-polarized setting but this time it crashed with the error:

Segmentation fault (core dumped)
Segmentation fault (core dumped)

There are some segmentation fault in 'w2w -so' reported in mailing list in 2016 
but I understood the issue is resolved for later version of w2w. So I am not 
sure why I am getting the error. There is no other error message.

Note that the bandstructure calculation works fine for this system, so the 
problem is something to do with w2w. I am wondering if anyone has encountered 
similar problem or has any suggestion on how to fix it.


Thanks,
Fhokrul
___
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 (core dumped) error in w2w with spin-orbit

2019-07-25 Thread Kyohoon Ahn

Dear Fhokrul,


I also usually do some calculations with [run_lapw -so].
(i.e., not runsp_lapw)

So I may be I can share my experiences.


In my case, the procedure is following:



### PART 1. WIEN2K   ###


 \cp case.vns case.vnsup
 \cp case.vns case.vnsdn
 \cp case.vsp case.vspup
 \cp case.vsp case.vspdn

 x kgen -fbz (no shift)

 x lapw1 -up (and with the additional options from the dayfile)
 x lapw1 -dn
 x lapwso -up



### PART 2. WIEN2WANNIER & WANNIER90 ###


 write_inwf -up
 write_inwf -dn
 write_win -up

 write case.fermiup and case.fermidn

 x wannier90 -pp
 x w2w -so -up
 x w2w -so -dn
 wannier90 -so


The above procedure works fine for me.
Is there any difference from yours?


Have a nice day.!

Best regards,


- Kyohoon

2019년 7월 23일 (화) 오후 3:04, Md. Fhokrul Islam 님이 작성:

> Hi Wien2k users and developers,
>
> I encountered couple of problems running w2w with SO for a tetragonal
> Cd3As2 (with some impurity). I am using Wien2k18.2.
>
> 1. This is a non-magnetic system so I did run spin unpolarized
> calculations (x lapw1, x lapwso) following a note by Elias Assmann but it
> crashes when starts
>
> x w2w -so -up
> x w2w -so -dn
>
> It asks for spin-polarized files vspup and vspdn files etc. I have done
> several non-magnetic calculations with exactly the same approach but I
> didn't have any problem before. But for some reason, in this case the
> upw2w.def and dnw2w.def files are just like the way it creates def files
> for spin-polarized calculations. I tried copying .vsp file to vspup and
> vspdn, and also other files to corresponding spin-polarized extension but
> it didn't work.
>
> 2. Because of this problem in (1) I rerun the DFT calculations with
> spin-polarized setting but this time it crashed with the error:
>
> Segmentation fault (core dumped)
> Segmentation fault (core dumped)
>
> There are some segmentation fault in 'w2w -so' reported in mailing list in
> 2016 but I understood the issue is resolved for later version of w2w. So I
> am not sure why I am getting the error. There is no other error message.
>
> Note that the bandstructure calculation works fine for this system, so the
> problem is something to do with w2w. I am wondering if anyone has
> encountered similar problem or has any suggestion on how to fix it.
>
>
> Thanks,
> Fhokrul
> ___
> 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] Larger basis at higher energy scales

2019-07-25 Thread Guoping Zhang

Dear Dr. Blaha,

Thank you so much for your great help!

I was unaware of the new feature HELOs and HDLO.  I just downloaded WIen19 
version. I will try to use them in my calculation. I am sorry that I forgot to 
mention that I need states both a few eV above the Fermi level up to several 
Rydberg above the Fermi level, which covers 130 bands from 3s,3p above. I want 
to describe all of them accurately.   My system is FeNi3. I created my own 
weight file (which is read into my modified wien code, see an example below) 
and nearly all the band states are partially occupied.You are correct in 
general APW is quite flexible, but not in my case with so many states . I 
tested several compounds and found that LAPW basis leads to fewer FERMI errors, 
but I am not entirely whether this is due to the difference between APW and 
LAPW basis or not.  Also my case.in1 does not lead to the same Fermi error 
message when I work on the ground state calculation or fewer states occupied in 
conduction bands. 3d-lo is not needed in the beginning. It is when I have more 
states occupied in the conduction band range, where this error message appears.

Here is my
case.weightdn
1st k point
ENERGYOCC   wien  weight
 -7.028525570298  0.9655769771D+00  0.13717373905318D-02
 -7.026380887859  0.9774915802D+00  0.13717390249081D-02
 -7.026364863146  0.9641420436D+00  0.13717371936960D-02
 -6.963105821346  0.9684097144D+00  0.13717377791103D-02
 -6.960884433752  0.9241965826D+00  0.13717317142089D-02
 -6.960863985385  0.9681157351D+00  0.13717377387840D-02
 -5.955580145632  0.9727476037D+00  0.13717383741569D-02
...
  0.551102177130  0.99654806344721D+00  0.13670069457438D-02
  0.556450855740  0.99979910735537D+00  0.13714665395821D-02
  0.557215914130  0.99891542054497D+00  0.13702543491701D-02
  0.598361667748  0.86195838931551D+00  0.11823846218320D-02 <---Fermi energy
  0.614426820474  0.21955408776520D-01  0.30117158815528D-04
  0.616258443618  0.61299145119382D-02  0.84086618819453D-05
  0.620265725818  0.63525870932193D-04  0.87141112389839D-07
  0.671961904610  0.20208405018240D-03  0.27720720189629D-06

  2.523661999828  0.60120208311812D-04  0.82469421552554D-07
  2.535036138282  0.77696873303722D-04  0.10658007311896D-06
  2.557885989252  0.19321304918263D-03  0.26503847624503D-06
  2.561145153263  0.16466297198602D-03  0.22587513303980D-06
  2.570553631703  0.47163224554491D-04  0.64695781281880D-07
  2.573893684513  0.96953048385584D-04  0.13299457940409D-06
  2.764459110536  0.14599878318928D-04  0.20027267927199D-07
  2.765906180448  0.17919946692148D-04  0.24581545531067D-07
  2.786646061603  0.12925884883145D-04  0.17730980635316D-07
  2.787413941376  0.40356598962982D-05  0.55358846314104D-08
  2.790360218136  0.35673794370040D-04  0.48935246049437D-07
  2.808193555479  0.17264394477140D-04  0.23682296950809D-07

One side mark on WIEN update: Is it possible that you keep those old comments 
and remarks inside the modified codes? I found the new version has fewer 
comment lines.

I am grateful if you give me  further comments and suggestions.

Thanks a lot again!

Best regards,
Guoping



From: Wien  on behalf of Peter Blaha 

Sent: Wednesday, July 24, 2019 4:40 PM
To: wien@zeus.theochem.tuwien.ac.at 
Subject: Re: [Wien] Larger basis at higher energy scales

Hi,

I don't know which system it is, but definitely the case.in1 file cannot
work.
Also a couple of other statements are definitely wrong, see below.

> I am interested in the constraint excited states calculation a few eV
> about the Fermi level, so I have to add a few local orbitals at those
> higher energies (see my case.in1 below). I also use LAPW basis instead
> of APW (which is not flexible for delocalized states). But since wien2k
> is restricted to one local basis for each atom, I can not increase
> anymore.

Why do you think that APW is not flexible for delocalized states 
I don't think this is true.

If you just want states "a few eV" above EF, probably nothing is
necessary, but eventually you could add a HDLO.

Why do you think WIEN2k is restricted to one local basis function/atom
???  Since a couple of years one can add multiple LOs (see eg. the NMR
code), but they have to be sufficiently separated in energy .

As a result, WIEN2k gave me
> FERMI - Error. The program stops at LAPW2, with uplapw2.error as
> Error in LAPW2
>   'FERMI' - EFERMI OUT OF ENERGY RANGE
>   'FERMI' - STOP IN EFI
>   'FERMI' - ENERGY OF LOWER BOUND :   0.59917
>   'FERMI' - NUMBER OF STATES AT THE LOWER BOUND   :  70.04360
>   'FERMI' - ENERGY OF UPPER BOUND :   0.59917
>   'FERMI' - NUMBER OF STATES AT THE UPPER BOUND   :  70.04377
>   'FERMI' - ADD   69.72319
>   'FERMI' - SOS 0..........000
>   'FERMI' - NOS **
> **  testerror: Error

Re: [Wien] lapw2c tries to read an anomalous amount of data

2019-07-25 Thread Laurence Marks

I expect it was the Ubuntu update.

The synchronous CPU will be some combination of:
a) Multiple cores running lapack commands
b) Openmp code in some subroutines (if you are not using mpi)
c) Data communications and/or cores waiting for others if you are using
mpi. When they are all in step there will be an apparent burst.

On Thu, Jul 25, 2019 at 12:25 PM Luc Fruchter 
wrote:

> I changed to Wien2k 19.1 version, latest Intel ifort compiler (2019.4)
> and latest Ubuntu (18.04.2), shared memory, 4 CPUs, same case with 154
> atoms :
>
> - no more anomalous reading of the disk from parallel lapw2c
>
> - the system is however slowed down a lot (as seen from switching
> between applications), although there is very little use of the CPUs.
> The usage of the Cpus looks strange, compared to lpaw1c : quasi idle
> state, interrupted by burst of synchronous CPU use for a few seconds
> (why are lpaw2c synchronous: exchange data ?).
>
> - no log warnings
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwICAg=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=woK5GmXj7EmuNvmeBZLERexqEYJ1Gxy7yjF4sV2H1IA=oN_y0PMTBGFDfTY5zWM_ytb0zN4xIIl55vcWkefWV-0=
> SEARCH the MAILING-LIST at:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwICAg=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=woK5GmXj7EmuNvmeBZLERexqEYJ1Gxy7yjF4sV2H1IA=alo9IkAiLLoUEnci7rmpmEVQUQzGDBtDYqmIufVhB2g=
>


-- 
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu
Corrosion in 4D: www.numis.northwestern.edu/MURI
Co-Editor, Acta Cryst A
"Research is to see what everybody else has seen, and to think what nobody
else has thought"
Albert Szent-Gyorgi
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] lapw2c tries to read an anomalous amount of data

2019-07-25 Thread Luc Fruchter

I changed to Wien2k 19.1 version, latest Intel ifort compiler (2019.4) 
and latest Ubuntu (18.04.2), shared memory, 4 CPUs, same case with 154 
atoms :


- no more anomalous reading of the disk from parallel lapw2c

- the system is however slowed down a lot (as seen from switching 
between applications), although there is very little use of the CPUs. 
The usage of the Cpus looks strange, compared to lpaw1c : quasi idle 
state, interrupted by burst of synchronous CPU use for a few seconds 
(why are lpaw2c synchronous: exchange data ?).


- no log warnings
___
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 (core dumped) error in w2w with spin-orbit

Re: [Wien] Segmentation fault (core dumped) error in w2w with spin-orbit

Re: [Wien] lapw2c tries to read an anomalous amount of data

[Wien] lapw2c tries to read an anomalous amount of data

[Wien] lapw2c tries to read an anomalous amount of data

Re: [Wien] Segmentation fault (core dumped) error in w2w with spin-orbit

Re: [Wien] Segmentation fault (core dumped) error in w2w with spin-orbit

Re: [Wien] Larger basis at higher energy scales

Re: [Wien] lapw2c tries to read an anomalous amount of data

[Wien] lapw2c tries to read an anomalous amount of data

10 matches

Site Navigation

Mail list logo

Footer information