Thanks, you are correct in this case about .eq. being the proper choice.
Today, I did an upgrade from Ubuntu 18.04 LTS to the April 2020 release
of Ubuntu 20.04 LTS [1].
I was able to compile WIEN2k 19.2 using the stable gfortran 9.3.0 of
Ubuntu 20.04 LTS successfully.
Since it is easy to install the developmental gfortran 10 [2] using
"sudo apt install gfortran-10" in Ubuntu 20.04 LTS, I compiled the tetra
program with that and it worked fine too as seen below. Something that
I have noticed is that in my compile.msg for SRC_tetra I have "76
| DO 30 K=1,KMAX" for a warning that does not affect the compile
but in the compile.msg at [3] that Dr. Elumalai sent there is "73
| DO 30 K=1,KMAX" that seems to suggest the same warning occurred
at different line numbers of 76 and 73, respectively. Thus,
SRC_tetra/ados.f file the Dr. Elumalai has is most likely different from
the one I'm using. I'm using the original file that is part of
WIEN2k_19.2.tar that I got today from the Code download [4] area of the
WIEN2k website.
Of note, the full WIEN2k 19.2 compiled successfully with gfortran 10,
but the -fallow-invalid-boz and -fallow-argument-mismatch [5] compiler
options [6] were needed to compile some of the modules.
[1]
https://ubuntu.com/tutorials/tutorial-upgrading-ubuntu-desktop#1-before-you-start
[2]
https://gcc.gnu.org/wiki/GFortran/News#gfortran_10_.28current_development_version.29
[3]
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg20025.html
[4] http://www.wien2k.at/reg_user/index.html
[5] https://github.com/Unidata/netcdf-fortran/issues/212
[6]
https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gfortran/Fortran-Dialect-Options.html#Fortran-Dialect-Options
username@computername:~/WIEN2k$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04 LTS
Release: 20.04
Codename: focal
username@computername:~/WIEN2k$ gfortran-10 -v
...
gcc version 10.0.1 20200411 (experimental) [master revision
bb87d5cc77d:75961caccb7:f883c46b4877f637e0fa5025b4d6b5c9040ec566]
(Ubuntu 10-20200411-0ubuntu1)
...
username@computername:~/WIEN2k$ ./siteconfig
...
Selection: R
...
Selection: S
Which program to recompile? tetra
...
SRC_tetra ...
...
gfortran-10 -ffree-form -O2 -ftree-vectorize -march=native
-ffree-line-length-none -ffpe-summary=none -fallow-invalid-boz
-fallow-argument-mismatch -c ados.f
ados.f:76:30:
76 | DO 30 K=1,KMAX
| 1
Warning: Fortran 2018 deleted feature: Shared DO termination label 30 at (1)
ados.f:86:72:
86 | 10 F(I,KP)=FC(I,KPP,JJ)
| 1
Warning: Fortran 2018 deleted feature: DO termination statement which is
not END DO or CONTINUE with label 10 at (1)
ados.f:87:24:
87 | 20 D(KP)=EBS(KPP,JJ)
| 1
Warning: Fortran 2018 deleted feature: DO termination statement which is
not END DO or CONTINUE with label 20 at (1)
...
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.
On 5/9/2020 9:18 AM, Peter Blaha wrote:
This is an if between 2 integers and for that .eq. is the proper
choice.
Only for comparison of logical variables some "clever" informatic guys
have invented .eqv. instead of the old f77 standard.
Another possibility is that the .eq. in the if statement is
problematic. It's a little surprising that it even compiles as
usually the .eq. works fine for ifort but does not work for
gfortran. For both ifort and gfortran to work, we have been having
to change .eq. to .eqv.:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18770.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg11545.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18762.html
The information at the following links might be of interest:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18767.html
https://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Equivalence-Versus-Equality.html#Equivalence-Versus-Equality
https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gfortran/Bitwise-logical-operators.html#Bitwise-logical-operators
On 5/9/2020 3:34 AM, Tran, Fabien wrote:
If the suggestion of P. Blaha does not help, remove "doit= .true."
and rewrite it manually. Maybe there is some hidden character which
perturbs the line.
________________________________________
From: Wien<wien-boun...@zeus.theochem.tuwien.ac.at> on behalf of
Peter Blaha<pbl...@theochem.tuwien.ac.at>
Sent: Saturday, May 9, 2020 8:57 AM
To:wien@zeus.theochem.tuwien.ac.at
Subject: Re: [Wien] compilation error - reg
Which version of gfortran are you using ?
Maybe the newest gfortran is "buggy" or is using some newest fortran
standard which has eliminated the default types of fortran.
My gfortran-8 compiles this without problem.
The offending statement:
ados.f:79:48:
79 | if(kpp.eq.kselect.and.kselect.gt.0) doit= .true.
| 1
Error: Cannot convert LOGICAL(4) to REAL(4) at (1)
looks innocent to me. kpp and kselect are by default integers.
Maybe you can switch-off the 2018 standard somewhere, or try to enclose
the 2 parts of the if with further brackets like:
if((kpp.eq.kselect).and.(kselect.gt.0)) doit= .true.
Am 09.05.2020 um 04:50 schrieb Viswanathan Elumalai:
Dear Sir/Mam
Greetings
I had error while compiling the wien2k 19.2 version. I could not solve
it from my end. I searched in wien mail list, I did not see any report
in this regards. I copied the error message here and attached the
corresponding compile file.
SRC_tetra/compile.msg:Error: Cannot convert LOGICAL(4) to REAL(4)
at (1)
SRC_tetra/compile.msg:make: *** [Makefile:108: ados.o] Error 1
I am looking forward your reply.
with best regards
Dr. Viswanathan Elumalai,
Assistant Professor in Physics
_______________________________________________
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
