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@computername:~/Desktop/test$ ls
test.f
username@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@computername:~/Desktop/test$ gfortran -ffree-form -O2
-ftree-vectorize -march=native -ffree-line-length-none
-ffpe-summary=none test.f -o test
username@computername:~/Desktop/test$ ./test
username@computername:~/Desktop/test$ cat test1.vorbup
2 1107 0.000000E+00 nmod, nsp, natorb, muB*Bext (Ry), spin up
username@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@computername:~$ cd $WIENROOT/SRC_orb
username@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@computername:~/WIEN2k/SRC_orb$ patch -b init.f init.patch
patching file init.f
username@computername:~/WIEN2k/SRC_orb$ cd ..
username@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
