[Wien] compilation error - reg

Mon May 11 06:11:25 CEST 2020

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 at computername:~/WIEN2k$ lsb_release -a
No LSB modules are available.
Distributor ID:    Ubuntu
Description:    Ubuntu 20.04 LTS
Release:    20.04
Codename:    focal
username at computername:~/WIEN2k$ gfortran-10 -v
...
gcc version 10.0.1 20200411 (experimental) [master revision 
bb87d5cc77d:75961caccb7:f883c46b4877f637e0fa5025b4d6b5c9040ec566] 
(Ubuntu 10-20200411-0ubuntu1)
...
username at 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-bounces at zeus.theochem.tuwien.ac.at>  on behalf of 
>>> Peter Blaha<pblaha at theochem.tuwien.ac.at>
>>> Sent: Saturday, May 9, 2020 8:57 AM
>>> To:wien at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20200510/d38c4033/attachment.html>