NCEP libraries: gfortran 10.2.0 and the argument-mismatch

[timhoar]

GNU Fortran (MacPorts gcc10 10.2.0_5) 10.2.0 is very strict about rank mismatches and such. Putting -fallow-argument-mismatch in the FFLAGS allows the compiler to proceed - but it still throws a ton of warnings, which is a bit of unnecessary chatter in the output log.

Worse ... the NCEP libraries do not build without manual intervention, because they do not use the mkmf.template - they use the NCEP/prep_bufr/install.sh script to build - which does not dynamically use the FFLAGS from the mkmf.template.

The obs_converters/run_tests.csh script queries the mkmf.template for the compiler and then sets some variables that are used by install.sh ... perhaps this can be extended to use the FFLAGS as well.

[nancycollins]

i'll give you some history on why it is how it is. the prepbufr libraries are downloaded from NCEP. they have been updated over the years but the original code is very old. we decided to make as few changes as possible so when a new version was downloaded it wouldn't require redoing a lot of work that would again get lost in the next update. install.sh is what comes with the libs, and the strange directory structure and filename convention (bob.x for executables) is all theirs. the prepbufr obs converter itself is very much based on a dump program that is distributed with the library.

having said that, yes, i snuck some code into install.sh to try to use the "current" compiler if running in a higher level script. i'm not sure if any of the other FFLAGS we set in mkmf.template will cause the libs to not compile. if not, then sure, the same process can be extended, i'd think. users may still want to build just the ncep libs, so install.sh needs to be able to work standalone and not only in a testing environment.

i'll caution people not to try to "fix" the lib code itself unless it won't build. as long as it's working, no one cares and anything done there will be overwritten if a new version is downloaded. if you don't look, you won't be horrified.

[timhoar]

So I am 'discovering' this problem again. Just to recap and to help aid in any possible searches, here is an example of the error:

Error: Rank mismatch between actual argument at (1) and actual argument at (2) (rank-1 and scalar)
../../../assimilation_code/modules/utilities/mpi_utilities_mod.f90:1394:19:

Fixing install.sh to define

elif [ $FCOMP = gnu ] ; then
   ff='gfortran -fallow-argument-mismatch'

fixes that for the NCEP libraries - easy. However - in addition to the NCEP prepbufr libraries, our mpi_utilities_mod.f90 is (still) throwing the errors and requires the -fallow-argument-mismatch flag. We have two choices as far as I can see ... we can either fix the mpi_utilities_mod.f90 code (if possible) - or - put the appropriate values in the mkmf.templates for gfortran and add something to the FAQ (which I cannot find after the document restructuring).

[nancycollins]

i sent this by email to a couple people but really i should have made the comment here so all the discussion is in one place:

i just looked at this code. i'm a bit confused about what gfortran is unhappy about. the arguments to our sum_across_tasks_real() routine are scalar, but they're moved into rank 1 arrays to be passed to MPI_AllReduce because that's what the interface is documented to require.

i'd try to fix the code if i understood what problem it is complaining about.

[hkershaw-brown]

Tim - what is the code you are building that is getting the error?

I can not reproduce the error.
I'm using lorenz_96 and quickbuild.csh -mpi

I'm using gfortran version:
10.1.0 (Cheyenne)
10.3.0 (mac)
11.1.0 (mac)

I'm going to build 10.2.0 to see if it is a problem with 10.2.0.

[timhoar]

Seriously?! I am using GNU Fortran (MacPorts gcc10 10.2.0_5) 10.2.0 the 'standard' mkmf.template.gfortran with the lorenz_96 quickbuild.csh -mpi *0[1131]**cam-fv_even_sphere **~/<3>lorenz_96/work * % mpif90 --version GNU Fortran (MacPorts gcc10 10.2.0_5) 10.2.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. And I'm relatively certain I installed it with: port select --list mpi sudo port select --set mpi mpich-mp-fortran Can you build the NCEP libraries without the switch? That should absolve the mpi portion of the equation, in any event.

[hkershaw-brown]

Ok, I was using openmpi
I do get this error with mpich. Super cool. I think this might be explicit vs. implicit interfaces in the different mpi libraries.

[hkershaw-brown]

I think the mpi_utilities errors are mpich using f77 bindings when you use mpi. Hello world mpi (no dart code) will not compile if you have a mpi_send(integer) mpi_send(real) in the same file.

hello.f90.txt
hello_f08.f90.txt

The f08 mpi module use mpi_f08 follows the fortran standard.
There is a branch mpi_f08 which has a version of mpi_utilites_mod.f90 with mpi_f08 bindings. This will work with mpich and gfortran 10+ (only done a quick test).
The cray window module (cray pointers) could get replaced with iso_c_bindings.

or short term solution: port select --set mpi openmpi-mp-fortran

[hkershaw-brown]

closing this since:

• the mpi is in issue mpich mpif08 #261 (solution is mpi_f08)
• not going to have the NCEP libraries use mkmf.template because the prebuffer libraries are so old.
• adding a note in Complete testing coverage of obs_converters in developer_tests #133 to link to this issue.