[QUESTION] Compiling GCHP failed about gchp_legacy HOT 5 CLOSED

Hi Lei,
Unfortunately the GCHP compile log for the 12 series of releases is difficult to parse. We are moving to a CMake build system for 13.0.0, to be released later this year, which will make figuring out compile errors much easier.

In the meantime, the best way to figure out the build problem is to search for string "making install" in the file. Each one should have a blank line above it, and the last compile messages for a given component above that. If you go through each one, starting with the first instance found in the file, and inspect the last compile messages per component, you can identify which MAPL component was first to fail to build. That is the key to finding the original problem.

In your case it is GMAO_pFIO, as found with this result:

gmake[9]: *** No rule to make target `pfio_messagevectorutilmod.mod', needed by `BaseServer.o'.  Stop.
gmake[9]: *** Waiting for unfinished jobs....
gmake[9]: Leaving directory `/home/zhulei/GC/Code.gchp/GCHP/Shared/GMAO_pFIO'
gmake[8]: *** [install] Error 2
gmake[8]: Leaving directory `/home/zhulei/GC/Code.gchp/GCHP/Shared/GMAO_pFIO'

Making install in /home/zhulei/GC/Code.gchp/GCHP/Shared/MAPL_Base

Looking higher up in the file for the first error message during compilation of GMAO_pFIO, I see this:

/home/zhulei/gFTL/include/templates/vector.inc:37:10: fatal error: templates/type_set_use_tokens.inc: No such file or directory
37 | #include "templates/type_set_use_tokens.inc"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It appears that the gFTL library files are not found, indicating either that you did not successfully download and build gFTL prior to run, or you have an incorrect path to the library.

What does the symbolic link to gFTL point to in your run directory? It should point to your gFTL/install directory. If that is correct, go to that directory and check that you have directories include/templates and include/types, and that those directories contain *.inc files, including the one listed in the error message above. If they do not, try redownloading and building gFTL following the wiki instructions here.

from gchp_legacy.

It should point to your gFTL/install directory. If that is correct, go to that directory and check that you have directories include/templates and include/types, and that those directories contain *.inc files, including the one listed in the error message above

Hi Lizziel,

Thank you very much for your help. You are right - the previous error was caused by gFTL path. In GCHP run dir, gFTL was linked to the home dir of gFTL, but not to gFTL/install. After fixing this, the previous error was resolved. Maybe we could make a note about this on GCHP wiki.

However, the compiling process failed again. I checked the compile.log by tracing "making install" and "error". It seems the compiling failed at "MAPL_ExtDataGridCompMod.F90" (Line 5613, ignored) and/or "FVdycoreCubed_GridComp" (Line 14507). I doubt that it may be related to the mpi fortran compiler I used. I would be really appreciated it if you may take another look.

Thanks!
Lei
gchp.compile.log

from gchp_legacy.

Hi Lei, @zhu-group,

These are the two problems I am seeing that I think you are referring to:

MAPL_ExtDataGridCompMod.F90:5081: error: unterminated argument list invoking macro "_ASSERT"
 5081 |  END MODULE MAPL_ExtDataGridCompMod

and

FV_StateMod.F90:3991:19:

 3991 |       do 500 i=1,im
      |                   1
Warning: Fortran 2018 deleted feature: Shared DO termination label 500 at (1)

The first error has to do with misinterpretation of code within the MAPL macro _ASSERT. The macro is written in C and different compilers have different ways of handling this. If done incorrectly then present of a fortran string concatenation symbol (//) is interpreted as a C comment and the fortran call is considered incomplete with an unterminated argument list (no end parenthesis).

The second error has a message that the code uses a feature deleted in Fortran 2018 (gfortran 9). We ran into something similar with GEOS-Chem Classic when the automatic build tests started using GCC 9 (geoschem/geos-chem#113).

Both of these errors indicate that your compiler is not compatible with this version of MAPL used in GCHP. Unfortunately we have not tested a comprehensive list of compiler and MPI versions with GCHP 12. However, we will begin more comprehensive testing with GCHP 13.0 when automatic continuous integration build tests are incorporated as we currently do for GEOS-Chem Classic.

Do you have access to an earlier version of GCC? GCC 8.2.0 has worked well for the GCHP 12 series.

from gchp_legacy.

Hi Lei, following up again, the wiki is now updated to be more clear that the gFTL symbolic link in the run directory should be to the install directory within gFTL. Thanks for the suggestion.

Lizzie

from gchp_legacy.

Thanks Lizzie! @lizziel
I re-compiled all the necessary libraries with GCC 8.2.0. However, this time the GCHP compiling process failed with BLAS and LAPACK, see line 6410-6411 in compile.fail.log:

/usr/bin/ld: cannot find -lblas
/usr/bin/ld: cannot find -llapack

This issue has been previously reported #39 and fixed. Instead of installing the two libraries on the system level (In fact, our cluster didn't allow me to do so), I got this straight by installing and loading a local spack openblas package.
The following changes were made to gchp.env:

# Load blas and lapack
spack load blas%[email protected]
spack load lapack%[email protected]

# Set path to blas and lapack
export BLAS_HOME=$(spack location -i blas%[email protected])
export PATH=${BLAS_HOME}/bin:$PATH
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${BLAS_HOME}/lib

https://github.com/geoschem/gchp/blob/90f24d9aeab58c988da1f88263ce7b471f799367/Shared/Config/math.mk#L45 was also modified to:

#LIB_SCI = -lblas -llapack
LIB_SCI = -lopenblas

GCHP finally compiled successfully on our cluster, see compile.success.log. I also upload our gchp.env file for your reference.
Again, thank you very much for walking us through this.
Lei

from gchp_legacy.