Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

As part of the efforts in the CMDV project, interfaces to integrate the MOAB unstructured mesh library with the TempestRemap remapping tool have been undertaken. Detailed information on the algorithmic and implementation aspects of this effort have been written in a manuscript submitted to Geoscientific Model Development [1]. This work has led to the development of a new offline remapping tool called mbtempest, which exposes the functionality to compute the supermesh or intersection mesh between two unstructured source and target component grids, in addition to using this supermesh for computing the remapping weights to project solutions between the grids. This functionality is part of the critical worflow with E3SM, where the generated remapping weights in the offline step are consumed by MCT at runtime to seamlessly transfer solution data between components (atm↔ocn, atm↔lnd, etc).

...

The meshes generated with TempestRemap are output in the Exodus format, which is not in the natively parallel (optimized), I/O format in used by MOAB. So for cases with high resolution meshes (such as NE512 or NE120 or greater i.e., NE256/NE512/NE1024) that need to be used for computation of remapping weights, it is important that a preprocessing step is performed to partition the mesh in h5m format in order to minimize the mbtempest execution time. Such a workflow can be implemented as below.

...

Convert Exodus mesh to MOAB HDF5 (h5m) format

Code Block
mpiexec -n 4 tools/mbconvert -g -o "PARALLEL=WRITE_PART" -O "PARALLEL=BCAST_DELETE" -O "PARTITION=TRIVIAL" -O "PARALLEL_RESOLVE_SHARED_ENTS" outputCSMesh.exo outputCSMesh.h5m

...

MOAB supports generating partitions for the mesh using either Zoltan or Metis. The mbpart tool can be utilized to generate the PARALLEL_PARTITION tag in MOAB to enable parallel runs and computation of intersection/remapping weights in considerably reduced times. Note that for the MOAB mbtempest workflows, we prefer Zoltan as our primary partitioner since there is an ongoing NGD effort with Dr. Karen Devine (Karen Devine (Unlicensed)), who is the PI of Zoltan partitioning library. However, for simplicity, Metis partitioner would work as well even if computational scaling is slightly sub-optimal.  

To partition MOAB H5M meshes for running on say 1024 processes, the following arguments can be used in the mbpart tool.

...

Partitioning meshes with the "inferred" strategy for better performance

A more recent update /wiki/spaces/ED/pages/2208170181 to the mbpart tool is to use the concept of inferred partitions such that the geometric locality on the source and target grids are preserved as much as possible to minimize communication at runtime during intersection mesh computation. This strategy has been shown to provide considerable speedup in the intersection mesh computation, and is the preferred workflow now our preferred partitioning strategy in offline workflows, especially when one of the grids has topological holes (OCN mesh). In order to generate the inferred partitions, we usually choose the target mesh as the primary partition and the source mesh as the secondary partition. Then, the source mesh partitions are "inferred" based on the target mesh partition RCB tree. The commands to generate the inferred source partitions are shown below.

Inferred partitioner usage
Code Block
languagebash
titleInferred Partitioner Usage
Usage: tools/mbpart #parts -z RCB -b --scale_sphere -p 2 target_input_mesh.h5m target_output_mesh.h5m --inferred source_input_mesh.h5m
Example: tools/mbpart 1024 -z RCB -b --scale_sphere -p 2 ocean.oEC60to30v3.h5m ocean.oEC60to30v3.p1024.h5m --inferred NE1024.h5m

...

Note that only Zoltan interface in mbpart supports  supports this strategy, and hence becomes a required dependency for MOAB to enable better partitioning for remapping.

...

Code Block
1. mpiexec -n 1 tools/mbtempest -t 5 -l outputCSMesh.exoh5m -l outputICOMesh.exoh5m -i moab_intx_cs_ico.exoh5m
2. mpiexec -n 16 tools/mbtempest -t 5 -l $MOAB_SRC_DIR/MeshFiles/unittest/wholeATM_Tp16.h5m -l outputICOMesh_p16.exoh5m  -i moab_intx_atm_ico.h5m
3. mpiexec -n 128 tools/mbtempest -t 5 -l $MOAB_SRC_DIR/MeshFiles/unittest/wholeATM_Tp128.h5m -l $MOAB_SRC_DIR/MeshFiles/unittest/recMeshOcn_p128.h5m  -i moab_intx_atm_ocn.h5m 

The first -l option specifies the source grid to load, and the second -l option specifies the target grid to load. mbtempest can load Exodus, .nc and h5m files in serial, while the parallel I/O is generally optimized only for the native HDF5 format (h5m) at the moment. So we recommend converting meshes to this format and pre-partitioning using the instructions above. The option -i specifies the output file for the intersection mesh that is computed in MOAB using the advancing front algorithm in parallel. Due to the distributed nature of the mesh in parallel runs, the h5m file cannot be directly used with TempestRemap's GenerateOfflineMap tool. However, if mbtempest is run in serial (first case above) or in parallel, the intersection mesh in Exodus mesh format can be written out using TempestRemap underneath by performing a MPI_Gather on the root process. This process does not scale due to the aggregation of the entire mesh and associated metadata for this process and we recommend using the fully parallel mbtempest workflow directly if possible.

...

Once we have a source and target grid that is to be used to compute the remapping weights, mbtempest can be used in a similar fashion to GenerateOverlapMesh/GenerateOfflineMap in TempestRemap or the ESMF_RegridWeightGen tool with ESMF  in TempestRemap to create the field projection weights. Note that unlike ESMF, there is no need to create a dual of the higher-order Spectral Element (SE) mesh using the TempestRemap workflow. Some examples with different options are provided below. Note that to enable generation of weights in addition to computing the intersection mesh, the only main option to enable is -w.The remapping weights can be generated after computing the intersection mesh by specifying the -w flag.

Code Block
1. Serial (default: FV-FV): mpiexec -n 1 tools/mbtempest -t 5 -l outputCSMesh.exoh5m -l outputICOMesh.exoh5m -f moab_mbtempest_remap_csico_fvfv.h5mnc -i moab_intx_file2.exo -w 
2. Parallel (explicit: FV-FV): mpiexec -n 64 tools/mbtempest -t 5 -l $MOAB_SRC_DIR/MeshFiles/unittest/wholeATM_T.h5m -l $MOAB_SRC_DIR/MeshFiles/unittest/recMeshOcn.h5m  -f moab_mbtempest_remap_fvfv.h5mnc -i moab_intx_file2.exoh5m -w -m fv -m fv 
3. Parallel (SE-FV): mpiexec -n 128 tools/mbtempest -t 5 -l $MOAB_SRC_DIR/MeshFiles/unittest/wholeATM_T.h5m -l $MOAB_SRC_DIR/MeshFiles/unittest/recMeshOcn.h5m  -f moab_mbtempest_remap_sefv.h5mnc -i moab_intx_file2.exoh5m -w -m cgll -m fv -o 4 -o 1 -g GLOBAL_DOFS -g m fv -o 1 -g GLOBAL_ID

These commands will generate the remapping weights by computing the intersection mesh through advancing front intersection algorithm in MOAB and then using TempestRemap to generate the weights in parallel. The computed matrix weights are then written out in parallel in the h5m format (specified through option -f). The user can also specify the field discretization type and order by using the -m and -o options. Currently, the -m option can take fv, cgll, dgll as valid options and -o is any non-zero, positive integer representing the order of the spectral or FV discretization for climate problems.

...

Converting parallel h5m file to SCRIP file for E3SM

To complete the offline map generation workflow, a converter tool from the parallel MOAB h5m file to a SCRIP file to be consumed in E3SM directly is available. This h5mtoscrip converter tool takes the output file from mbtempest and produces the mapping weights and attributes in SCRIP nc file based on the metadata generated during the remapping process. The downside to this extra step in conversion is that this process is only run in serial and is limited to the memory constraints on the node. As a future task, we will also be investing effort into writing a SCRIP file in parallel through a custom I/O interface using PNetCDF. 

Typical usage of the tool takes the mapping file (h5m) as input and writes out the SCRIP (nc) file as output.

Code Block
tools/h5mtoscrip -d 2 -w mapSEFV-NE30.h5m -s mapSEFV-NE30.nc

NOTE: In the latest version of MOAB (5.2.1+ or master branch), we now have a parallel SCRIP writer for map files. So you can just use .nc extension when writing out the map file with the -f argument for mbtempest

Machines with mbtempest tool pre-installed

Cori: Updated sources of TempestRemap and MOAB have been pre-installed along with all required dependencies on some of the standard machines. The MOAB installation is available on Cori within the E3SM project space: /project/projectdirs/e3sm/software/moab  and the corresponding TempestRemap installation is at /project/projectdirs/e3sm/software/tempestremap. The workflow for generating the offline maps using these installed tools is described below. 

Note that for the mbtempest stack to run cleanly on Cori, you may have to set the following environment variable:

csh:

Code Block
setenv HDF5_USE_FILE_LOCKING FALSE

bash:

Code Block
export HDF5_USE_FILE_LOCKING=FALSE

Anvil:

prepare environment for intel18 compiler:

...

NOTE: In older versions of MOAB (< 5.2.1), you have to write out the map file in parallel using h5m format and then use the h5mtoscrip tool to convert to .nc file. However, in MOAB v5.2.1 and later, we can directly write out the remap weights in the nc file format, in parallel.

Machines with mbtempest tool pre-installed

Cori: Updated sources of TempestRemap and MOAB have been pre-installed along with all required dependencies on some of the standard machines. The MOAB installation is available on Cori within the E3SM project space: /project/projectdirs/e3sm/software/moab  and the corresponding TempestRemap installation is at /project/projectdirs/e3sm/software/tempestremap. The workflow for generating the offline maps using these installed tools is described below. 

Note that for the mbtempest stack to run cleanly on Cori, you may have to set the following environment variable:

csh:

Code Block
setenv HDF5_USE_FILE_LOCKING FALSE

bash:

Code Block
export HDF5_USE_FILE_LOCKING=FALSE

Anvil:

Prepare environment for Intel-v18 compiler:

source /lcrc/soft/climate/moab/anvil/intel18/anvil_env.sh 
MOAB_DIR=/lcrc/soft/climate/moab/anvil/intel18
TEMPESTREMAP_DIR=/lcrc/soft/climate/tempestremap/anvil/intel18

Chrysalis: 

Prepare environment for Intel compiler:

source /lcrc/soft/climate/moab/chrysalis/intel/chrys_intel.env 
MOAB_DIR=/lcrc/soft/climate/moab/chrysalis/intel
TEMPESTREMAP_DIR=/lcrc/soft/climate/tempestremap/chrysalis/intel

Note: the serial executables need to be launched with mpiexec -np 1, if on login node.  Otherwise you may encounter an error as shown below. 

Code Block
> mbpart -h
Abort(1091087) on node 0 (rank 0 in comm 0): Fatal error in PMPI_Init: Other MPI error, error stack:
MPIR_Init_thread(136): 
MPID_Init(950).......: 
MPIR_pmi_init(168)...: PMI2_Job_GetId returned 14 )

Best A recommended best practice is to use an interactive session on a compute node, which can be requested using the following command.

    srun

...

-N

...

1

...

-t

...

10

...

--pty

...

bash

Compy:

After several iterations to get the dependency stack correct with respect to compatible parallel HDF5 and NetCDF installations by sysadmins on Compy, the other required dependencies were installed successfully and verified/tested to run without issues. Now mbtempest tool is accessible from $MOAB_DIR (see below).

The environment settings for running mbtempest on comps are listed below, and stored in the file: /compyfs/software/mbtempest.envs.sh for reference.mbtempest.envs.sh for reference. 
This is version 5e41106dc9a2 from MOAB (>5.3.0) and version 72df14282a2e9 from tempestremap (>2.1.0)

Code Block
module load cmake/3.11.4 intel/19.0.3 mvapich2/2.3.1 pnetcdf/1.9.0 mkl/2019u3 metis/5.1.0
export MPI_DIR=/share/apps/mvapich2/2.3.1/intel/19.0.3
export METIS_DIR=/share/apps/metis/5.1.0
export EIGEN3_DIR=/share/apps/eigen3/3.3.7/include/eigen3
export HDF5_DIR=/share/apps/netcdf-MPI/intel/19.0.5/mvapich2/2.3.2
export NETCDF_DIR=/share/apps/netcdf-MPI/intel/19.0.5/mvapich2/2.3.2
export PNETCDF_DIR=/share/apps/pnetcdf/1.9.0/intel/19.0.3/mvapich2/2.3.1
export ZOLTAN_DIR=/compyfs/software/zoltan/3.83/intel/19.0.3
export TEMPESTREMAP_DIR=/compyfs/software/tempestremap/intel/19.0.3
export MOAB_DIR=/compyfs/software/moab/intel/19.0.3

...

  1. For the NE30 case, let us generate the CS mesh of required resolution using mbtempest.
    1. Command: $MOAB_DIR/bin/mbtempest -t 0 -r 30 -f outCSMesh30.nc
    2. Here, the type = 0 ( -t 0) specifies that we want to generate a CS grid, with element resolution = 30x30x6 (using -r 30).
  2. Next, convert the NetCDF nc file format to a MOAB format, and in the process, also add some metadata for DoF numbering for the SE grid.
    1. Command: $MOAB_DIR/bin/mbconvert  -B -i GLOBAL_DOFS -r 4 outCSMesh30.nc outCSMesh30.h5m
    2. Here, the GLOBAL_DOFS is the tag that stores the DoF numbering for SE grid of order 4. The input "*.nc" mesh and output "*.h5m" mesh is specified as arguments for the format conversion.
  3. The next step is to pre-partition the h5m file so that the map generation can be computed in parallel. In this particular example, we will use Metis Zoltan partitioner to generate 1024 128 parts.
    1. Command: $MOAB_DIR/bin/mbpart 1024 -m ML_RB 128 -z RCB outCSMesh30.h5m outCSMesh30_1024p128.h5m
  4. Now that we have the ATM grid generated, let us perform a similar conversion on the OCN MPAS file. The MPAS nc file already exists and we will use this input file and convert it to a MOAB h5m file. During this process, unwanted edges and variables are not converted since the mbtempest mapping workflow only requires the actual mesh for computation of the overlap.
    1. Command: $MOAB_DIR/bin/mbconvert -O "variable=" -O "no_edges"  -O "NO_MIXED_ELEMENTS"  oEC60to30v3_60layer.170905.nc oEC60to30v3_60layer.170905.h5m
  5. Similar to the CS grid case, let us now pre-partition the grid to 1024 128 parts using the Metis Zoltan Recursive-Bisection algorithm.
    1. Command: $MOAB_DIR/bin/mbpart 128 -z RCB oEC60to30v3_60layer.170905.h5m oEC60to30v3_60layer.170905_p128.h5m
  6. As mentioned above, better performance can be achieved by using the "inferred" partitioning strategy with Zoltan.
    1. Command: $MOAB_DIR/bin/mbpart 1024 -m ML_RB 128 -z RCB -b --scale_sphere -p 2 oEC60to30v3_60layer.170905.h5m oEC60to30v3_60layer.170905_p128.h5m --inferred outCSMesh30.h5m
    2. Rename outCSMesh30_inferred.h5m to outCSMesh30_p128.h5m to be consistent
    3. The above command will generate oEC60to30v3_60layer.170905_1024.h5m_p128.h5m and outCSMesh30_p128.h5m meshes, which are optimized in term of geometric locality for parallel runs on 128 processes.
  7. We now have fully partitioned MOAB meshes for the CS and MPAS grids (either from step (3)+(5) or from (6)), and all required inputs for mbtempest is available. Invoke the mbtempest command in parallel to generate the remapping weights after specifying the source and target grids, along with discretization detail specifications.
    1. mpiexec Command: srun -n 16 64 $MOAB_DIR/bin/mbtempest -t 5 -w -l outCSMesh30_1024p128.h5m -l oEC60to30v3_60layer.170905_1024p128.h5m -m cgll -o 4 4 -g GLOBAL_DOFS -m fv -o 1 -g GLOBAL_DOFS -g GLOBAL_ID ID -i intx_ne30_oEC60to30v3.h5m -f mapSEFV-NE30.h5mnc
    2. The particular example above runs on 16 64 processes, and takes the pre-partitioned input grids outCSMesh30_1024p128.h5m and oEC60to30v3_60layer.170905_1024p128.h5m for CS and MPAS respectively
    3. We also specify that the source discretization method is Spectral Element (SE) with continuous representation of DoFs on the element interfaces and the target discretization on MPAS grid is Finite Volume (fv). This option is specified using the -m input parameter, whose default is fv.
    4. The order of the discretization is then specified using the -o options for input and output models. In the above case, we have SE order = 4 and FV order = 1.
    5. Next, we also need to specify the tags in the mesh that contain the source and target global DoF numbers that are stored on their corresponding elements. This will dictate the ordering of the mapping weight matrix that is written out to file.
    6. The final set of argument specifies that the output map file is to be written out to mapSEFV-NE30.h5m for the NE30 case in parallel.
  8. Now that we have the parallel remapping weights generated in h5m format, we need to re-convert it back to a SCRIP nc file in order to be consumed by E3SM. For this purpose, we use a special "serial" tool to convert the h5m file to SCRIP.
    1. $MOAB_DIR/bin/h5mtoscrip -d 2 -w mapSEFV-NE30.h5m -s mapSEFV-NE30.nc
    2. The -w argument takes the input map file in h5m format and the -s argument takes the output SCRIP filename.
  9. At the end of this workflow, we now have a SCRIP file containing the weights to compute a solution projection from an input CS NE30 grid with SE(4) discretization to an output MPAS grid with FV(1) discretization.

Building your own version of the mbtempest tool locally

In order to build the MOAB-TempestRemap stack with parallel MPI launch support, we suggest the following list of commands. First define an installation prefix directory where the stack of library, includes and tools will be installed. Let us call this as the $INSTALL_PREFIX environment variable.

Dependencies and pre-requisites

Before getting started, for your architecture of choice, whether that is your laptop or a LCF machine, create a list of following compatible environment variables that can be used to build the stack.

  1. MPI-enabled C, C++, and Fortran compiler wrappers that are exported in the local environment as $CC, $CXX, and $FC.
  2. Next, verify installations of dependent libraries such as $HDF5_DIR and $NETCDF_DIR that have been compiled with MPI support using the $CC, $CXX, $FC compilers.
  3. Get Eigen3 package from the webpage and untar to the $INSTALL_PREFIX/eigen3 directory with the following command
  4. Download: wget https://bitbucket.org/eigen/eigen/get/3.3.7.tar.gz  OR  curl https://bitbucket.org/eigen/eigen/get/3.3.7.tar.gz -O
  5. Move: mv eigen-eigen* $INSTALL_PREFIX/eigen3
  6. export EIGEN3_DIR=$INSTALL_PREFIX/eigen3At the end of this workflow, we now have a SCRIP file (mapSEFV-NE30.nc) containing the weights to compute a solution projection from an input CS NE30 grid with SE(4) discretization to an output MPAS grid with FV(1) discretization.
  7. Exercise: rerun step (7) with source discretization specification: `-m fv -o 1 -g GLOBAL_ID`. This results in a FV-FV map between the NE30 grid and the OCN MPAS grid. You can also switch the order of -l arguments to generate the weights in the reverse direction here i.e., switch source and target grids/discretization specifications for mbtempest.

Building your own version of the mbtempest tool locally

In order to build the MOAB-TempestRemap stack with parallel MPI launch support, we suggest the following list of commands. First define an installation prefix directory where the stack of library, includes and tools will be installed. Let us call this as the $INSTALL_PREFIX environment variable.

Dependencies and pre-requisites

Before getting started, for your architecture of choice, whether that is your laptop or a LCF machine, create a list of following compatible environment variables that can be used to build the stack.

  1. MPI-enabled C, C++, and Fortran compiler wrappers that are exported in the local environment as $CC, $CXX, and $FC.
  2. Next, verify installations of dependent libraries such as $HDF5_DIR and $NETCDF_DIR that have been compiled with MPI support using the $CC, $CXX, $FC compilers.
  3. Get Eigen3 package from the webpage and untar to the $INSTALL_PREFIX/eigen3 directory with the following command
    1. Download: wget https://bitbucket.org/eigen/eigen/get/3.3.7.tar.gz  OR  curl https://bitbucket.org/eigen/eigen/get/3.3.7.tar.gz -O
    2. Move: mv eigen-eigen* $INSTALL_PREFIX/eigen3
    3. export EIGEN3_DIR=$INSTALL_PREFIX/eigen3

Dependencies and pre-requisites from an existing E3SM use case

It is recommended to use the same dependent libraries as a regular E3SM case. 
E3SM cases save the environment in files like  .env_mach_specific.sh in the case folder. That is a good environment to start building your tempestremap, MOAB or Zoltan dependencies. Or maybe they are already built on your machine.  That environment is created from config_machines.xml or config_compiler.xml files, and these change all the time, as new releases, use cases and tests become available. Problems can appear for MOAB's mbtempest if the HDF5 library that netcdf4 is built on does not have a good MPI support. Or if (gasp!) hdf5 is built in serial. Then you are limited on building mbtempest without parallel support, which means you are better off by just running tempestremap in serial. Do not bother with building MOAB. 
On compy, the netcdf used for E3SM is built with serial hdf5, so it cannot be used for MOAB. This is why on compy we have a separate netcdf, built with parallel hdf5. 

Build

To get the entire (MOAB-TempestRemap) stack working correctly, we need to find parallel-enabled dependency installations for HDF5 and NetCDF that are built with MPI library support for the current architecture

...

If steps (a)-(g) pass successfully, the MOAB libraries and tools, along with interfaces for TempestRemap will be installed in $INSTALL_PREFIX/moab directory. The offline remapping weight computation tool, mbtempest, will also be installed during this process and can then be used standalone to generate the weight files as needed.

References

1 Mahadevan, V. S., Grindeanu, I., Jacob, R., and Sarich, J.: Improving climate model coupling through a complete mesh representation: a case study with E3SM (v1) and MOAB (v5.x), Geosci. Model Dev. Discuss., https://doi.org/10.5194/gmd-2018-280, in review, 2018.