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

[Gavin Abo]

I forgot to mention that init.patch will only work for WIEN2k 19.1, 
because SRC_orb was changed in WIEN2k 18.1.  However, due to the other 
fixes and improvements mentioned on the WIEN2k updates page [1] such as 
to SRC_lapwso for SOC it would be recommended to use 19.1 instead of 17.1.

[1] http://susi.theochem.tuwien.ac.at/reg_user/updates/

On 11/14/2019 2:35 AM, Gavin Abo wrote:
>
> 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 convince 
> 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/bd5b557e/attachment.html>