Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

No specific subroutine for the generic ‘nuopc_updatetimestamp’ #89

Closed
platipodium opened this issue Dec 6, 2021 · 16 comments
Closed

No specific subroutine for the generic ‘nuopc_updatetimestamp’ #89

platipodium opened this issue Dec 6, 2021 · 16 comments

Comments

@platipodium
Copy link
Contributor

On branch feature/schism and ubuntu/gcc/openmpi I get:

mpif90 -g -ffree-line-length-none -fno-range-check -fbacktrace  -I/home/lemmen/opt/mod/modg/Linux.gfortran.64.openmpi.ESMF_8_2_0_beta_snapshot_00 -I/home/lemmen/opt/include -I/usr/include -I/usr/include  -I/usr/include -IENS_Cpl -I.  -I/home/lemmen/devel/noaa/CoastalApp/NEMS/src/schism -I/home/lemmen/devel/noaa/CoastalApp/SCHISM/build/include -c module_MEDIATOR.tmp.f90
module_MEDIATOR.tmp.f90:3892:59:

 3892 |     call NUOPC_UpdateTimestamp(NState_AtmExp, clock, rc=rc)
      |                                                           1
Error: There is no specific subroutine for the generic ‘nuopc_updatetimestamp’ at (1)
@ghost
Copy link

ghost commented Dec 10, 2021

@pvelissariou1

@platipodium
Copy link
Contributor Author

This is still a problem, occurring now on my ubuntu ESMF/8.2.0 system @pvelissariou1

@platipodium
Copy link
Contributor Author

Copied from email thread by @pvelissariou1

Without going into the documentation,
It seems that there is a change in the interface for NUOPC_UpdateTimestamp, see below:

ESMF v7.1.0r
-----------
interface NUOPC_UpdateTimestamp
  module procedure NUOPC_UpdateFieldList
  module procedure NUOPC_UpdateAcrossFieldLists
  module procedure NUOPC_FieldBundleUpdateTime
  module procedure NUOPC_StateUpdateTimestamp
  module procedure NUOPC_StateSetTimestamp
end interface

ESMF v8.0.1
-----------
interface NUOPC_UpdateTimestamp
  module procedure NUOPC_UpdateFieldList
  module procedure NUOPC_UpdateAcrossFieldLists
  module procedure NUOPC_FieldBundleUpdateTime
  module procedure NUOPC_StateUpdateTimestamp
end interface

ESMF v8.1.1
-----------
interface NUOPC_UpdateTimestamp
  module procedure NUOPC_UpdateFieldList
  module procedure NUOPC_UpdateAcrossFieldLists
  module procedure NUOPC_FieldBundleUpdateTime
  module procedure NUOPC_StateUpdateTimestamp
end interface

and in the NEMS directory see how NUOPC_UpdateTimestamp is being called.
In NEMS/src/module_MEDIATOR.F90
---------------------------------------------------
#if ESMF_VERSION_MAJOR >= 8
    call NUOPC_SetTimestamp(NState_AtmExp, clock, rc=rc)
#else
    call NUOPC_UpdateTimestamp(NState_AtmExp, clock, rc=rc)
#endif

@platipodium
Copy link
Contributor Author

OK, so the problem is that ESMF_VERSION_MAJOR is not known? At least, it is not defined on the command line:

cpp -P -traditional -DENABLE_SMP -DCHNK_RRTM=8   -DFRONT_ATMESH=ATMESH     -DFRONT_WW3DATA=wav   -DFRONT_SCHISM=schism_nuopc_cap -D'SVN_INFO="(lemmen) Fr 10. Jun 11:16:03 CEST 2022 r581d8bea1ab6 https://github.com/noaa-ocs-modeling/NEMS.git"' -D'CMP_YEAR=2022' -D'CMP_JD=161' module_MEDIATOR.F90 > module_MEDIATOR.tmp.f90
mpif90 -g -ffree-line-length-none -fno-range-check -fbacktrace  -I/home/lemmen/opt/mod/modg/Linux.gfortran.64.openmpi.ESMF_8_2_0_beta_snapshot_00 -I/home/lemmen/opt/include -I/usr/include -I/usr/include  -I/usr/include -IENS_Cpl -I.  -I/home/lemmen/devel/noaa/CoastalApp/ATMESH -I/home/lemmen/devel/noaa/CoastalApp/ATMESH_INSTALL -I/home/lemmen/devel/noaa/CoastalApp/WW3DATA -I/home/lemmen/devel/noaa/CoastalApp/WW3DATA_INSTALL -I/home/lemmen/devel/noaa/CoastalApp/NEMS/src/schism -I/home/lemmen/devel/noaa/CoastalApp/SCHISM/build/include -c module_MEDIATOR.tmp.f90

@platipodium
Copy link
Contributor Author

It seems that NEMS' build system does not include the ESMF_CPPFLAGS, possibly not even about ESMF itself?

@platipodium
Copy link
Contributor Author

So the problem is that the version is not defined in ESMFVersionDefine.h

(base) lemmen@rzcp0209-ubuntu:~/devel/noaa/CoastalApp$ cat NEMS/src/ESMFVersionDefine.h
#if 0
//
// Make this header file available as ESMFVersionDefine.h in order to build
// NEMS against an ESMF installation that contains a reference level NUOPC Layer.
//
#endif

#include "./ESMFConvenienceMacros.h"

@platipodium
Copy link
Contributor Author

In GNUMakefile, the transfer of the version information to CPPFLAGS should be here:

# Loop over all defined variables, calling add_to_cppflags (see above)
# on each.  The $(and ...,) ensures the result is the empty string.
$(and $(foreach var,$(.VARIABLES),$(if $(call startswith,$(var),ESMF_VERSION),$(call add_to_cppflags,$(var)))),)

@platipodium
Copy link
Contributor Author

This can be worked around by exporting ESMF_MAJOR_VERSION=8, but that is not a sustainable solution. Somewhere along the way, the ESMF information is not transferred through the build system.

@pvelissariou1
Copy link
Collaborator

pvelissariou1 commented Jun 10, 2022 via email

@platipodium
Copy link
Contributor Author

@pvelissariou1 , indeed the problem might be in the CoastalPaa rather than in NEMS. On our HPC gnu system levante and on my Desktop gnu system these errors appear. Something related to the shell environment? Here's the module files for my gnu system:

myDIRS="$(cd "$(dirname "$(realpath -s "${BASH_SOURCE[0]}" )" )" && pwd -P)"
myDIRS="${myDIRS} . ${APPMODS_DIR}"
####################

# Install via apt instsall libparmetis-dev
export METIS_DIR=/usr

####################
### (2) Set some environments varaiables related to the loaded
###     modules and required to compile the NEMS application properly.
funcs="$( find ${myDIRS} -type f -iname "PlatformFuncs" | head -n 1 )"
if [ -f "${funcs}" ]; then
  source "${funcs}"

  get_env_hdf5
  get_env_netcdf
fi
unset funcs myDIRS

# apt install libnetcdff-dev libnetcdf-dev libhdf5-openmpi-dev
export NETCDFHOME=/usr
export HDF5HOME=/usr
export METISHOME=/usr
export PARMETISHOME=/usr

export NETCDF_CONFIG=${NETCDFHOME:+${NETCDFHOME}/bin/nc-config}
export NETCDF_INCDIR=${NETCDFHOME:+${NETCDFHOME}/include}
export NETCDF_LIBDIR=${NETCDFHOME:+${NETCDFHOME}/lib}

export ESMFMKFILE=${ESMFMKFILE}

So ESMFMKFILE is defined but somehow gets lost on the way from CoastlApp to NEMS...

@pvelissariou1
Copy link
Collaborator

pvelissariou1 commented Jun 10, 2022 via email

@platipodium
Copy link
Contributor Author

Modules are loaded and ESMFMKFILE is correctly defined on the shell. So, NEMS does not load it despite it being defined.

@pvelissariou1
Copy link
Collaborator

pvelissariou1 commented Oct 11, 2022 via email

@platipodium
Copy link
Contributor Author

Sure, but we have the VIMS meeting at 1 pm if I am not mistaken. I'd be available 12-1pm CT or after the VIMS meeting (from 2pm CT)

@platipodium
Copy link
Contributor Author

This problem occurs also on my Mac laptop with ESMF 8.4 installed:

module_MEDIATOR.tmp.f90:3881:59:

 3881 |     call NUOPC_UpdateTimestamp(NState_AtmExp, clock, rc=rc)
      |                                                           1
Error: There is no specific subroutine for the generic ‘nuopc_updatetimestamp’ at (1)
module_MEDIATOR.tmp.f90:3893:80:

 3893 |         call NUOPC_UpdateTimestamp(NState_AtmExp, clock_invalidTimeStamp, rc=rc)
      |                                                                                1
Error: There is no specific subroutine for the generic ‘nuopc_updatetimestamp’ at (1)
make[1]: *** [GNUmakefile:239: module_MEDIATOR.o] Fehler 1

@platipodium platipodium mentioned this issue Feb 5, 2023
Open
@pvelissariou1
Copy link
Collaborator

Closing the issue. If @platipodium still reports problems we may reopen it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@platipodium @pvelissariou1