building against pre-build NCEP libraries

[pmspire]

Hi. I'm trying to build GSI from the source contained in the release tarball https://github.com/NOAA-EMC/GSI/archive/gefs_v12.0.2.tar.gz. My build invocation looks like

cmake -DBUILD_CORELIBS=OFF -DBUILD_ENKF=OFF -DBUILD_GLOBAL=ON -DCMAKE_INSTALL_PREFIX=$PREFIX -DCMAKE_PREFIX_PATH=$PREFIX -DUSE_WRF=OFF ..

I have already built the required NCEP libraries (individually, each from their own git repo) and have them installed under $PREFIX. The build makes some progress, but then gets to this:

Found BACIO library $PREFIX/lib/libbacio_4.a
Found BUFR library BUFR_LIBRARY-NOTFOUND
Could not find BUFR library, so building from libsrc
searching for source for bufr_v in 
didn't find directory
WARNING: Did not find  of bufr, looking for alternates
CMake Error at cmake/Modules/FindBUFR.cmake:44 (add_subdirectory):
  add_subdirectory given source
  "$SRCPREFIX/gsi/libsrc/bufr"
  which is not an existing directory.
Call Stack (most recent call first):
  CMakeLists.txt:226 (find_package)

find: ‘/sigio’: No such file or directory
find: ‘/sorc’: No such file or directory
CMake Error at cmake/Modules/findHelpers.cmake:137 (string):
  string sub-command REGEX, mode MATCH needs at least 5 arguments total to
  command.
Call Stack (most recent call first):
  cmake/Modules/FindSIGIO.cmake:19 (findInc)
  CMakeLists.txt:227 (find_package)

(I replaced some long paths there with $PREFIX and $SRCPREFIX for readability -- the values are correct, but shouldn't be interesting.)

I note in the output that libbacio is found, but libbufr isn't. However:

% cd $PREFIX/lib
% ls libbacio*
libbacio_4.a  libbacio_8.a
% ls libbufr*
libbufr_4.a  libbufr_4_DA.a  libbufr_8.a  libbufr_8_DA.a  libbufr_d.a  libbufr_d_DA.a
% ls libcrtm*
libcrtm.a
% ls libnemsio*
libnemsio.a
% ls libsigio*
libsigio.a
% ls libsfcio*
libsfcio.a
% ls libsp*
libsp_4.a  libsp_8.a  libsp_d.a
% ls libw3emc*
libw3emc_4.a  libw3emc_8.a  libw3emc_d.a
% ls libw3nco*
libw3nco_4.a  libw3nco_8.a  libw3nco_d.a

I also tried setting

export COREPATH=$PREFIX/lib

export BACIO_LIB=$PREFIX/lib/libbacio_4.a
export BUFR_LIB=$PREFIX/lib/libbufr_4.a
export CRTM_LIB=$PREFIX/lib/libcrtm.a
export NEMSIO_LIB=$PREFIX/lib/libnemsio.a
export SFCIO_LIB=$PREFIX/lib/libsfcio.a
export SIGIO_LIB=$PREFIX/lib/libsigio.a
export SP_LIB=$PREFIX/lib/libsp_4.a
export W3EMC_LIB=$PREFIX/lib/libw3emc_4.a
export W3NCO_LIB=$PREFIX/lib/libw3nco_4.a

but the build fails in the same way.

Maybe interestingly, if I set

export BACIO_LIB=$PREFIX/lib/libbacio_8.a

(i.e. libbacio_8.a instead of libbacio_4.a -- I'm guessing this is a kind=8 build of the library, whether or not that's what is actually desired for the GSI build), I still see

Found BACIO library $PREFIX/lib/libbacio_4.a

in the output of a new cmake invocation, so that I'm not sure this environment variable is having any effect.

Can you offer any advice on what I might be doing wrong here? Thanks in advance!

[pmspire]

I also tried using the source directories obtained by following the -DDOWNLOAD_ONLY=ON procedure for https://github.com/NOAA-EMC/NCEPLIBS and linking the individual source directories for the support libraries into GSI's libsrc directory, to no avail.

I would be grateful for ideas on how to get the GSI CMake system to recognize the pre-built NCEP libraries, as described above.

[pmspire]

Can anyone provide some help with this?

[MichaelLueken]

Hi Paul,

The GSI is expecting modules for the various libraries to be loaded. It looks like the NCPELIBS team has added instructions on how to generate either LMod or Tcl modulefiles in their README. You might be able to get around this by going into:

cmake/Modules

and adding the path to the libraries ($PREFIX/lib) into the various Find*.cmake modules. CMake should be able to use the paths, supplied under HINTS, to find the library and include files.

Mike

[pmspire]

Thanks @MichaelLueken-NOAA. The system I'm using doesn't use modules but, if I generate them anyway, I should be able to deduce from them the environment variables that GSI's CMake is looking for. As far as you know, then, should the modules produced by https://github.com/NOAA-EMC/NCEPLIBS provide what GSI's CMake needs? I'll go ahead and assume that's true unless I hear otherwise, and report back. That would be nicer than hacking the CMake files, but I'll try that, too.

[MichaelLueken]

Hi Paul,

Since your system doesn't use modules, you are better off going into the cmake/Modules/Find.cmake files and either adding the path to HINTS, or searching for DEFINED ENV to find the environment variables expected to compile the GSI (you are looking for the _LIB and *_INC entries, also note that several of the libraries require specific versions - like BACIO_LIB4 is required to compile).

Mike

[pmspire]

Thanks, Mike. By inspecting the Find* files under cmake/Modules, I determined that the *_LIB environment variables README.cmake recommends appear to be (at least partially) inaccurate, but I was was able to make progress by doing

export BACIO_LIB4=$PREFIX/lib/libbacio_4.a
export BUFR_LIBd=$PREFIX/lib/libbufr_d.a
export COREPATH=$PREFIX
export CRTM_INC=$PREFIX/include
export CRTM_LIB=$PREFIX/lib/libcrtm.a
export NEMSIO_INC=$PREFIX/include
export NEMSIO_LIB=$PREFIX/lib/libnemsio.a
export SFCIO_INC4=$PREFIX/include
export SFCIO_LIB4=$PREFIX/lib/libsfcio.a
export SIGIO_INC4=$PREFIX/include
export SIGIO_LIB4=$PREFIX/lib/libsigio.a
export SP_LIB4=$PREFIX/lib/libsp_4.a
export SP_LIBd=$PREFIX/lib/libsp_d.a
export W3EMC_INC4=$PREFIX/include_4
export W3EMC_INCd=$PREFIX/include_d
export W3EMC_LIB4=$PREFIX/lib/libw3emc_4.a
export W3EMC_LIBd=$PREFIX/lib/libw3emc_d.a
export W3NCO_LIB4=$PREFIX/lib/libw3nco_4.a
export W3NCO_LIBd=$PREFIX/lib/libw3nco_d.a
export WRFPATH=$SRC_DIR/wrf

based on the environment variables referenced by the various Find* modules. These seem to be sufficient, but maybe not all of them are necessary (e.g. I'd initially been setting an NDATE environment variable explicitly, but found that the catch-all COREPATH variable allowed CMake to find ndate).

I ran into trouble later when trying to specify -DBUILD_GLOBAL=ON and providing no WRF build: CMake complained about a missing stub_get_fv3_regional_ensperts.f90 that, as far as I can tell from the CMake logic, is meant to exist to correspond to the class_get_fv3_regional_ensperts.f90 file. For now, as shown above, I'm providing a WRFPATH environment variable, and then calling cmake with -DUSE_WRF=ON. That works, but there might be an outstanding issue with -DBUILD_GLOBAL=ON.

This is, BTW, now using the gfsda.v16.0.0 release.

[pmspire]

I coaxed CMake into success by touching the missing stub_get_fv3_regional_ensperts.f90 file, but compilation later failed, as apparently this source file should provide a module that is used elsewhere in the build. Would it be possible to add this file to the repo?

[aerorahul]

@pmspire Would your team be willing to use the develop version of the GSI?
There has been a significant update in the build system of this package. Please refer to instructions in INSTALL.md