These are just notes to remember how I fixed some errors encountered while trying to port CESM 1.2.0 onto my new linux server.

---

Makfile.conf

During the build stage I encountered this message:

Copying source to CCSM EXEROOT...
PIO already built. Checking machine type
Same machine.
cp: cannot stat ‘Makefile.conf.old’: No such file or directory
cp: cannot stat ‘Makefile.conf’: No such file or directory
Makefile:25: Makefile.conf: No such file or directory
gmake: *** No rule to make target `Makefile.conf'. Stop.

I initially suspected that this was due to a previous build attempt, so I deleted the case directory. But I forgot to delete the scratch directory. This post helped clue me in on the solution. Once I deleted the scratch directory, this error disappeared.

---

C compiler cannot create executables

I encountered this problem before while building CESM on OSX, but I think the problem is slightly different here. Here’s the error message:

configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
checking whether the C compiler works... no
configure: error: in `/home/whannah/Model/CESM/scratch/AQUA_ZM_TEST_00_ne30/bld/mct':
configure: error: C compiler cannot create executables
See `config.log' for more details

First, this post got me thinking that it was a library issue, specifically with glibc. But that ended up not being the root of the problem. After reading this post, I figured out from the mct config log file that I was not getting valid NetCDF library paths for the linker from “nc-config –flibs”. The mct config log file is found in the scratch or run directory at …./scratch/<case_name>/bld/mct/config.log. This actually turned out to be a serious issue because it meant that my build of the netcdf libraries didn’t work right. This is the first time that the “make check” step of the build was actually helpful! A big part of this issue was that I had 2 conflicting versions of HDF5 library and header files!

The actual CESM error message in config.log was about not being able to find -lnetcdf and -lnetcdff.

Note that the absolute path of the netcdf libraries is needed in the config_compiler.xml file. The final solution was the following change to the config_compiler.xml file:

<LDFLAGS>-L/home/whannah/NetCDF/bld-netcdf-fortran-4.4.1/lib64 -lnetcdff 
           -L/home/whannah/NetCDF/bld-netcdf-c-4.3.2/lib64/  -lnetcdf</LDFLAGS>

---

Error: Symbol ‘sneginf’ at (1) has no IMPLICIT type

A little later in the build process I got this error.

 integer(Single), parameter :: sNegInf = Z"FF800000"
 1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1). This check can be disabled with the option -fno-range-check
/home/whannah/Model/CESM/CESM_SRC/cesm1_2_0/models/csm_share/shr/shr_test_infnan_mod.F90:58.43:

But as the error message says, it can be easily remedied by adding the -fno-range-check flag. I added it to the config_compilers.xml file like this:

<ADD_FFLAGS> -fno-range-check </ADD_FFLAGS>

---

MPI is not a GNU Fortran module file

/home/whannah/Model/CESM/CESM_SRC/cesm1_2_0/models/csm_share/shr/shr_pio_mod.F90:9.6:
    use mpi, only : mpi_comm_null, mpi_comm_world
        1
Fatal Error: File 'mpi.mod' opened at (1) is not a GNU Fortran module file
gmake: *** [shr_pio_mod.o] Error 1

This was tricky because I had multiple version of mpi.mod and I wasn’t sure which ones to keep. I tried modified the config_compiers.xml like this:

<MPI_PATH>/usr/lib64/mpi/gcc/openmpi</MPI_PATH>

but it didn’t have any affect. I feel like there is a simple fix to this, whether it be changing how libraries are installed or changing flags in the model. But either way, I decided to just build the damn openMPI libraries from source in my home directory, which fixed the issue.

---

 

That’s all for now. The model is running… for now. I’ll try to come back and update this mess of a post when it breaks, or when I have to port it again.