Compilation with gfortran

i.s.ger · 2022-02-05 20:23:28

Dear Lian Lu,

I tried to compile MultiWFN (noGUI version) with gfortran compiler for non-x86 architecture since ifort is not available there.

I found some mistakes during the porting process:

1) `integer,allocatable :: skippair(:)` at excittrans.f90:1136 should be `logical,allocatable :: skippair(:)`
See at line excittrans.f90:1207:
`skippair=.false.`

2) `if (excdir(iexcitorb)==2) strtmp1=" <-"` at excittrans.f90:4379 should be `if (excdir(iexcitorb)==2) strdir=" <-"`
`strtmp1` is not declared as a character variable

3) `read(*,"(a)") radfilename` at population.f90:794 reads to `real*8` variable, since there is no type declaration of `radfilename` at the beginning of routine. `radfilename` should be declared as `character(len=200) :: radfilename`

Also, there is a couple of hard-to-understand errors that arise when someone tries to use gfortran:

4) at visweak.f90:326, the `\` is at the end of the line that leads to comment out the next line
`real*8,allocatable :: dg_intra(:,:,:) !delta-g_intra of fragments`
and as a result, `dg_intra` has only `real*8` type according to `implicit real*8`.
That is specific to the GCC preprocessor. Could you please remove that symbol?

5) at grid.f90:821, `integer function ifgridortho` is declared without parentheses. Could you please add them?
It should be `integer function ifgridortho()` at the end.

Additionally, most of the changes for making possible compilation with gfortran can be done by applying a couple sed-scripts:

sed -i "s/==.true./.eqv..true./" *.f90 sed -i "s/==.false./.eqv..false./" *.f90 sed -i 's/"A+B"," A"," B"/"A+B"," A "," B "/' GUI.f90 sub.f90 util.f90

That would be great if these scripts will be applied to MultiWFN source code.

Also, there is one more patch for compiling define.f90 using gfortran:
0001-Fix-compilation-errors-in-define.f90.patch.txt

That is not the full list of patches, which are required, but these will extremely decrease work for porting of new versions of MultiWFN.

Best regards,
Igor

sobereva · 2022-02-06 03:24:15

Dear Igor,

Thank you for pointing out these problems.

The issues (1), (2), (3), (4), (5) have been fixed, and I have correspondingly updated Multiwfn packages on Multiwfn website.

Regarding the use of the sed-scripts and your patch, I have mentioned them in "COMPLIATION_METHOD.txt" in source code package to faciliate users compiling Multiwfn with gfortran (they are not applied to official source code because I believe they are mostly special requirement of gfortran compiler rather than that of Fortran).

Best regards,

Tian

i.s.ger · 2022-02-06 03:56:40

Dear Tian Lu,

Thank you!

According to Fortran 2003 standard (draft is available here:https://j3-fortran.org/doc/year/04/04-007.pdf), for logical comparison, `.EQV.` or `.NEQV.` operators should be used. See 7.2.4 on page 135: there are no available `==` operators. That is the reason for the first two sed-hacks.

I will look for character array initialization in Fortran standard.

Best regards,
Igor

sobereva · 2022-02-06 04:22:29

Dear Igor,

Thank you for mentioning this point.
Using .eqv. and .neqv. heavily contradicts my habit and it is evidently not as convenient as simply using == and /= , ifort doesn't have such a somewhat weird requirement. So, please still use patch to rectify it if compiling Multiwfn using gfortran.

Best regards,

Tian

i.s.ger · 2022-02-06 04:50:44

Dear Tian Lu,

Array initialization is described in 4.7 on page 67 in Fortran 2003 standard.

Mostly, MultiWFN uses R465 statement.

array-constructor is (/ ac-spec /)

where `ac-spec` is

ac-spec is type-spec :: or [type-spec ::] ac-value-list

So, for MultiWFN, most popular declaration is (/ ac-value-list /)

Then, the standard says: If `type-spec` is omitted, each `ac-value` expression in the array constructor shall have the same length type parameters.

That is the reason why gfortran says a lot of errors in array initializations where parameters do not have the same lengths.

Another possible fix of gfortran compilation is provide `type-spec` in each array declaration, where errors are. For example (see also note 4.72):

clrtransname(0:18)*50=(/ character(len=50) :: "Rainbow & white/black for out-of-limit data","Rainbow","Reversed rainbow","Rainbow starting from white","Spectrum","Reversed Spectrum","Grey","Reversed Grey","Blue-White-Red",& "Red-White-Blue","Blue-Green-Red","Red-Green-Blue","White-Dark red","Black-Orange-Yellow","White-Dark green","Black-Green","White-Dark blue","Black-Blue-Cyan","Viridis" /)

> Using .eqv. and .neqv. heavily contradicts my habit and it is evidently not as convenient as simply using == and !=

By the way,

if(alive==.true.)

can be rewritten as

if(alive)

That is acceptable by the standard. I hope, you will find it useful.

Best regards,
Igor

sobereva · 2022-02-06 19:50:44

Dear Igor,

Thank you again. I just updated Multiwfn code on Multiwfn website. I have modified all codes to avoid expicitly using ==.true. and ==.false. I also carefully looked through all codes to rectify all declaration problems of string arrays.

Best regards,

Tian

i.s.ger · 2022-02-06 22:11:27

Dear Tian Lu,

Thank you so much!
The count of compilation errors is decreased significantly!

I found that issue (5) is not fixed in the current version of the Multiwfn code.

One more error continues to be in define.f90:

define.f90:360:52: 360 | character :: graphformat*4="png ",graphformatname*4(9)=(/ "png ","gif ","tiff","bmp ","ps ","eps ","pdf ","wmf ","svg " /) | 1 Error: Syntax error in data declaration at (1)

I do not know why gfortran does not understand such constructions. It looks correct.
Anyway, Fortran 2003 Standard says that CHARACTER* is the obsolescent feature (see Annex B.2.7).

It can be replaced with

character(len=4) :: graphformat="png ",graphformatname(9)=(/ "png ","gif ","tiff","bmp ","ps ","eps ","pdf ","wmf ","svg " /)

Similar errors are at fileIO.f90. At line 5293:

character bondstr*6(ncenter),anglestr*6(ncenter),dihstr*6(center)

and at line 6666 (basname):

character :: method*20="PBE",basname*30(-10:30)=" ",PBCdir*4="XYZ "

These expressions can be replaced with:

character(len=6) bondstr(ncenter),anglestr(ncenter),dihstr(center)

and at line 6666 (basname):

character :: method*20="PBE",PBCdir*4="XYZ " character(len=30) :: basname(-10:30)=" "

(`len=`) can be skipped.

Gfortran also found one more place where logical comparison is `==` at line 261 of basin.f90:

where (interbasgrid==0) cubmattmp=0

interbasgrid is logical variable. This error can be fixed as:

where (interbasgrid==.false.) cubmattmp=0

or even:

where (.not.interbasgrid) cubmattmp=0

Also, could you please declare `i` in defvar as `private` for avoiding spreading it in others modules? For example, right after `use` statement:

use deftype integer, private :: i

Best regards,
Igor

sobereva · 2022-02-06 22:24:45

Dear Igor,

I have updated Multiwfn source code package again, all of them have been fixed.

Best regards,

Tian

i.s.ger · 2022-02-06 23:04:48

Dear Tian Lu,

Thank you!

I have one more patch for fixing build errors with gfortran:
0001-Fix-compilation-errors-with-gfortan.patch.txt

It should work both with ifort and gfortran. That should be the end.

One more patch adds gfortran-build-related files:
0002-Add-compilation-with-gfortran.patch.txt
Note:
1) It does not apply any optimization level
2) Only several features are tested*
3) openblas is used (can be changed manually to another BLAS/LAPACK implementation)
4) at noGUI_gfortran some additional sed-hacks are:

sed "s/directory=/file=/" *.f90 -i sed "/kmp_[sg]et_stacksize_s/Id" Multiwfn.f90 -i sed "/mkl_set_num_threads/Id" Multiwfn.f90 -i

*Tested features:
- Integration of rho, grad, lapl, G(r), some user-defined functions (not presented in the current build)
- Output of cube files
- Computation of functions along the line
- Reduced Density Functions

Do you have any non-manual tests of Multiwfn?

Best regards,
Igor

sobereva · 2022-02-07 03:04:51

Dear Igor,

Great work!
Unfortunately, current there is no test sets and automatic testing script for Multiwfn.
Gfortran users are suggested to reproduce relevant examples in Chapter 4 of Multiwfn manual. If the result in the manual can be reproduced, that means corresponding function work normally.

Best regards,

Tian

sobereva · 2022-02-07 03:14:35

Considering that in the future the official source code of Multiwfn will be modified, which may make the patches in #9 no longer work, I have backed up the current latest version as ://www.umsyar.com/multiwfn/res/Multiw … -Feb-7.zip. People who use the aforementioned patches please download this source code package.

i.s.ger · 2022-02-14 05:23:01

Dear Tian Lu,

There is an actual patch for the latest version of MultiWFN for begin it be compiled with gFortran. That should work both for gFortran and Intel Fortran compiler.

0001-Fix-gfortran-builds.patch.txt

Could you please apply it to the current source code?

Best regards,
Igor

sobereva · 2022-02-14 07:19:36

Dear Igor,

I have applied the first two changes to official source code. Unfortunately, if the third one is applied, the progress bar cannot be normally updated during calculation, therefore the third one cannot be applied if there is no ideal substitute.

Best regards,

Tian

i.s.ger · 2022-05-12 03:04:12

Dear Tian Lu,

There is a new patch for fixing compilation issues for gfortran:0001-Fix-compilation-issues-for-gfortran.patch.txt

With fixing inquire statement issues and applying an OpenMP-related patch, there is no problem building Multiwfn using gfortran.

Best regards,
Igor

sobereva · 2022-05-12 16:48:46

Dear Igor,

Thank you, the patch has been incorporated to official source code (will be updated on Multiwfn website soon). The progress bar can update normally.

Best regards,

Tian

Multiwfn forum

#12022-02-05 20:23:28

Compilation with gfortran

#22022-02-06 03:24:15

Re: Compilation with gfortran

#32022-02-06 03:56:40

Re: Compilation with gfortran

#42022-02-06 04:22:29

Re: Compilation with gfortran

#52022-02-06 04:50:44

Re: Compilation with gfortran

#62022-02-06 19:50:44

Re: Compilation with gfortran

#72022-02-06 22:11:27

Re: Compilation with gfortran

#82022-02-06 22:24:45

Re: Compilation with gfortran

#92022-02-06 23:04:48

Re: Compilation with gfortran

#102022-02-07 03:04:51

Re: Compilation with gfortran

#112022-02-07 03:14:35

Re: Compilation with gfortran

#122022-02-14 05:23:01

Re: Compilation with gfortran

#132022-02-14 07:19:36

Re: Compilation with gfortran

#142022-05-12 03:04:12

Re: Compilation with gfortran

#152022-05-12 16:48:46

Re: Compilation with gfortran

Board footer