how to build land_model_mod.mod?

[edwardhartnett]

The FMScoupler project has a dependency on missing land_model_mod.mod. See NOAA-GFDL/FMScoupler#15.

So I am trying to build land_model_mod.mod so that I can get the autotools build for FMScoupler working.

However, when I build AM4 according to your home rolled build system (a.k.a. your "workflow") it does not build land_model_mod.mod.

find ~/AM4/ -name 'land_model*'
/home/Edward.Hartnett/AM4/src/land_lad2/land_model.F90

How do I get AM4, using your legacy build system, to build land_model_mod.mod?

Thanks!

[thomas-robinson]

@edwardhartnett what compiler are you using? What version of hdf5 are you using? Is the build error a problem with hdf5? Does it fail in tiling_input.F90?

[edwardhartnett]

I can build (or at least try to build) FMScoupler with either GNU or Intel Fortran. I am trying Intel Fortran at the moment.

This is using a new, autotools-based build system.

The error I get is:

mpiifort -DPACKAGE_NAME=\"AM4\" -DPACKAGE_TARNAME=\"am4\" -DPACKAGE_VERSION=\"2.0-development\" -DPACKAGE_STRING=\"AM4\\
 2.0-development\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"am4\" -DVERSION=\"2.0-development\" -DSTDC_H\
EADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_\
H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I.   -I/home/Edwar\
d.Hartnett/local/netcdf-c-4.6.3/include -I/home/Edward.Hartnett/local/netcdf-fortran-4.4.5/include -I/home/Edward.Hartn\
ett/local/FMS/include -I/home/Edward.Hartnett/AM4/exec/land_lad2  -fno-alias -stack_temps -safe_cray_ptr -ftz -assume b\
yterecl -i4 -r8 -nowarn -g -sox -traceback -c -o land_ice_flux_exchange.o land_ice_flux_exchange.F90
land_ice_flux_exchange.F90(31): error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   [LAND_M\
ODEL_MOD]
  use land_model_mod,      only: land_data_type
------^
land_ice_flux_exchange.F90(32): error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   [ICE_MO\
DEL_MOD]
  use ice_model_mod,       only: ice_data_type, land_ice_boundary_type
------^
land_ice_flux_exchange.F90(55): error #6457: This derived type name has not been declared.   [LAND_DATA_TYPE]
    type(land_data_type),         intent(in)    :: Land !< A derived data type to specify land boundary data
---------^
land_ice_flux_exchange.F90(56): error #6457: This derived type name has not been declared.   [ICE_DATA_TYPE]
    type(ice_data_type),          intent(inout) :: Ice !< A derived data type to specify ice boundary data
---------^
land_ice_flux_exchange.F90(57): error #6457: This derived type name has not been declared.   [LAND_ICE_BOUNDARY_TYPE]
    type(land_ice_boundary_type), intent(inout) :: land_ice_boundary !< A derived data type to specify properties
---------^
land_ice_flux_exchange.F90(109): error #6457: This derived type name has not been declared.   [LAND_DATA_TYPE]
    type(land_data_type),           intent(in) :: Land !< A derived data type to specify land boundary data
---------^
land_ice_flux_exchange.F90(110): error #6457: This derived type name has not been declared.   [ICE_DATA_TYPE]
    type(ice_data_type),            intent(in) :: Ice !< A derived data type to specify ice boundary data
---------^
land_ice_flux_exchange.F90(112): error #6457: This derived type name has not been declared.   [LAND_ICE_BOUNDARY_TYPE]
    type(land_ice_boundary_type), intent(inout):: Land_Ice_Boundary !< A derived data type to specify properties and fl\
uxes passed
---------^
land_ice_flux_exchange.F90(107): error #6404: This name does not have a type, and must have an explicit type.   [LAND_I\
CE_BOUNDARY]
  subroutine flux_land_to_ice( Time, Land, Ice, Land_Ice_Boundary )
------------------------------------------------^
land_ice_flux_exchange.F90(117): error #6460: This is not a field name that is defined in the encompassing structure.  \
 [RUNOFF]
    real, dimension(size(Land_Ice_Boundary%runoff,1),size(Land_Ice_Boundary%runoff,2),1) :: ice_buf
-------------------------------------------^
land_ice_flux_exchange.F90(117): error #6158: The structure-name is invalid or is missing.
etc...

[thomas-robinson]

@edwardhartnett you need to build fms, land_lad2, mom6, ice_sis, atmos_phys, and atmos_dyn before you can build coupler. FMS_coupler depends on all of those components.

If land_model_mod.mod is missing, then it's likely that it did not build. If the problem with building the land model is in tiling_input.F90, it is likely an hdf5 issue. I can merge #12 to possibly fix the problem.

[thomas-robinson]

@edwardhartnett I merged #12. This is hopefully resolve issues with compiling the land model with "newer" version of hdf5. Please try to recompile the land and see if it works now.

[edwardhartnett]

OK, thanks for the info! I will keep trying...

[edwardhartnett]

OK, I've updated the code. Now I see a failure like this:

mpiifort -fpp -Wp,-w -I/home/Edward.Hartnett/local/hdf5-1.10.5/include -I/home/Edward.Hartnett/local/netcdf-fortran-4.4\
.5/include  -fno-alias -stack_temps -safe_cray_ptr -ftz -assume byterecl -i4 -r8 -nowarn -g -sox -traceback -fp-model s\
ource -O3 -qopenmp -msse2 -qoverride-limits -I/misc/whome/Edward.Hartnett/AM4/exec/fms  -c -o land_dust.o         land_\
dust.DO_NOT_MODIFY.f90
/misc/whome/Edward.Hartnett/AM4/src/land_lad2/predefined_tiles/tiling_input.F90(31): error #6683: A kind type parameter\
 must be a compile-time constant.   [HID_T]
 integer(hid_t) :: h5id8
---------^
/misc/whome/Edward.Hartnett/AM4/src/land_lad2/predefined_tiles/tiling_input.F90(45): error #6683: A kind type parameter\
 must be a compile-time constant.   [HID_T]
 integer(hid_t) :: h5id8
---------^
/misc/whome/Edward.Hartnett/AM4/src/land_lad2/predefined_tiles/tiling_input.F90(59): error #6683: A kind type parameter\
 must be a compile-time constant.   [HID_T]
integer(hid_t) :: varid,dsid,grpid
--------^
/misc/whome/Edward.Hartnett/AM4/src/land_lad2/predefined_tiles/tiling_input.F90(62): error #6683: A kind type parameter\
 must be a compile-time constant.   [HSIZE_T]
  integer(hsize_t) :: dims(2),maxdims(2)
----------^
/misc/whome/Edward.Hartnett/AM4/src/land_lad2/predefined_tiles/tiling_input.F90(64): error #6683: A kind type parameter\
 must be a compile-time constant.   [HSIZE_T]
  integer(hsize_t) :: dimsm(2),count(2),offset(2)
----------^
/misc/whome/Edward.Hartnett/AM4/src/land_lad2/predefined_tiles/tiling_input.F90(65): error #6683: A kind type parameter\
 must be a compile-time constant.   [HID_T]
  integer(hid_t) :: memid
----------^
/misc/whome/Edward.Hartnett/AM4/src/land_lad2/predefined_tiles/tiling_input.F90(100): error #6683: A kind type paramete\
r must be a compile-time constant.   [SIZE_T]
  integer(size_t),intent(inout) :: buf_len
----------^
/misc/whome/Edward.Hartnett/AM4/src/land_lad2/predefined_tiles/tiling_input.F90(103): error #6683: A kind type paramete\
r must be a compile-time constant.   [HID_T]
integer(hid_t) :: grpid,cell_grpid,dstid
--------^
/misc/whome/Edward.Hartnett/AM4/src/land_lad2/predefined_tiles/tiling_input.F90(106): error #6683: A kind type paramete\
r must be a compile-time constant.   [HID_T]
  integer(hid_t) :: fapl
----------^

[thomas-robinson]

@edwardhartnett hid_t and size_t are both defined in hdf5. I cloned and compiled the AM4 code with hdf5/1.10.4 and hdf5/1.8.16, and I didn't have this problem. It looks like you have the hdf5 include path, so I'm not sure why you are getting this problem. Did you pull the latest changes to the master branch after I merged in #12?

[nikizadehgfdl]

@thomas-robinson I am having this same issue on lscsky50-d with Inetl19.
-I cloned AM4 master and typed make
-It complained that it could not find hdf.h so I added the following line to templates/intel.mk
INCLUDES = -I/opt/hdf5/1.10.1/INTEL/include
-It passed that point but stopped somewhere else

mpiifort -fpp -Wp,-w -I/opt/hdf5/1.10.1/INTEL/include -I/opt/netcdf/4.6.1/INTEL/include  -fno-alias -stack_temps -safe_cray_ptr -ftz -assume byterecl -i4 -r8 -nowarn -g -sox -traceback -fp-model source -O3 -qopenmp -msse2 -qoverride-limits -I/home/Niki.Zadeh/AM4/exec/fms  -c -o soil.o         soil.DO_NOT_MODIFY.f90
/home/Niki.Zadeh/AM4/src/land_lad2/soil/soil.F90(71): error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   [HILLSLOPE_HYDROLOGY_MOD]
use hillslope_hydrology_mod, only: hlsp_hydro_lev_init, hlsp_hydrology_2, &
----^
/home/Niki.Zadeh/AM4/src/land_lad2/soil/soil.F90(71): error #6580: Name in only-list does not exist or is not accessible.   [HLSP_HYDRO_LEV_INIT]
use hillslope_hydrology_mod, only: hlsp_hydro_lev_init, hlsp_hydrology_2, &
-----------------------------------^
/home/Niki.Zadeh/AM4/src/land_lad2/soil/soil.F90(71): error #6580: Name in only-list does not exist or is not accessible.   [HLSP_HYDROLOGY_2]
use hillslope_hydrology_mod, only: hlsp_hydro_lev_init, hlsp_hydrology_2, &
--------------------------------------------------------^
/home/Niki.Zadeh/AM4/src/land_lad2/soil/soil.F90(72): error #6580: Name in only-list does not exist or is not accessible.   [STIFF_EXPLICIT_GWUPDATE]
     stiff_explicit_gwupdate
-----^

Note, there is no hillslope_hydrology_mod in this code base.

[nikizadehgfdl]

hillslope_hydrology_mod is in the repo, but something removed it from src/!!!

 lscsky50-d: /home/Niki.Zadeh/AM4/src % git status
# On branch master
# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   ../exec/templates/intel.mk
#       deleted:    land_lad2/soil/hillslope_hydrology.F90

I did a git checkout land_lad2/soil/hillslope_hydrology.F90 and the compile went OK!

[markyoder]

Would it be possible to include some improved documentation for compiling AM4? The Makefile and templates are a great start, but they seem to have features specific to the system on which they were built. It seems to be implied that mkmf can be used to generate new makefiles, but there are details that need to be resolved -- like building the modules independently. What would it take to set up a Configure script or CmakeLists? Even without those standard build tools, a general explanation of the build process would be extremely helpful. I expect, with the new HPCs coming online soon -- and many of them AMD, not Intel based, there is going to be a lot of recompiling being done in the next few months, and the existing Makefiles, with hard-coded options, etc., will not work correctly.

[thomas-robinson]

@markyoder I have sort of an unsatisfying answer for you. TLDR: open a new issue and request what you want specifically.

The Makefiles were indeed generated using list_paths and mkmf. list_paths lists the paths of the files in folder and any subfolders. mkmf resolves the dependancies of the modules, and generates a Makefile based on those dependancies. They should work on any system. The Makefiles also reference a template included in the templates directory. The template is specific for the compiler. The intel.mk file should work, and gnu.mk file may work.

cmake and autotools are great tools for compiling, and are being used or are in the process of being added to some of the components of this model. As you can tell from this issue, compiling the code isn't as straightforward as it could be, so there are some snags to adding a more automated build system.

The intent of this repository was to provide a mechanism to reproduce the scientific results of the AM4 papers. With that said, if you have a feature or documentation request, it would be great if you could open a separate issue on the request, and then I can address it more directly and hopefully spend a little bit of time to add it.

[markyoder]

Thanks Thomas. I guess it would be nice if the documentation just said, "modify the templates and use these makefiles." There are other related codes where mkmf is part of the compile script, and so the discussion of mkmf is a little bit misleading -- or at lest the best strategy is not abundantly clear.
I eventually made it work, after making some expected modifications to the template file and adding a script-wrapper to use the Makefile to compile each component independently. I think there are some missing dependencies (probably revisions in the code since the makefiles were generated), so 1) the compile can trip over itself on a parallel build, 2) I think it was the the land_lad2 module has some unrecognized dependencies on one or more of the other modules. I changed the order in which the modules were compiled and was then able to compile each component separately in parallel successfully. I can put that script into a PR if you like, or you can find it on my fork: https://github.com/jeffersonscientific/AM4
Thanks again for the response!