[Wien] Bug in WIEN2k for more than 100 atoms running with SOC+OP

[Gavin Abo]

With my current computer system, I expect that I will be unable to test 
as needed for this with greater than 100 atoms, which is why you'll need 
to test the fix and let me know how it goes.

However, the following Fortran test file might be enough to convenience 
that init.patch will work as intended.

username at computername:~/Desktop/test$ ls
test.f
username at computername:~/Desktop/test$ cat test.f
       program init_test

       character*4     spin(-1:2)
       common/updn/    nup
!      common/opr/     nmod,natorb
       integer nmod,natorb
!      common/opr/   Bexten
       real*8  Bexten

       nmod=2
       nup=1
       natorb=107
       Bexten=0.000000E+00
       spin(1) ='up  '

       OPEN(1,file='test1.vorbup')
       OPEN(12,file='test12.vorbup')

       write(1,197)nmod,nup,natorb,Bexten,spin(nup)

       write(12,198)nmod,nup,natorb,Bexten,spin(nup)

197   format(3i3,e14.6,' nmod, nsp, natorb,', &
              ' muB*Bext (Ry), spin ',a4)

198   format(i3,i3,i4,e14.6,' nmod, nsp, natorb,', &
              ' muB*Bext (Ry), spin ',a4)

       CLOSE(1)
       CLOSE(12)

       END
username at computername:~/Desktop/test$ gfortran -ffree-form -O2 
-ftree-vectorize -march=native -ffree-line-length-none 
-ffpe-summary=none test.f -o test
username at computername:~/Desktop/test$ ./test
username at computername:~/Desktop/test$ cat test1.vorbup
   2 1107  0.000000E+00 nmod, nsp, natorb, muB*Bext (Ry), spin up
username at computername:~/Desktop/test$ cat test12.vorbup
   2 1 107  0.000000E+00 nmod, nsp, natorb, muB*Bext (Ry), spin up

On 11/14/2019 1:58 AM, Gavin Abo wrote:
>
> I made a mistake.  What I suggest trying is:
>
> 198   format(i3,i3,i4,e14.6,' nmod, nsp, natorb,', &
>              ' muB*Bext (Ry), spin ',a4)
>
> 1. Backup your calculation files first.
>
> 2. Then, I put a patch that you may test at 
> https://github.com/gsabo/WIEN2k-Patches/tree/master/19.1 that can be 
> applied with the following.
>
> username at computername:~$ cd $WIENROOT/SRC_orb
> username at computername:~/WIEN2k/SRC_orb$ wget 
> https://raw.githubusercontent.com/gsabo/WIEN2k-Patches/master/19.1/init.patch
> ...
> 2019-11-14 01:47:40 (3.73 MB/s) - ‘init.patch’ saved [117/117]
>
> username at computername:~/WIEN2k/SRC_orb$ patch -b init.f init.patch
> patching file init.f
> username at computername:~/WIEN2k/SRC_orb$ cd ..
> username at computername:~/WIEN2k$ siteconfig
> ...
>   Selection: R
> ...
>      Selection: S
>    Which program to recompile? orb
> ...
> 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.
> ...
>   Selection: Q
>
>
> On 11/13/2019 7:49 PM, Gavin Abo wrote:
>>
>> It looks like what you have reported affects WIEN2k 17.1 - 19.1.  
>> Have you tried changing SRC_orb\init.f followed by recompiling to see 
>> if that fixes the problem or not?  In other words, you might just 
>> need to change i3 to i4 [1].
>>
>>       write(12,198)nmod,nup,natorb,Bexten,spin(nup)
>>
>> 198   format(3i3,e14.6,' nmod, nsp, natorb,', &
>>              ' muB*Bext (Ry), spin ',a4)
>>
>> 198   format(i3,i4,i3,e14.6,' nmod, nsp, natorb,', &
>>              ' muB*Bext (Ry), spin ',a4)
>>
>> [1] 
>> https://software.intel.com/en-us/fortran-compiler-developer-guide-and-reference-format-specifications
>>
>> On 11/13/2019 4:49 PM, Hernandez, Sarah Christine wrote:
>>>
>>> Hello!
>>>
>>> I wanted to bring to your attention a bug in WIEN2k. I haven’t 
>>> upgraded to the newest version and maybe this has been fixed, but I 
>>> would like to bring it to your attention. I am currently using 
>>> version 17.1.
>>>
>>> I have been trying to run a 107 atom system with SOC and orbital 
>>> polarization. When the “x orb –up” and “x orb –dn” commands are 
>>> invoked  the *.vorbup and *.vorbdn files read at the top “2  1107  
>>> 0.000000E+00 nmod, nsp, natorb, muB*Bext (Ry), spin up” and ”2 -1107 
>>> 0.000000E+00 nmod, nsp, natorb, muB*Bext (Ry), spin down,” 
>>> respectively. This can easily be fixed if there is a space between 
>>> the 1 and 107, such that it reads “2 1 107 0.000000E+00 nmod, nsp, 
>>> natorb, muB*Bext (Ry), spin up.” I have tried this small fix and I 
>>> am able to finish the SCF cycle without getting an error in lapwso 
>>> –up -orb, but it is bothersome to fix it every time before it 
>>> reaches lapwso –up –orb.
>>>
>>> Please let me know if this has been fixed in the most updated 
>>> version 19.1, if you will consider fixing this in a future version, 
>>> or if there is another fix instead of me manually putting in the 
>>> space while it is running.
>>>
>>> Thank you,
>>>
>>> Sarah Hernandez
>>>
>>> Sarah C. Hernandez, Ph.D.
>>>
>>> Los Alamos National Laboratory
>>>
>>> MST-16: Nuclear Materials Science
>>>
>>> P.O. Box 1663 MS E574
>>>
>>> Los Alamos, NM  87545
>>>
>>> Office: 505-667-9520
>>>
>>> Cell: 505-500-2788
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20191114/6729ace8/attachment.html>