Problem linking netcdf libraries

[djw]

I am porting CESM to a new machine and am having problems linking the netcdf libraries. The machine is running centos 7, and like OpenSUSE and I suspect Redhat, provides netcdf C and fortran support through separate modules with separate directory structures. For a long time this gave me the error "ERROR: CIME models require NETCDF in PIO build" until by trial and error I eventually found the binary, include and library files all had to be copied to a single directory structure.

At the present stage the netcdf files are under directory /home/djw/opt/intel/netcdf/lib and the pnetcdf files are under /home/opt/intel/lib - the libraries being kept separate to make things easier when the system is next updated.

This allows the build to get past the pio section to build the atmosphere, ocean etc, but it now fails while building cesm when it cannot find the netcdf libraries. The output describing the link command is:

mpif90 -o /dssgfs01/scratch/djw/NCAR/CIME/mycase/bld/cesm.exe cime_comp_mod.o cime_driver.o component_mod.o component_type_mod.o cplcomp_exchange_mod.o map_glc2lnd_mod.o map_lnd2glc_mod.o map_lnd2rof_irrig_mod.o mrg_mod.o prep_aoflux_mod.o prep_atm_mod.o prep_glc_mod.o prep_ice_mod.o prep_lnd_mod.o prep_ocn_mod.o prep_rof_mod.o prep_wav_mod.o seq_diag_mct.o seq_domain_mct.o seq_flux_mct.o seq_frac_mct.o seq_hist_mod.o seq_io_mod.o seq_map_mod.o seq_map_type_mod.o seq_rest_mod.o t_driver_timers_mod.o -L/dssgfs01/scratch/djw/NCAR/CIME/mycase/bld/lib/ -latm -L/dssgfs01/scratch/djw/NCAR/CIME/mycase/bld/lib/ -lice -L/dssgfs01/scratch/djw/NCAR/CIME/mycase/bld/lib/ -llnd -L/dssgfs01/scratch/djw/NCAR/CIME/mycase/bld/lib/ -locn -L/dssgfs01/scratch/djw/NCAR/CIME/mycase/bld/lib/ -lrof -L/dssgfs01/scratch/djw/NCAR/CIME/mycase/bld/lib/ -lglc -L/dssgfs01/scratch/djw/NCAR/CIME/mycase/bld/lib/ -lwav -L/dssgfs01/scratch/djw/NCAR/CIME/mycase/bld/lib/ -lesp -L../../intel/mpi/nodebug/nothreads/mct/noesmf/c1a1l1i1o1r1g1w1e1/lib -lcsm_share -L../../intel/mpi/nodebug/nothreads/lib -lpio -lgptl -lmct -lmpeu -L/home/djw/opt/intel/lib -lpnetcdf

Followed by a lot of messages about missing routines. I've cheked the files libnetcdff.a libnetcdf.a and found that they contain the 'missing' routines.

I am attaching the machines and compiler xml files from my latest try (gzipped to bypass the attach restrictions). I've tried various options, using <append> </append> tags around the separate combinations of "-Ldirname -llibname", removing the SLIBS section and and replacing the text there by that from the LDFLAGS line - but the link command line (shown above) stays the same - so the pnetcdf section appears to be added separately and the LDFLAGS and SLIBS sections of the compilers xml file appear to be ignored.

Anyway I'd welcome any help or suggestions.

At the moment it is a bit like a locked room puzzle in which I have to do the unknown right things in the unknown right order before I can unlock a door. But at the moment I suspect I don't even have the right key - or missed the right web page.

Regards, D.

 

[jedwards]

In the link line above I see that you are linking pnetcdf correctly, but I don't see netcdf or netcdff at all.
In fact this link line doesn't seem to correspond to the info in your config_compilers.xml file at all.
Check the file Macros.make that is generated in your case directory - do you see

-L/home/djw/opt/intel/netcdf/lib -l netcdff -lnetcdf

in that file?

 

[djw]

Thanks for getting back so quickly.

On the basis of you comments, I checked the two xml files and saw that in the version I included, I had left out the 'djw' in the NETCDF path in configure_compilers.xml. I corrected this so that the NETCDF_PATH text matched that in the LDFLAGS text.

I am fairly certain that the error was introduced when I was cleaning up the files before attaching them to the above message. Anyway, just in case, I went through the process again, removing the mycase directories before running create_newcase and the other scripts. The result was the same as before with the loader unable to find the netcdf routines.

You say that you "don't see netcdf or netcdff at all". However you should see them, in config_compilers.xml, near the end of the LDFLAGS line. I assumed the layout here should follow the normal makefile format.

<LDFLAGS> -L/home/djw/opt/intel/lib -lpnetcdf -L/home/djw/opt/intel/netcdf/lib -l netcdff -lnetcdf</LDFLAGS>

I could not find your code line in the Makefile.make file. I enclose the file in case it contains useful information.

While I am writing, some quick questions:
1. Am I correct in thinking that the scripts check only files in the configure_compilers.xml NETCDF_PATH, when checking for NETCDF support?
2. In the same file, could I have replaced the NETCDF_PATH line with separate NETCDF_C_PATH and NETCDF_Fortran_PATH lines - following the names in in config_machines.xml?
3. In the compilers file, should both LDFLAGS and SLIBS text be copied to the makefiles, as parameters to use when calling the loader?

Thanks again, D.

 

[jedwards]

The Macros.make that you attached does not contain netcdf or netcdff. Go back and try again.
Are you using a config_compilers.xml in the ~/.cime path? If so you may want to remove that and try
editing the config_compilers.xml in the source code (cime/config/cesm/machines/config_compilers.xml)

Edit that file, create a newcase, case.setup - check the Macros.make - if netcdf and netcdff aren't there, go back and try again.

 

[djw]

Everything now works and the test with "--compset X --res f19_g16" runs to completion.

The errors were first, additions to tags CFLAGS, FFLAGS and LDFLAGS have to be included within additionsl tags, i.e.:
<LDFLAGS>
<append> -L/home/djw/opt/intel/lib -lpnetcdf -L/home/djw/opt/intel/netcdf/lib -l netcdff -lnetcdf </append>
</LDFLAGS>

Secondly I was blindly using both "Anemone" and "anemone" as the machine name.

I've moved the Anemone parts of config_machines.xml and config_compilers.xml back to my .cime directory - and the system still works.

So many thanks. D.

 

[jedwards]

That's awesome. Sorry that it was so difficult, it can be really hard to help when I can't see what's going on on your end.