Re: [Wien] Regarding bandstructure calculation in WIEN2k 17.1

[mohaddeseh abbasnejad]

Dear Gavin Abo,

Thank you very much for your help.
I could solve it.
However, I can not have the PostScript format in the w2web. However,
it saves correctly.
Is there any way to have it?

Regards,
Mohaddeseh

On 4/20/18, Gavin Abo  wrote:
> There are fixed band.pl and scf.pl files for WIEN2k 17.1 [1-4] in the
> post [1] that you can use (or band.patch and scf.patch [5,6] at [7]
> could be used instead).
>
> If you choose to use the patch files.  The following is what I do.
>
> First, I go to [7].  I click on band.patch on the webpage, then I click
> on the Raw button followed by getting the url from the bar of my web
> browser (Firefox).  In other words, the url:
>
> https://raw.githubusercontent.com/gsabo/WIEN2k-Patches/master/17.1/band.patch
>
> Then in the terminal on my Linux system using the obtained url, I do for
> example:
>
> username@computername:~/Desktop$ cd $WIENROOT/SRC_w2web/htdocs/exec
> username@computername:~/WIEN2k/SRC_w2web/htdocs/exec$ wget
> https://raw.githubusercontent.com/gsabo/WIEN2k-Patches/master/17.1/band.patch
> ...
> 2018-04-19 18:38:34 (5.32 MB/s) - ‘band.patch’ saved [63/63]
> username@computername:~/WIEN2k/SRC_w2web/htdocs/exec$ wget
> https://raw.githubusercontent.com/gsabo/WIEN2k-Patches/master/17.1/scf.patch
> ...
> 2018-04-19 18:39:10 (16.0 MB/s) - ‘scf.patch’ saved [114/114]
> username@computername:~/WIEN2k/SRC_w2web/htdocs/exec$ patch -b band.pl
> band.patch
> patching file band.pl
> username@computername:~/WIEN2k/SRC_w2web/htdocs/exec$ patch -b scf.pl
> scf.patch
> patching file scf.pl
>
> [1]
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16069.html
> (The text of the code in the post can be copied and pasted into a text
> editor to create the band.pl and scf.pl files)
> [2]
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16743.html
> [3]
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16843.html
> [4]
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17179.html
> [5]
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17169.html
> [6]
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17218.html
> [7] https://github.com/gsabo/WIEN2k-Patches/tree/master/17.1
>
> On 4/19/2018 11:30 AM, mohaddeseh abbasnejad wrote:
>>
>> Dear experts,
>>
>> Hello,
>>
>> Recently, I have installed WIEN2k version 17.1.
>> After I installed it successfully, I tried to test it running
>> different tasks.
>> Every things went as well. However, I could not do bandstructure
>> calculations.
>> In fact, when doing lapw1 -band command, it looks for the file with
>> inc prefix in the another directory than
>> the one I am doing calculations in.
>> I was wondering if you can help me solving the problem.
>> Thanks in advance.
>>
>> Regards,
>> Mohaddeseh
>
>


-- 
-

Mohaddeseh Abbasnejad,
Assistant Professor of Physics,
Faculty of Physics,
Shahid Bahonar University of Kerman,
Kerman, Iran
P.O. Box 76169-133
Tel: +98 34 31322199
Fax: +98 34 33257434
Cellphone: +98 917 731 7514
E-Mail: m.abbasne...@gmail.com
Website:  academicstaff.uk.ac.ir/moabbasnejad

-
___
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] Regarding bandstructure calculation in WIEN2k 17.1

[Gavin Abo]

There are fixed band.pl and scf.pl files for WIEN2k 17.1 [1-4] in the 
post [1] that you can use (or band.patch and scf.patch [5,6] at [7] 
could be used instead).


If you choose to use the patch files.  The following is what I do.

First, I go to [7].  I click on band.patch on the webpage, then I click 
on the Raw button followed by getting the url from the bar of my web 
browser (Firefox).  In other words, the url:


https://raw.githubusercontent.com/gsabo/WIEN2k-Patches/master/17.1/band.patch

Then in the terminal on my Linux system using the obtained url, I do for 
example:


username@computername:~/Desktop$ cd $WIENROOT/SRC_w2web/htdocs/exec
username@computername:~/WIEN2k/SRC_w2web/htdocs/exec$ wget 
https://raw.githubusercontent.com/gsabo/WIEN2k-Patches/master/17.1/band.patch

...
2018-04-19 18:38:34 (5.32 MB/s) - ‘band.patch’ saved [63/63]
username@computername:~/WIEN2k/SRC_w2web/htdocs/exec$ wget 
https://raw.githubusercontent.com/gsabo/WIEN2k-Patches/master/17.1/scf.patch

...
2018-04-19 18:39:10 (16.0 MB/s) - ‘scf.patch’ saved [114/114]
username@computername:~/WIEN2k/SRC_w2web/htdocs/exec$ patch -b band.pl 
band.patch

patching file band.pl
username@computername:~/WIEN2k/SRC_w2web/htdocs/exec$ patch -b scf.pl 
scf.patch

patching file scf.pl

[1] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16069.html 
(The text of the code in the post can be copied and pasted into a text 
editor to create the band.pl and scf.pl files)
[2] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16743.html
[3] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16843.html
[4] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17179.html
[5] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17169.html
[6] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17218.html

[7] https://github.com/gsabo/WIEN2k-Patches/tree/master/17.1

On 4/19/2018 11:30 AM, mohaddeseh abbasnejad wrote:


Dear experts,

Hello,

Recently, I have installed WIEN2k version 17.1.
After I installed it successfully, I tried to test it running 
different tasks.
Every things went as well. However, I could not do bandstructure 
calculations.
In fact, when doing lapw1 -band command, it looks for the file with 
inc prefix in the another directory than

the one I am doing calculations in.
I was wondering if you can help me solving the problem.
Thanks in advance.

Regards,
Mohaddeseh


___
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] 'LAPW2: semicore band-ranges too large error' for spin-orbit calculation

[Md. Fhokrul Islam]

Hi Gavin,

The compilation was done with -O0 option. I guess the problem is something else.


Thanks,
Fhokrul






From: Wien  on behalf of Gavin Abo 

Sent: Thursday, April 19, 2018 12:26 PM
To: wien@zeus.theochem.tuwien.ac.at
Subject: Re: [Wien] 'LAPW2: semicore band-ranges too large error' for 
spin-orbit calculation


Sorry, I don't know which of the 2016/2017/2018 ifort/mkl versions are more 
stable as I mentioned before [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16802.html ].


I would probably try the Update 2, Update 4, or try compiling with -O0 as Intel 
suggested on the webpage:


https://software.intel.com/en-us/articles/read-failure-unformatted-file-io-psxe-16-update-3


However, as Prof. Blaha and you have hinted at, the problem may be more likely 
coming from something else:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17287.html

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg10561.html

Kind Regards,

Gavin

On 4/19/2018 2:45 AM, Md. Fhokrul Islam wrote:
Hi Gavin,

Thank you very much for detailed explanation. I am indeed using intel 
2016.0.3.210. Could you please let me know which version is the least buggy 
version?

I am not sure if the problem is with lapwso. All the output files from lapw1 
and lapwso (case.scf1, case.scfso) look ok to me. But case.scf2 files have only 
these lines:

--
case.scf2up

   TEMP.-SMEARING WITH0.00500 Ry
  -S / Kb   =  -5.64060904
  -(T*S)/2  =  -0.00705076
  Chem Pot  =   0.25857200
 Bandranges (emin - emax) and occupancy:
:WARN :BAN1:   1   -9.849452   -7.837911  1.



It is bit confusing for me that I am encountering this problem only for this 
system. As I mentioned in my previous message, I have worked with different 
systems with spin-orbit coupling (some supercells containing more than 250 
atoms) but I didn't have problem with this version of intel.


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] Non-magnetic GGA+U+SOC calculations for Sm in Sm2+ valence state in Wien2K

[Anup Shakya]

Dear Prof. Blaha and Prof. Laurence,

Thank you very much for the suggestions.

Anup Pradhan Sakhya (Ph.D.)
___
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] Non-magnetic GGA+U+SOC calculations for Sm in Sm2+ valence state in Wien2K

[Laurence Marks]

I will second and third Peter's comments about 4f. You also have to worry
about what direction is relevant for the SOC, and whether it should be a
statistical average.

We managed to get decent agreement with experiment in DOI:
10.1103/PhysRevMaterials.2.025001 . An unconventional approach, determining
the hybrid fraction for -eece that best fits the experimental atomic
positions, and treating the Hubbard +U as a spectroscopic correction for
the valence hole.
_
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 Thu, Apr 19, 2018, 8:33 AM Peter Blaha 
wrote:

> Of course using runsp or runsp_c you will get different solutions.
>
> The 4f systems are very difficult to describe and GGA but also GGA+U or
> hybrid-DFT are only crude approximations (another one would be to put a
> certain number of 4f electrons into the core ).
>
> So we cannot get "THE correct solution", and not even a solution close
> to the correct one unambigously, but have to search for different
> solutions (eg. a magnetic one and a non-magnetic one) and then decide in
> a comparison with experiment, which one we should take.
>
> This sounds "horrible", but basically this is the status of DFT for 4f
> systems.
>
> On 04/19/2018 12:25 PM, Anup Shakya wrote:
> > Dear Prof. Blaha,
> >
> > Thank you very much for the reply.
> >
> > Yes I could see that the occupancy in spin up case is 3  and for spin
> > down is 3. After that as suggested by you I did
> >   x lapwdm -up -so
> > and x lapwdm -dn -so
> >
> > Then I checked the  case.scfdmup file and I could find the information
> > about the occupancy of f electrons in spin up as well as spin down which
> > is more clear than case.dmatup/dn file.
> >
> > :ORB001:  ORBITAL MOMENT:  0.0  0.0  0.0 PROJECTION ON M
> > 0.0
> > :SPI001:  SPIN MOMENT:   0.0   0.0   0.0 PROJECTION ON M
> > 0.0
> >
> > After that I performed runsp -orb -p as suggested in previous posts. But
> > since I wanted to perform non-magnetic calculations. So using this
> > command is fine or should I use runsp_c -orb -p??
> >
> > I performed runsp -orb -p and then afterwards checked the case.scfdmup
> > and case.scfdmdn files which have changed as shown below:
> >
> > case.scfdmup
> >
> >   Density matrix UPUP block, real part.  L= 3
> >   0.56681  0.0  0.0  0.0  0.42473  0.0  0.0
> >   0.0  0.00461  0.0  0.0  0.0 -0.00185  0.0
> >   0.0  0.0  0.32262  0.0  0.0  0.0  0.42473
> >   0.0  0.0  0.0  0.96033  0.0  0.0  0.0
> >   0.42473  0.0  0.0  0.0  0.32262  0.0  0.0
> >   0.0 -0.00185  0.0  0.0  0.0  0.00461  0.0
> >   0.0  0.0  0.42473  0.0  0.0  0.0  0.56681
> >
> > case.scfdmdn
> >
> > Density matrix UPUP block, real part.  L= 3
> >   0.61086  0.0  0.0  0.0  0.46143  0.0  0.0
> >   0.0  0.00462  0.0  0.0  0.0 -0.00193  0.0
> >   0.0  0.0  0.35289  0.0  0.0  0.0  0.46143
> >   0.0  0.0  0.0  0.96012  0.0  0.0  0.0
> >   0.46143  0.0  0.0  0.0  0.35289  0.0  0.0
> >   0.0 -0.00193  0.0  0.0  0.0  0.00462  0.0
> >   0.0  0.0  0.46143  0.0  0.0  0.0  0.61086
> >
> > Now, since the occupancy has changed. What should I do? Any suggestions
> > would be of great help to me.
> >
> > Anup Pradhan Sakhya (Ph.D.)
> >
> >
> >
> > ___
> > 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=DwIGaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=41LOVsShASDuqDatfuIo32MsoJj1rOEN1y8ZebRQ_-Y=W1C0xRpk4PodCtMC-GfA_uijBsSvxzFsxLSmRsqBDYE=
> > 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=DwIGaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=41LOVsShASDuqDatfuIo32MsoJj1rOEN1y8ZebRQ_-Y=TjaK-bLvzCn2ku_OOGwGNJSprmUyUCzoOQhgMETq1-8=
> >
>
> --
>
>P.Blaha
> --
> Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
> Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
> Email: bl...@theochem.tuwien.ac.atWIEN2k:
> 

Re: [Wien] Non-magnetic GGA+U+SOC calculations for Sm in Sm2+ valence state in Wien2K

[Peter Blaha]

Of course using runsp or runsp_c you will get different solutions.

The 4f systems are very difficult to describe and GGA but also GGA+U or 
hybrid-DFT are only crude approximations (another one would be to put a 
certain number of 4f electrons into the core ).


So we cannot get "THE correct solution", and not even a solution close 
to the correct one unambigously, but have to search for different 
solutions (eg. a magnetic one and a non-magnetic one) and then decide in 
a comparison with experiment, which one we should take.


This sounds "horrible", but basically this is the status of DFT for 4f 
systems.


On 04/19/2018 12:25 PM, Anup Shakya wrote:

Dear Prof. Blaha,

Thank you very much for the reply.

Yes I could see that the occupancy in spin up case is 3  and for spin 
down is 3. After that as suggested by you I did

  x lapwdm -up -so
and x lapwdm -dn -so

Then I checked the  case.scfdmup file and I could find the information 
about the occupancy of f electrons in spin up as well as spin down which 
is more clear than case.dmatup/dn file.


:ORB001:  ORBITAL MOMENT:  0.0  0.0  0.0 PROJECTION ON M  
0.0
:SPI001:  SPIN MOMENT:   0.0   0.0   0.0 PROJECTION ON M  
0.0


After that I performed runsp -orb -p as suggested in previous posts. But 
since I wanted to perform non-magnetic calculations. So using this 
command is fine or should I use runsp_c -orb -p??


I performed runsp -orb -p and then afterwards checked the case.scfdmup 
and case.scfdmdn files which have changed as shown below:


case.scfdmup

  Density matrix UPUP block, real part.  L= 3
  0.56681  0.0  0.0  0.0  0.42473  0.0  0.0
  0.0  0.00461  0.0  0.0  0.0 -0.00185  0.0
  0.0  0.0  0.32262  0.0  0.0  0.0  0.42473
  0.0  0.0  0.0  0.96033  0.0  0.0  0.0
  0.42473  0.0  0.0  0.0  0.32262  0.0  0.0
  0.0 -0.00185  0.0  0.0  0.0  0.00461  0.0
  0.0  0.0  0.42473  0.0  0.0  0.0  0.56681

case.scfdmdn

Density matrix UPUP block, real part.  L= 3
  0.61086  0.0  0.0  0.0  0.46143  0.0  0.0
  0.0  0.00462  0.0  0.0  0.0 -0.00193  0.0
  0.0  0.0  0.35289  0.0  0.0  0.0  0.46143
  0.0  0.0  0.0  0.96012  0.0  0.0  0.0
  0.46143  0.0  0.0  0.0  0.35289  0.0  0.0
  0.0 -0.00193  0.0  0.0  0.0  0.00462  0.0
  0.0  0.0  0.46143  0.0  0.0  0.0  0.61086

Now, since the occupancy has changed. What should I do? Any suggestions 
would be of great help to me.


Anup Pradhan Sakhya (Ph.D.)



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



--

  P.Blaha
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
Email: bl...@theochem.tuwien.ac.atWIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at/TC_Blaha
--
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] 'LAPW2: semicore band-ranges too large error' for spin-orbit calculation

[Gavin Abo]

Sorry, I don't know which of the 2016/2017/2018 ifort/mkl versions are 
more stable as I mentioned before [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16802.html 
].



I would probably try the Update 2, Update 4, or try compiling with -O0 
as Intel suggested on the webpage:



https://software.intel.com/en-us/articles/read-failure-unformatted-file-io-psxe-16-update-3


However, as Prof. Blaha and you have hinted at, the problem may be more 
likely coming from something else:



https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17287.html

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg10561.html


Kind Regards,

Gavin

On 4/19/2018 2:45 AM, Md. Fhokrul Islam wrote:

Hi Gavin,

Thank you very much for detailed explanation. I am indeed using intel 
2016.0.3.210. Could you please let me know which version is the least 
buggy version?


I am not sure if the problem is with lapwso. All the output files from 
lapw1 and lapwso (case.scf1, case.scfso) look ok to me. But case.scf2 
files have only these lines:


--
case.scf2up

       TEMP.-SMEARING WITH    0.00500 Ry
          -S / Kb           =  -5.64060904
          -(T*S)/2          =  -0.00705076
          Chem Pot          =   0.25857200
         Bandranges (emin - emax) and occupancy:
:WARN :BAN1:   1   -9.849452   -7.837911  1.



It is bit confusing for me that I am encountering this problem only 
for this system. As I mentioned in my previous message, I have worked 
with different systems with spin-orbit coupling (some supercells 
containingmore than 250 atoms) but I didn't have problem with this 
version of intel.



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

Re: [Wien] 'LAPW2: semicore band-ranges too large error' for spin-orbit calculation

[Lyudmila Dobysheva]

19.04.2018 12:45, Md. Fhokrul Islam wrote:
I am not sure if the problem is with lapwso. All the output files from 
lapw1 and lapwso (case.scf1, case.scfso) look ok to me. But case.scf2 
files have only these lines:

        TEMP.-SMEARING WITH    0.00500 Ry
           -S / Kb           =  -5.64060904
           -(T*S)/2          =  -0.00705076
           Chem Pot          =   0.25857200
          Bandranges (emin - emax) and occupancy:
:WARN :BAN1:   1   -9.849452   -7.837911  1.
It is bit confusing for me that I am encountering this problem only for 
this system.


I didn't see if you have sent the initial files: .struct, in0,in1,in2, 
inso, klist. The output files: error, dayfile...

Better send them.

Best wishes
Lyudmila Dobysheva
--
Physics-Techn.Institute,
Udmurt Federal Research Center, Ural Br. of Rus.Ac.Sci.
426000 Izhevsk Kirov str. 132
Russia
---
Tel. +7 (34I2)43-24-59 (office), +7 (9I2)OI9-795O (home)
Skype: lyuka18 (office), lyuka17 (home)
E-mail: lyuk...@mail.ru (office), lyuk...@gmail.com (home)
___
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] 'LAPW2: semicore band-ranges too large error' for spin-orbit calculation

[Peter Blaha]

I am not sure if the problem is with lapwso. All the output files from 
lapw1 and lapwso (case.scf1, case.scfso) look ok to me. 


The scf files look "ok", but you need to check the output1* and 
outputso* files.


lapw2 detects that the first eigenvalue on all the k-points has a large 
spread, i.e. they vary from -9 to -7 Ry.
This is unphysical (such a deep semicore state MUST NOT vary in energy 
by more than a few mRy) for the different k-points and therefore lapw2 
stops with an error messge, but the error must happened already before.


Check if such a variation already occurs in output1 or only in outputso.

Of course, these problems could also come from non-optimal sphere radii 
(with approximate linear dependency), bad energy parameters, a bad 
potential, 



But case.scf2

files have only these lines:

--
case.scf2up

        TEMP.-SMEARING WITH    0.00500 Ry
           -S / Kb           =  -5.64060904
           -(T*S)/2          =  -0.00705076
           Chem Pot          =   0.25857200
          Bandranges (emin - emax) and occupancy:
:WARN :BAN1:   1   -9.849452   -7.837911  1.



It is bit confusing for me that I am encountering this problem only for 
this system. As I mentioned in my previous message, I have worked with 
different systems with spin-orbit coupling (some supercells 
containingmore than 250 atoms) but I didn't have problem with this 
version of intel.



Thanks,
Fhokrul



*From:* Wien  on behalf of 
Gavin Abo 

*Sent:* Thursday, April 19, 2018 2:55 AM
*To:* wien@zeus.theochem.tuwien.ac.at
*Subject:* Re: [Wien] 'LAPW2: semicore band-ranges too large error' for 
spin-orbit calculation



Thanks, for the reply. I am using intel 2016. I did apply the patch 
get_nloat.patch in SRC_lapwso but I still have the same problem.


Which 2016 ifort?  I haven't used Update 3 (16.0.3.210) but that version 
seemed particularly bad in mailing list posts probably because of the 
unformatted file I/O bug [ 
https://software.intel.com/en-us/articles/read-failure-unformatted-file-io-psxe-16-update-3 
].


Every so often it happens to me that I think I recompiled a change to 
the code, but I make as mistake and the change doesn't get compiled into 
the executable.  Though, maybe this doesn't happen to you.  When I get 
paranoid about that, I remove the existing executable and .o files using 
'make clean'.


In this case for example:

username@computername:~/Desktop$ cd $WIENROOT
username@computername:~/WIEN2k$ ls -l lapwso
-rwxrwxr-x 1 username username 1533555 Apr 18 20:06 lapwso
username@computername:~/WIEN2k$ rm lapwso
username@computername:~/WIEN2k$ cd SRC_lapwso
username@computername:~/WIEN2k/SRC_lapwso$ make clean
rm -f *.o _tmp_.* *.P .real .complex .sequential .parallel *.mod
username@computername:~/WIEN2k/SRC_lapwso$ ls -l get_nloat.f
-rw-rw-r-- 1 username username 682 Apr  2  2014 get_nloat.f
username@computername:~/WIEN2k/SRC_lapwso$ wget 
https://raw.githubusercontent.com/gsabo/WIEN2k-Patches/master/17.1/get_nloat.patch

...
username@computername:~/WIEN2k/SRC_lapwso$ patch -b get_nloat.f 
get_nloat.patch

patching file get_nloat.f
username@computername:~/WIEN2k/SRC_lapwso$ ls -l get_nloat.f
-rw-rw-r-- 1 username username 1782 Apr 18 20:12 get_nloat.f <- Notice 
how the get_nloat.f file changes from 682 to1782 after the patch

username@computername:~/WIEN2k/SRC_lapwso$ cd ..
username@computername:~/WIEN2k$ ./siteconfig
...
   Selection: R
...
    ***
    *  Compile/Recompile programs *
    ***

  A   Compile all programs
  S   Select program

  Q   Quit

  Selection: S
    Which program to recompile? lapwso
...
Compile time errors (if any) were:


Check file   compile.msg   in the corresponding SRC_* directory for the
compilation log and more info on any compilation problem.

  Press RETURN to continue
...
username@computername:~/WIEN2k$ ls -l lapwso
-rwxrwxr-x 1 username username 1520752 Apr 18 20:16 lapwso <- Notice how 
the lapwso file size decreases from 1533555 to 1520752.  However, file 
sizes for the executable generated by the compiler specifically for your 
system might be of different sizes.



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



--

  P.Blaha
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
Email: 

[Wien] Non-magnetic GGA+U+SOC calculations for Sm in Sm2+ valence state in Wien2K

[Anup Shakya]

 Dear Prof. Blaha,

Thank you very much for the reply.

Yes I could see that the occupancy in spin up case is 3  and for spin down
is 3. After that as suggested by you I did
 x lapwdm -up -so
and x lapwdm -dn -so

Then I checked the  case.scfdmup file and I could find the information
about the occupancy of f electrons in spin up as well as spin down which is
more clear than case.dmatup/dn file.

:ORB001:  ORBITAL MOMENT:  0.0  0.0  0.0 PROJECTION ON M
0.0
:SPI001:  SPIN MOMENT:   0.0   0.0   0.0 PROJECTION ON M
0.0

After that I performed runsp -orb -p as suggested in previous posts. But
since I wanted to perform non-magnetic calculations. So using this command
is fine or should I use runsp_c -orb -p??

I performed runsp -orb -p and then afterwards checked the case.scfdmup and
case.scfdmdn files which have changed as shown below:

case.scfdmup

 Density matrix UPUP block, real part.  L= 3
 0.56681  0.0  0.0  0.0  0.42473  0.0  0.0
 0.0  0.00461  0.0  0.0  0.0 -0.00185  0.0
 0.0  0.0  0.32262  0.0  0.0  0.0  0.42473
 0.0  0.0  0.0  0.96033  0.0  0.0  0.0
 0.42473  0.0  0.0  0.0  0.32262  0.0  0.0
 0.0 -0.00185  0.0  0.0  0.0  0.00461  0.0
 0.0  0.0  0.42473  0.0  0.0  0.0  0.56681

case.scfdmdn

Density matrix UPUP block, real part.  L= 3
 0.61086  0.0  0.0  0.0  0.46143  0.0  0.0
 0.0  0.00462  0.0  0.0  0.0 -0.00193  0.0
 0.0  0.0  0.35289  0.0  0.0  0.0  0.46143
 0.0  0.0  0.0  0.96012  0.0  0.0  0.0
 0.46143  0.0  0.0  0.0  0.35289  0.0  0.0
 0.0 -0.00193  0.0  0.0  0.0  0.00462  0.0
 0.0  0.0  0.46143  0.0  0.0  0.0  0.61086

Now, since the occupancy has changed. What should I do? Any suggestions
would be of great help to me.

Anup Pradhan Sakhya (Ph.D.)
___
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