View source for GCHP Hardware and Software Requirements v12

__FORCETOC__
'''''[[Downloading_GCHP|Next]] | [[Getting Started With GCHP]] | [[GCHP Main Page]]'''''
#<span style="color:blue">'''Hardware and Software Requirements'''</span>
#[[Downloading_GCHP|Downloading Source Code and Data Directories]]
#[[Obtaining_a_GCHP_Run_Directory|Obtaining a Run Directory]]
#[[Setting_Up_the_GCHP_Environment|Setting Up the GCHP Environment]]
#[[Compiling_GCHP|Compiling]]
#[[Running_GCHP:_Basics|Running GCHP: Basics]]
#[[Running_GCHP:_Configuration|Running GCHP: Configuration]]
#[[GCHP_Output_Data|Output Data]]
#[[Developing_GCHP|Developing GCHP]]
#[[GCHP_Run_Configuration_Files|Run Configuration Files]]
<br>

Please note that documentation on this page primarily reflects the latest GCHP public release which is currently the GCHP 12 series. The documentation will be updated for the GCHP 13.0.0 release over the coming months.

==Hardware Requirements ==

The following is a short list of hardware requirements for GCHP and related information:

#'''GCHP requires a minimum of 6 cores''' to run, and beyond this the number of '''cores must be a multiple of 6'''.
#Most GCHP and GEOS-Chem Classic users use the [[Intel Fortran Compiler]] (ifort). Starting with version 12.5.0, GCHP also has compatibility with open-source GNU compilers. Regardless of whether you use an Intel compiler or not, '''we highly recommend that you use Intel CPUs, preferably Xeon'''. It is a known issue that ifort does not optimize well on AMD chips ([http://hackaday.com/2015/12/09/echo-of-the-bunnymen-how-amd-won-then-lost/ this was actually intended]). Don't worry too much about CPU speed if you can use Xeon CPUs.
#Most clusters are built upon nodes with 16 to 32 CPUs each. One node of 32 CPUs will provide sufficient resources for standard GCHP c48 runs. It will have the added benefit of not needing to use the network interconnect for MPI. In general, '''GCHP will have better performance with more cores per node''' due to how input handling is parallelized.
#GCHP can run with ~7 GB per CPU if using C24, the cubed sphere resolution equivalent to 4&deg; x 5&deg;. Higher resolutions will require more memory per core depending on how many cores you use for your run. '''We have found that the biggest bottleneck for running high resolution simulations is the amount of memory available per node since it limits the memory available per core.''' The best solution when running into memory per core limitations is to request more nodes, reserve all memory per node by requesting all cores, and use fewer cores per node than you have requested for your actual GCHP run.
#'''InfiniBand is recommended''' if you can afford it. If not, a 10 Gigabit Ethernet is a good alternative when using high-end interconnects like Cisco or high-end Hewlett-Packard (HP). A 1000 Mbps Gigabit Ethernet should also work if you get an optimized router like Cisco or HP, but it will be less speed-dependent and have more packet latency. This is minimized in the high-end network interconnects.
#'''If using an interconnect, it would be very helpful if the system had two''': one interconnect for file transfer, log-in, etc, and the other interconnect for MPI-only communication. Using two interconnects in this way prevents problems such as file I/O interfering with MPI packet transfer. This is probably now standard on turn-key systems. Ask your local cluster administrator what is available for you to use.
#'''Ensure all MPI communication nodes use the same interconnect hardware'''. There have been reports of problems running at high resolution with mixed hardware configurations.

== Software Requirements ==

GCHP requires C and Fortran compilers, netCDF C and Fortran libraries, an implementation of a Message Passing Interface (MPI), git version control software, and C-preprocessor software. This software is standard on many primary HPC systems in use by academic and scientific institutions. '''If any of the required software is not available then you must acquire it to compile and run GCHP.'''

For systems with pre-installed packages, such as an institutional compute cluster, you must determine how each package was compiled to ensure that you will be able to build and run GCHP successfully.  '''It is absolutely necessary to use MPI and netCDF libraries built with the same compiler you will use to build GEOS-Chem and ESMF.''' If your pre-installed packages were not built with the same compilers then you will need to build them yourself or have them built for you by your organization's technical support staff.

=== Operating System ===

We are currently only supporting GCHP on Linux distributions.

=== Git ===

You should acquire source code by cloning or forking the GEOS-Chem and GCHP repositories on GitHub using git. The GCHP Makefile assumes use of git version >1.8. Otherwise you will get an error that the -C option is not available. Check the default git version on your cluster by typing 'git --version' at the command line. If you have version 1.8 and prior then check with your system administrator on modules available with a more recent version of git, or download a newer version for free from the web.

If you are new to git then you should take time to get familiar with it. The UCAR CESM project has an excellent git guide, [https://github.com/esmci/cime/wiki/CIME-Git-Workflow CIME Git Workflow], that is a great resource regardless of your skill level. The same basic workflow can be used for GEOS-Chem.

=== GNU Make ===

[https://www.gnu.org/software/make/ GNU Make] is required to build all past versions of GCHP.

=== CMake ===

[https://cmake.org/ CMake] will be required for building an upcoming version of GCHP but is not currently required. Stay tuned for more information on this transition from GNU Make to CMake for building GCHP. GNU Make will still be required to build ESMF.

=== MPI ===

The Message Passing Interface (MPI) is the fundamental requirement for distributed memory computing. We currently support using GCHP with [https://www.open-mpi.org OpenMPI] version 3.1 or higher. OpenMPI 3.0 will also work with GCHP, but versions prior to it will not.

We have not actively tested GCHP 12 with Intel MPI but it has been achieved within the user community with some modification. See [https://github.com/geoschem/gchp/pull/71 GCHP GitHub Issue #71] for details.

Running very old versions of GCHP has also been successful with [https://www.sgi.com SGI MPT], [https://www.mpich.org/ MPICH], and [http://mvapich.cse.ohio-state.edu MVAPICH2], a derivation of MPICH for use with the Infiniband interconnect. All tests were configured with Intel Fortran + Intel C, Intel Fortran + GNU C, or GNU Fortran + GNU C. We have had reports of diagnostic write problems when using MPICH and MVAPICH2 on some systems. Switching to OpenMPI version 3.0 or 3.1 appears to resolve the problems. We therefore recommend trying OpenMPI 3 or higher before other implementations of MPI if possible. See the [https://github.com/geoschem/gchp/issues GCHP issues page on GitHub], and filter for tag "MPI",  for more information. 

You may test which compiler your version of MPI is using with:
 $ mpif90 --version (for Fortran Compiler)
 $ mpicc  --version (for C compiler)

=== Fortran Compiler ===

Starting in GCHP 12.5.0 we recommend using the [[Intel Fortran Compiler]] (ifort) 17.0.4 or above. Prior versions of GCHP are compatible with earlier versions of ifort but an update to the GMAO MAPL library in 12.5.0 requires 17.0.4 or later. 

GCHP 12.5.0 also compiles and runs successfully with the [[GNU Fortran compiler|GNU Compiler Collection]] fortran compiler (gfortran). GCHP versions prior 12.5.0 will compile successfully with gfortran but will not run due to a bug. See the [[GEOS-Chem_12#GCHP_silent_bug_when_using_gfortran_compiler:_Olson_land_map_read_as_all_zeros|wiki post on this issue]] for more information on this issue.

<span style="color:red">'''*** Important ***'''</span> The NASA finite-volume cubed-sphere (FV3) dynamical core used for advection is at least 50% slower when compiled with gfortran. Only use gfortran is absolutely necessary or if you do not mind the performance hit. 

A summary of past reported version compatibility is displayed in the table below. Our testing is not exhaustive so compilers not listed may be compatible with GCHP. If you are using GCHP version and compiler combination not listed below please contact the GEOS-Chem Support Team to have your information added.

{| border=1 cellspacing=0 cellpadding=5
|- bgcolor="#CCCCCC" valign="top"
!Compiler
!GCHP Versions Tested
!Result

|-valign="top"
|ifort 14
|DevKit
|Failed to compile prerequisite libraries

|-valign="top"
|ifort 13
|v11-02b
|Relatively slow compared to more recent versions of ifort

|-valign="top"
|ifort 15
|v11-02d
|Success

|-valign="top"
|ifort 16
|v11-02d
|Success

|-valign="top"
|ifort 17.0.1.132
|12.2.0
|Fail; use 17.0.4 or later

|-valign="top"
|ifort 18.1.163
|12.2.0
|Success 

|-valign="top"
|gfortran 8.2
|12.2.x, 12.3.x, 12.4.x
|Compilation successful, but run fails. See the [[GEOS-Chem_12#GCHP_silent_bug_when_using_gfortran_compiler:_Olson_land_map_read_as_all_zeros|wiki post on this issue]] for more information.

|-valign="top"
|ifort 17.0.4
|12.2.0+
|Success; earlier versions of ifort17 are buggy and should not be used

|-valign="top"
|gfortran 8.2
|12.5.0+
|Success

|}

=== ESMF ===

The Earth System Modeling Framework (ESMF) library provides a software infrastructure that allows different components of Earth System Models to communicate with each other using MPI parallelization. For more information about ESMF, please see: https://www.earthsystemcog.org/projects/esmf/. 

Current versions of GCHP come with ESMF source code that you build as part of the GCHP build sequence. The following ESMF versions are used:
*'''Prior to GCHP 12.2.0:''' v5.2.0rp2
*'''12.2.0 - 12.4.0:''' v7.1.0r
*'''12.5.0 - 12.6.3:''' v8.0.0 beta snapshot 28
*'''12.7.0:''' v8.0.0 public release

We are in the process of restructuring GCHP so that ESMF is built and accessed as an external library. Once we make this switch in GCHP 13.0.0 you will be required to download and build ESMF outside of GCHP. ESMF will no longer be included in the GCHP repository. The primary benefits of using ESMF as an external library are:
#Only one download of ESMF source code is needed
#Only one ESMF build will be required for each combination of libraries you use
#GCHP download time will be much faster due to a more lightweight repository
#GCHP initial build time will be more than 50% reduced

To download ESMF, please see instructions on the [https://www.earthsystemcog.org/projects/esmf/git_clone_instructions ESMF webpage for "How to Git Clone ESMF"] and follow instructions to "clone the entire repository." 

Once downloaded, browse file <code>ESMF/README</code> for information about build requirements. ESMF requires that you define environment variable <code>ESMF_DIR</code> to be the path to your ESMF clone. To create multiple builds in the library, also set environment variable <code>ESMF_INSTALL_PREFIX</code> indicating your environment, such as <code>INSTALL_ifort17_openmpi3</code>. Most other environment variables that are required for GEOS-Chem are also required for ESMF. These variables are listed in the README but are also detailed on the [[Setting_Unix_environment_variables_for_GEOS-Chem#Environment_variables_that_specify_compiler_names|GEOS-Chem wiki page for environment variables that specify compiler name]]. See also the environment examples files that come with GCHP run directories since they include all variables needed. 

You should load libraries you plan on running with GCHP prior to building ESMF. This is best done by saving your library load commands to an environment file that you can save and reuse. Once you are ready to build execute the following commands:

 $ source path_to_your_env_file
 $ cd $ESMF_DIR
 $ make &> compile.log

Once compilation completes, check the end of file <code>compile.log</code> to see if compilation was successful. If yes, continue as follows:

 $ make install &> install.log

Check the end of file <code>install.log</code>. A message that installation was complete should be there if ESMF installation was a success. There should now be a folder in the top-level ESMF directory corresponding to what you defined as environment variable <code>ESMF_INSTALL_PREFIX</code>. Archive your compile and install logs to that directory.

 $ mv compile.log $ESMF_INSTALL_PREFIX
 $ mv install.log $ESMF_INSTALL_PREFIX

Calling <code>make</code> builds ESMF and calling <code>make install</code> places the build into your install directory. In that folder the build files are placed within subdirectories such as <code>bin</code> and <code>lib</code>, among others. The install directory is not deleted when you clean ESMF source code with <code>make distclean</code> in the top-level ESMF directory. Therefore you can clean and rebuild ESMF with different combinations of libraries in advance of needing them to build and run GCHP. Just remember to clean the source code and source the environment file you intend to use prior to creating a new build. You also must specify a different <code>${ESMF_INSTALL_PREFIX}</code> for each unique build so as not to overwrite others.

 $ cd $ESMF_DIR
 $ make distclean
 $ source path_to_your_env_file_with_unique_ESMF_INSTALL_PREFIX
 $ make &> compile.log
 $ install $> install.log
 $ mv compile.log $ESMF_INSTALL_PREFIX
 $ mv install.log $ESMF_INSTALL_PREFIX

Please contact the GEOS-Chem Support Team if you run into problems and please include your <code>compile.log</code> and <code>install.log</code> (if you have one). Depending on the issue, if you run into problems downloading or building ESMF we may refer you to ESMF Support at [https://www.earthsystemcog.org/projects/esmf/contactus/ https://www.earthsystemcog.org/projects/esmf/contactus/].

=== C/Fortran Pre-processor ===

To compile certain ESMF components in GCHP, a compatible C pre-processor (cpp) needs to be available. If you are having compilation errors in the GCHP/Shared directory, you may check your C pre-processor version with the following command:

 $ cpp --version

cpp versions in the 4.x series (4.8.5) have been used to successfully build GCHP, while at least one version in the 5.x series (5.4.0) have failed to correctly process the Fortran sources in the Shared directories for compilation.

=== Goddard Fortran Template Library (gFTL) ===

Starting GCHP 12.5.0, MAPL requires a fortran template library developed by NASA. The library can be cloned from [https://github.com/nasa/gFTL https://github.com/nasa/gFTL]. Complete instructions for download are provided during creation of a GCHP run directory. However, you can prepare in advance by doing the following to acquire the library locally on your system. Please note that building gFTL requires CMake build software.

#Navigate to directory where you want to download gFTL
#Type the following at the command prompt:
        $ git clone https://github.com/Goddard-Fortran-Ecosystem/gFTL
        $ cd gFTL
        $ git checkout v1.0.0
        $ mkdir build
        $ cd build
        $ cmake .. -DCMAKE_INSTALL_PREFIX=../install
        $ make install
You should then verify success by checking that directories <code>gFTL/install/include/templates</code> and <code>gFTL/install/include/types</code> exist.

This whole process should take a couple minutes. If you run into a make error calling <code>make install</code>, check that you have a Makefile in the build directory and you are calling <code>make install</code> from that directory. Note that once you call the <code>cmake</code> command with target paths you cannot change the paths by simply calling <code>cmake</code> again. If you think you made an error it is easiest to simply delete the directory and start from scratch.

=== NetCDF Libraries ===

A netCDF library installation is required to run GCHP. If you are using GEOS-Chem on a shared computer system, chances are that your IT staff will have already installed one or more netCDF library versions that you can use. Please note that parallel reading and writing requires netCDF-4 and requires that it be compiled with parallel-enabled HDF5 libraries. NetCDF-3 does not have parallel capabilities.

Starting with netCDF-4.2, the Fortran netCDF library split off as an independent distribution to be built after building the C library. Prior to that version the Fortran netCDF library was bundled with the C library in a single distribution of netCDF. We have successfully built GCHP using versions of netCDF both before and after the split. The only difference to be aware of is that using netCDF-4.2 requires setting additional environment variables.

If you are using netCDF-4.2 and later versions then you will need to include the following in your bashrc (this example assumes you are using bash):

 export GC_BIN="$NETCDF_HOME/bin"
 export GC_INCLUDE="$NETCDF_HOME/include"
 export GC_LIB="$NETCDF_HOME/lib"
 export GC_F_BIN="$NETCDF_FORTRAN_HOME/bin"
 export GC_F_INCLUDE="$NETCDF_FORTRAN_INCLUDE"
 export GC_F_LIB="$NETCDF_FORTRAN_LIB"

If using earlier versions of netCDF (prior to 4.2) then you should only include the following:

 export GC_BIN="$NETCDF_HOME/bin"
 export GC_INCLUDE="$NETCDF_HOME/include"
 export GC_LIB="$NETCDF_HOME/lib"

For more information about netCDF libraries, please see the wiki [[Guide_to_netCDF_in_GEOS-Chem|Guide to netCDF in GEOS-Chem]].

== Downloading and Installing Software using Spack Package Manager ==

The [https://spack.io/ Spack Package Manager] may be used to download and build CMake, MPI, and NetCDF libraries needed for GCHP. You will need to have a C/C++/Fortran compiler such as [https://gcc.gnu.org/ GNU Compiler Collection] available locally before you start. You can use this local compiler to later install a different compiler version through Spack. The following steps successfully create a GCHP environment on Harvard's Cannon cluster using <code>GCC 9.3.0</code> and <code>OpenMPI 4.0.4</code> through Spack. Info on using Intel compilers is coming soon.

To begin using Spack, clone the latest version by typing <code>git clone https://github.com/spack/spack.git</code>.
Execute the following commands to initialize Spack's environment (replacing <code>/path/to/spack</code> with the path of your <code>spack</code> directory). Add these commands to an environment initialization script for easy reuse.
        $ export SPACK_ROOT=/path/to/spack
        $ . $SPACK_ROOT/share/spack/setup-env.sh
If you do not already have a copy of your preferred text editor, you can use Spack to install and load one before proceeding (e.g. <code>spack install emacs; spack load emacs</code>). 

Ensure Spack recognizes a compiler by typing <code>spack compilers</code>. You will use this compiler to build <code>GCC 9.3.0</code>. Execute the following at the command prompt:
        $ spack install gcc@9.3.0
The <code>@VERSION</code> notation is common to all packages in Spack and can be customized to choose different versions. The installation of <code>gcc</code> may take a long time. Once it is complete, you'll need to add it to Spack's list of compilers using the following command:
        $ spack compiler find $(spack location -i gcc@9.3.0)
Make sure that spack recognizes your new compiler by typing spack compilers, which should display a list of compilers including <code>GCC 9.3.0</code>.

You should now install Git and CMake using Spack:
        $ spack install git@2.17.0%gcc@9.3.0
        $ spack install cmake@3.16.1%gcc@9.3.0

If you do not intend to use a job scheduler like Slurm to run GCHP, use the following commands to install OpenMPI and NetCDF-Fortran. Otherwise, scroll down to see necessary modifications you must make to include Slurm support.
        $ spack install openmpi@4.0.4%gcc@9.3.0
        $ spack install netcdf-fortran%gcc@9.3.0 ^netcdf-c^hdf5^openmpi@4.0.4

=== Configuring libraries with Slurm support  ===
If you intend to submit GCHP runs through a job scheduler like Slurm, you will need to explicitly build your MPI library with support for your pre-installed job scheduler (using Slurm as an example). If you know the install location of Slurm, edit your spack packages settings at <code>$HOME/.spack/packages.yaml</code> (you may need to create this file) with the following:

 packages:
  slurm:
    paths:
      slurm: /path/to/slurm
    buildable: False

This will ensure that when your MPI library is built with Slurm support requested, Spack will correctly use your preinstalled Slurm rather than trying to install a new version.

If you do not know the install location of Slurm, modify <code>$HOME/.spack/packages.yaml</code> with the lines above, but exclude the path designation:

 packages:
  slurm:
    buildable: False

In this case where you do not know Slurm's location, you will also need to modify the arguments passed to the OpenMPI build configuration through Spack. Open <code>$SPACK_ROOT/var/spack/repos/builtin/packages/openmpi/package.py</code> and locate the following lines:

        if spec.satisfies('schedulers=slurm'):
            config_args.append('--with-pmi={0}'.format(spec['slurm'].prefix))

Replace these lines with the following:

        if spec.satisfies('schedulers=slurm'):
            #config_args.append('--with-pmi={0}'.format(spec['slurm'].prefix))
            config_args.append('--with-pmi')

This modification should allow the build system to automatically locate Slurm and use a PMI setup that matches your cluster's Slurm configuration.

You may also run into issues building OpenMPI if your cluster has preexisting versions of PMIx that are newer than OpenMPI's internal version. OpenMPI will search for and use the newest version of PMIx installed on your system, which will likely cause a crash during build because OpenMPI requires you to build with the same libevent library as was used to build PMIx. This information may not be readily available to you, in which case you can tweak the build arguments for OpenMPI to always use OpenMPI's internal version of PMIx. Open <code>$SPACK_ROOT/var/spack/repos/builtin/packages/openmpi/package.py</code> and navigate to the <code>configure_args</code> function. In the body of this function, place the following line:

        config_args.append('--with-pmix=internal')

=== Building libraries with Slurm support ===

Once any necessary tweaks have been made, you need to tell Spack to build OpenMPI with Slurm support and NetCDF-Fortran with the correct OpenMPI version:
    $ spack install openmpi@4.0.4%gcc@9.3.0 +pmi schedulers=slurm
    $ spack install netcdf-fortran%gcc@9.3.0  ^netcdf-c^hdf5^openmpi@4.0.4+pmi schedulers=slurm

=== Loading Spack libraries for use with GCHP ===

After installing the necessary libraries, place the following in a script that you will run before building/running GCHP (such as <code>.bashrc</code> or a separate environment script):

 export SPACK_ROOT=$HOME/spack #your path to Spack
 source $SPACK_ROOT/share/spack/setup-env.sh
 if [[ $- = *i* ]] ; then
  echo "Loading Spackages, please wait ..."
 fi
 #==============================================================================
 # %%%%% Load Spackages %%%%%
 #==============================================================================
 # List each Spack package that you want to load
 pkgs=(gcc@9.3.0            \
       git@2.17.0           \
       netcdf-fortran@4.5.2 \
       cmake@3.16.1         \
       openmpi@4.0.4        )
 
 # Load each Spack package
 for f in ${pkgs[@]}; do
     echo "Loading $f"
     spack load $f
 done
 export MPI_ROOT=$(spack location -i openmpi)


You can also add other packages you've installed with Spack like <code>emacs</code> to the <code>pkgs</code> list above.

--------------------------------------

'''''[[Downloading_GCHP|Next]] | [[Getting Started With GCHP]] | [[GCHP Main Page]]'''''

--[[User:Lizzie Lundgren|Lizzie Lundgren]] ([[User talk:Lizzie Lundgren|talk]]) 18:06, 6 September 2019 (UTC)