Error compiling ROMS with new flag SINGLE_PRECISION (svn928)

[thiago.pdpaula]

Hello all,

I'm not sure this is whether a bug or a particular issue with my enviroment or setup. Anyway, I think it's worth to report.

I have been running my ROMS IS4DVAR application for a while using revision 881.

Now I decided to test the new flag SINGLE_PRECISION of revision 928, which is available since this recent update https://www.myroms.org/projects/src/ticket/789.

I'm using Intel Fortran (IFORT) version 17.0.5 20170817, MPICH library and netCDF4.

However, compiler complains of conflictant declarations in "distribute.F" with the following message:

Code: Select all

cd /home/users/tpdpbr/roms/projetos/4dvar/i4dvar.exp_01/t04/Build; /sw/apps/suse/mpi/intel/mvapich/2.2/bin/mpif90 -c -heap-arrays -fp-model precise -ip -O3 distribute.f90
distribute.f90(283): error #5286: Ambiguous generic interface MP_BCASTF: previously declared specific procedure MP_BCASTF_0DP is not distinguishable from this declaration. [MP_BCASTF_0D]
      SUBROUTINE mp_bcastf_0d (ng, model, A)
-----------------^
distribute.f90(353): error #5286: Ambiguous generic interface MP_BCASTF: previously declared specific procedure MP_BCASTF_1DP is not distinguishable from this declaration. [MP_BCASTF_1D]
      SUBROUTINE mp_bcastf_1d (ng, model, A)
-----------------^
distribute.f90(4364): error #5286: Ambiguous generic interface MP_REDUCE: previously declared specific procedure MP_REDUCE_0DP is not distinguishable from this declaration. [MP_REDUCE_0D]
      SUBROUTINE mp_reduce_0d (ng, model, Asize, A, op_handle)
-----------------^
distribute.f90(4468): error #5286: Ambiguous generic interface MP_REDUCE: previously declared specific procedure MP_REDUCE_1DP is not distinguishable from this declaration. [MP_REDUCE_1D]
      SUBROUTINE mp_reduce_1d (ng, model, Asize, A, op_handle)
-----------------^
compilation aborted for distribute.f90 (code 1)

I'm not very familiar to FORTRAN so forgive my ignorance but I can't see why the procedures are not distinguishable since the argument "A" of mp_bcastf_0dp and mp_bcastf_0d defined in distribute.F are actually of kind real with different precisions, being 'dp' and 'r8', respectively. This kinds are defined in mod_kinds.F as:

Code: Select all

#ifdef ESMF_LIB
!!      integer, parameter :: i1b= ESMF_KIND_I1                !  8-bit
        integer, parameter :: i1b= SELECTED_INT_KIND(1)        !  8-bit
!!      integer, parameter :: i2b= ESMF_KIND_I2                !  8-bit
        integer, parameter :: i2b= SELECTED_INT_KIND(2)        !  8-bit
        integer, parameter :: i4b= ESMF_KIND_I4                ! 16-bit
        integer, parameter :: i8b= ESMF_KIND_I8                ! 32-bit
        integer, parameter :: c8 = SELECTED_REAL_KIND(6,30)    ! 32-bit
        integer, parameter :: dp = ESMF_KIND_R8                ! 64-bit
        integer, parameter :: r4 = ESMF_KIND_R4                ! 32-bit
# ifdef SINGLE_PRECISION
        integer, parameter :: r8 = ESMF_KIND_R4                ! 32-bit
# else
        integer, parameter :: r8 = ESMF_KIND_R8                ! 64-bit
# endif
#else
        integer, parameter :: i1b= SELECTED_INT_KIND(1)        !  8-bit
        integer, parameter :: i2b= SELECTED_INT_KIND(2)        !  8-bit
        integer, parameter :: i4b= SELECTED_INT_KIND(4)        ! 16-bit
        integer, parameter :: i8b= SELECTED_INT_KIND(8)        ! 32-bit
        integer, parameter :: c8 = SELECTED_REAL_KIND(6,30)    ! 32-bit
        integer, parameter :: dp = SELECTED_REAL_KIND(12,300)  ! 64-bit
        integer, parameter :: r4 = SELECTED_REAL_KIND(6,30)    ! 32-bit
# ifdef SINGLE_PRECISION
        integer, parameter :: r8 = SELECTED_REAL_KIND(6,30)    ! 32-bit
# else
        integer, parameter :: r8 = SELECTED_REAL_KIND(12,300)  ! 64-bit
# endif

Compiling with previous or newer versions of ifort (V15, V16, V18), pgi or gfortran raises identical errors.

I also tried to compile the WC13 test case with revision 928. It compiles fine without SINGLE_PRECISION, but fails the same way as with my application when the flag is activated.

I know this feature is quite recent, but has anybody already had an error similar to this?

If is there anything else I should check, like compiler flags or so, please let me know.

Any replies are much appreciated.

Thanks.

[susonic]

Thank you for your report. I also faced with same situation as you mentioned and was about to report.

[arango]

You are doing something wrong or something is weird with the compiler. You need to read carefully the following trac ticket. Notice that even if SINGLE_PRECISION is activated, there are several variables that are still in double precision (dp 64-bit kind parameter) and the r8 kind parameter is redefined to 32-bit floating point variables. Both dp and r8 kind parmeters are used in ROMS regardless if we run in single- or double-precision.

distribute.f90(353): error #5286: Ambiguous generic interface MP_BCASTF: previously declared specific procedure MP_BCASTF_1DP is not distinguishable from this declaration. [MP_BCASTF_1D]

For some reason, your compiler cannot differentiate the module procedure between single- and double-precision, and that's what the error is telling you. I think that it does nothing to do with ROMS. The compiler says that dp and r8 parameters are the same on mod_kinds.F, which is not the case. So the module procedure in distribute.F doesn't know which routine to pick for mp_bcastf. It is that simple!

Code: Select all

      INTERFACE mp_bcastf
# ifdef SINGLE_PRECISION
        MODULE PROCEDURE mp_bcastf_0dp   ! double-precision exchanges
        MODULE PROCEDURE mp_bcastf_1dp   ! double-precision exchanges
# endif
        MODULE PROCEDURE mp_bcastf_0d
        MODULE PROCEDURE mp_bcastf_1d
        MODULE PROCEDURE mp_bcastf_2d
        MODULE PROCEDURE mp_bcastf_3d
        MODULE PROCEDURE mp_bcastf_4d
      END INTERFACE mp_bcastf

If the 1D variable argument to mp_bcastf is single precision, it will use routine mp_bcastf_1d in distribute.F. Contrarily, if it is double-precision it will use mp_bcastf_1dp instead. The compiler was not able to diferentiate!

I did run WC13 in single-precision (IS4DVAR and W4DPSAS) and it works for me. However, it is not recommended. We will work on a mixed precision 4D-Var driver next year. The inner loops can be in single-precision but the outer loops have to be in double-precision. It will require a scripted and split 4D-Var algorithm with two executables.

I just updated the code to correct a small bug when BGQC is activated. See trac ticket.

[susonic]

Thank you for your answer Dr.Arango.
I've got more question.

You mentioned that

If the 1D variable arguement to mp_bcastf is singe precison, it will usee routine mpbcastf_1d in distribute.F.

But my understanding looking at the code is if the single precision is defined, ROMS will use mp_bacastf_1dp instead of mp_bcastf_1d.
Please correct me if I'm wrong.

[arango]

Nope. What I said above is correct If the last argument to the mp_bcastf routine is single- precision it will use mp_bcast_1d, and if it is double-precision it will use mp_bcastf_1dp. Just look the subroutines in distribute.F If you don't understard, you need to check a Fortran 1990, 1995, or 2003 standard manual for how interface or module procedure works.

[thiago.pdpaula]

Thank you very much for the reply.

You are doing something wrong or something is weird with the compiler. You need to read carefully the following trac ticket. Notice that even if SINGLE_PRECISION is activated, there are several variables that are still in double precision (dp 64-bit kind parameter) and the r8 kind parameter is redefined to 32-bit floating point variables. Both dp and r8 kind parmeters are used in ROMS regardless if we run in single- or double-precision.

Indeed. I understand that. What intrigates me is that this issue happens across different systems and compilers, which forces me to perform a review of all the steps I'm taking for compiling, as you suggested. If I figure out what is going on here, I'll post again.

For some reason, your compiler cannot differentiate the module procedure between single- and double-precision, and that's what the error is telling you. I think that it does nothing to do with ROMS.

In that case I apologize for submitting under the "ROMS Bugs" forum. Please feel free to move or archive this discussion.

I did run WC13 in single-precision (IS4DVAR and W4DPSAS) and it works for me. However, it is not recommended...

Thank you for letting me know. I was looking for a way of reducing computational time of the assimilative run. On this regard, I was also advised to try the dual formulation methods of ROMS 4D-VAR module, which I have not done yet.

[tsangwpx]

As of r931, mod_kinds.F does not have a line

Code: Select all

#include "cppdefs.h"

at the beginning. The SINGLE_PRECISION flag is not defined. Adding it back at the beginning of the file will solve the issue.

[jivica]

If you are using SINGLE_PRECISION and wet-dry option then you can't compile the latest version of ROMS.
There is DSIGN problem (at least with gfortran), so after changing DSIGN -> SIGN for
Build/u2dbc_im.f90
Build/v2dbc_im.f90
Build/wetdry.f90
Build/step2d.f90
and ./build_roms.bash -noclean you can get romsM

Have to check solution but have feeling it should be OK.

Cheers,
I.