Building CVS Baselibs

From GEOS-5
Jump to navigation Jump to search

This page will detail the process of building Baselibs. For the purposes of this page, GMAO-Baselibs-4_0_7 as an example tag, but this process should work with any tag after GMAO-Baselibs-3_3_0.

Obtaining Baselibs

Check out Baselibs (CVS)

The first step is to check out the tag you want. Tags on CVS are versions of Baselibs 2.x.y, 3.x.y, and 4.x.y. For version 5.x.y, the recommended Baselibs is now hosted on NASA Internal Github.

Set up the 'bcvs' alias

Something useful to set up first is an alias that you can use to refer to the CVS repo for Baselibs. This is because the Baselibs are hosted on progress while the GEOS-5 model and most other tools are on the CVSACL repo. So, I recommend setting a 'bcvs' alias:

$ alias bcvs 'cvs -d:ext:USERNAME@progressdirect:/cvsroot/baselibs'

where USERNAME is your username at progress. Note that this works on discover and pleiades, but elsewhere you'll need to set up a tunnel to progress and alter the CVSROOT appropriately.

Checking out the tag

Next, checkout the tag:

$ bcvs co -r GMAO-Baselibs-4_0_7 -d GMAO-Baselibs-4_0_7 Baselibs

This will create a GMAO-Baselibs-4_0_7 inside which is a src directory.

Cloning Baselibs (git)

For the latest ESMA Baselibs (5.0.3 and higher), you'll need access to the NASA Internal Github (request through NAMS). If you can't get that, please contact Matt Thompson (matthew.thompson AT nasa.gov) and a tarball can be provided. Assuming access to the NASA Internal Github you can run:

$ git clone -b 5.0.4 --recursive git@developer.nasa.gov:mathomp4/ESMA-Baselibs.git ESMA-Baselibs-5.0.4/src

where 5.0.4 is the version.

Build Baselibs

The next task is to build Baselibs. In order to correctly build it, two arguments are needed: ESMF_COMM and CONFIG_SETUP. ESMF_COMM is the MPI stack used by ESMF (usually mvapich2, mpi (for SGI MPT or other vendor MPI), openmpi, or intelmpi). CONFIG_SETUP is actually an "identifier" that will allow you to build multiple versions of Baselibs for multiple compiler/MPI combination in the same checkout. The style recommended is for, say, Intel 15.0.2.164 and Intel MPI 5.0.3.048 is: CONFIG_SETUP=ifort_15.0.2.164-intelmpi_5.0.3.048 where you identify the compiler (by its name on the command line), its version, the MPI stack, and its version.

Note that if you do not add a CONFIG_SETUP, it will instead build into a directory named after $(FC), so ifort or gfortran. This is fine as long as you only build for that compiler once. Build again (say for a different MPI stack) and you will overwrite that first build!

Load modules

For our example we want to load these modules:

 1) comp/intel-15.0.2.164
 2) mpi/impi-5.0.3.048
 3) lib/mkl-15.0.2.164
 4) other/comp/gcc-4.6.3-sp1
 5) other/SIVO-PyD/spd_1.20.0_gcc-4.6.3-sp1_mkl-15.0.0.090

For other modules see the table at the end.

Note: It's a good idea to build Baselibs in a clean environment. If you have cruft in, say, LD_LIBRARY_PATH, it's possible the build will not pick up the libraries you expect.

Undo any CPP Environment Variable

Before doing any make (especially with PGI), you should issue:

$ unsetenv CPP DEFAULT_CPP

Some modules set these and most of the Baselibs assume the C-preprocessor will be gcc, not, say, pgcpp (which is not a C++ compiler!).

(OPTIONAL) Set MPICC_CC and MPICXX_CXX variables if using MPT

If you are using SGI MPT, and you wish to use, say, the PGI C and C++ compilers instead of GNU, you must set the MPICC_CC and MPICXX_CXX variables to be the "correct" compilers. This can be done either in the environment full (beware!) or during the install by adding at the end:

MPICC_CC=pgcc MPICXX_CXX=pgc++

Build and install

So for the above example you'd issue:

$ make install ESMF_COMM=intelmpi CONFIG_SETUP=ifort_15.0.2.164-intelmpi_5.0.3.048 |& tee makeinstall.ifort_15.0.2.164-intelmpi_5.0.3.048.log

and it would build all the libraries. The tee is so that you can capture the install log, and also see it real-time.

Once built, check for "Error" in your log file, and if you don't see any "Error 2" messages, you are probably safe.

make verify

You can also use make verify which will check the status of the build (by looking for xxx.config and xxx.install files) and print a table like:

-------+---------+---------+--------------
Config | Install |  Check  |   Package
-------+---------+---------+--------------
  ok   |   ok    |   --    | jpeg
  ok   |   ok    |   --    | zlib
  ok   |   ok    |   --    | szlib
  ok   |   ok    |   --    | curl
  ok   |   ok    |   --    | hdf4
  ok   |   ok    |   --    | hdf5
  ok   |   ok    |   --    | h5edit
  ok   |   ok    |   --    | netcdf
  ok   |   ok    |   --    | netcdf-fortran
  ok   |   ok    |   --    | udunits2
  ok   |   ok    |   --    | nco
  ok   |   ok    |   --    | cdo
  ok   |   ok    |   --    | esmf
  ok   |   ok    |   --    | hdfeos
  ok   |   ok    |   --    | uuid
  ok   |   ok    |   --    | cmor
  ok   |   ok    |   --    | hdfeos5
  ok   |   ok    |   --    | SDPToolkit
-------+---------+---------+--------------

Note that this is not as comprehensive as looking at the log file as it is possible that some submakes will fail but not communicate that well enough to the main make process.

Checking Baselibs

This is optional, but recommended. Many of the Baselibs have the ability to do a check. You should do this only in an environment where you can run MPI (like compute nodes at NCCS or NAS). This is because parallel NetCDF and ESMF tests are run:

$ make check ESMF_COMM=intelmpi CONFIG_SETUP=ifort_15.0.2.164-intelmpi_5.0.3.048 |& tee makecheck.ifort_15.0.2.164-intelmpi_5.0.3.048.log

Note that at the moment, many will exit with errors. For example, NetCDF has tests that require internet access and if a check is done on a compute node with no external access, it will fail.