This page is devoted to instruction in NCO’s regridding operator, ncremap. It describes steps necessary to create grids, and to regrid datasets between different grids with ncremap. Some of the simpler regridding options supported by ncclimo are also described at Generate, Regrid, and Split Climatologies (climo files) with ncclimo. This page describes those features in more detail, and other, more boutique features often useful for custom regridding solutions.
The Zen of Regridding
Most modern climate/weather-related research requires a regridding step in its workflow. The plethora of geometric and spectral grids on which model and observational data are stored ensures that regridding is usually necessary to scientific insight, especially the focused and variable resolution studies that E3SM models conduct. Why does such a common procedure seem so complex? Because a mind-boggling number of options are required to support advanced regridding features that many users never need. To defer that complexity, this HOWTO begins with solutions to the prototypical regridding problem, without mentioning any other options. It demonstrates how to solve that problem simply, including the minimal software installation required. Once the basic regridding vocabulary has been introduced, we solve the prototype problem when one or more inputs are "missing", or need to be created. The HOWTO ends with descriptions of different regridding modes and workflows that use features customized to particular models, observational datasets, and formats. The overall organization, including TBD sections (suggest others, or vote for prioritizing, below), is:
...
At a minimum, install a recent version NCO on your executable $PATH with the corresponding library on your $LD_LIBRARY_PATH. NCO installation instructions are here. Unless you have reason to do otherwise, we recommend installing NCO through the Conda package (conda install -c conda-forge nco) or via activating the E3SM-Unified environment. The Conda NCO package automagically installs two other important regridding tools, the ESMF_RegridWeightGen (aka ERWG) executable and the TempestRemap (aka TR) executables. Execute 'ncremap --config' to verify you have a working installation:
zender@aerosol:~$ ncremap --configncremap, the NCO regridder and grid, map, and weight-generator, version 4.9.3-alpha02 "Fuji Rolls"...[Legal Stuff]...Config: ncremap script located in directory /Users/zender/binConfig: NCO binaries located in directory /Users/zender/bin, linked to netCDF library version 4.7.3Config: No hardcoded machine-dependent path/module overrides. (If desired, turn-on NCO hardcoded paths at supported national labs with "export NCO_PATH_OVERRIDE=Yes").Config: External (non-NCO) program availability:Config: ESMF weight-generation command ESMF_RegridWeightGen version 7.1.0r found as /opt/local/bin/ESMF_RegridWeightGenConfig: MOAB-Tempest weight-generation command mbtempest not foundConfig: MPAS depth coordinate addition command add_depth.py found as /Users/zender/bin/add_depth.pyConfig: TempestRemap weight-generation command GenerateOfflineMap found as /usr/local/bin/GenerateOfflineMap
Only NCO is required for many operations including applying existing regridding weights (aka, regridding) and/or generating grids, maps, or conservative weights with the NCO algorithms. Generating new weights (and map-files) with ERWG or TR requires that you install those packages (both of which come with the NCO Conda package). MOAB-Tempest (MBTR) is not yet available in a pre-packaged format and must currently be built from scratch (MBTR is expected to come as a Conda package sometime in 2020). MBTR is only required for power-usersis only required to generate TR weights on the largest meshes. It is also available as a Conda package, and comes with the E3SM-Unified environment. Make sure ncremap reports a sufficiently working status as above before proceeding further.
...
This solution is deceptively simple because it conceals the choices, paths, and options required to create the appropriate map.nc for all situations. We will discuss creating map.nc later after showing more powerful and parallel ways to solve the prototype problem. The solution above only works for users savvy enough to know how to find appropriate pre-built map-files. E3SM mapMap-files used by the E3SM model are available at https://web.lcrc.anl.gov/public/e3sm/inputdata/cpl/gridmaps/ . Additional map-files useful in post-processing are available at https://web.lcrc.anl.gov/public/e3sm/diagnostics/maps/. Many commonly used maps and grids can also be found in my (@czender's) directories as ~zender/data/[maps,grids] at most DOE High Performance Computing (HPC) centers. Take a minute now to look at these locations.
...
The simplest regridding procedure applies an existing map-file to your data, as in the above example . E3SM (public servers of pre-existing map-files are publicly available at https://web.lcrc.anl.gov/public/e3sm/inputdata/cpl/gridmaps/. also linked to above). At most DOE High Performance Computing (HPC) centers these and others can also be found in my (@czenderCharlie Zender 's) directory, ~zender/data/maps. If the desired map-file cannot be found, then you must create it. Creating a map-file requires a complete specification of both source and destination grids (meshes). The files that contain these grid specifications are called "grid-files". Many E3SM grid-files are publicly available within model-specific directories of the previous location, e.g., https://web.lcrc.anl.gov/public/e3sm/inputdata/ocn/mpas-o/oEC60to30v3/ . Many grids useful for post-processing are publicly served from https://web.lcrc.anl.gov/public/e3sm/diagnostics/grids/. At most DOE High Performance Computing (HPC) centers these can also be found in my (@czender's) directory, ~zender/data/grids. Take a minute now to look there for the prototype problem grid-files, ie.eg., for FV 129x256, cmip6_180x360, and ne30np4 ne30pg2 grid-files.
You might find multiple grid-files that contain the string 129x256. Grid-file names are often ambiguous. The grid-file global metadata (ncks -M grid.nc) often displays the source of the grid. These metadata, and sometimes the actual data (fxm: link), are usually more complete and/or accurate in files with a YYYYMMDD-format date-stamp. For example, the metadata in file 129x256_SCRIP.20150901.nc clearly state it is an FV grid and not some other type of grid with 129x256 resolution. The metadata in 129x256_SCRIP.130510 tell the user nothing about the grid boundaries, and some of the data are flawed. When grids seem identical except for their date-stamp, use the grid with the later date-stamp. The curious can examine a grid-file (ncks -M -m grid.nc) and easily see it looks completely different from a typical model or observational data file. Grid-files and data-files are not interchangeable.
Multiple grid-files also contain the string ne30. These are either slightly different grids, or the same grids store in different formats meant for different post-processing tools. The different spectral element (SE) and Finite Volume (and FV) grid types are described with figures and described here (https://acme-climate.atlassian.net/wiki/spaces/Docs/pages/34113147/Atmosphere+Grids). As explained there, for E3SMv1 data many people will want the "dual-grid" with pentagons. The correct grid-file for this is ne30np4_pentagons.091226.nc. Do not be tempted by SE grid-files named with latlon. Datasets from E3SM v2 and v3 simulations are all on FV grids. EAM v2 and v3 grids are named in the format neXXXpg2. ELM and MPAS names take a wider variety of forms, many of which appear below.
All grid-files discussed so far are in SCRIP-format, named for the Spherical Coordinate Remapping and Interpolation Package (authored by @pjones). Other formats exist and are increasingly important, especially for SE grids. For now just know that these other formats are also usually stored as netCDF, and that some tools allow non-SCRIP formats to be used interchangeably with SCRIP.
...
This takes a few minutes, so save custom-generated map-files for future use. Computing weights to generate map-files is much more computationally expensive and time-consuming than regridding, i.e., than applying the weights in the map-file to the data. We will gloss over most options that weight-generators can take into consideration, because their default values often work well. One option worth knowing now is -a. The invocation synonyms for -a are --alg_typ, --algorithm, and --regrid_algorithm. These are listed in the square brackets in the self-help message that ncremap prints when it is invoked without argument, or with --help:
...
...
-a
...
alg_typ
...
Algorithm
...
for
...
weight
...
generation
...
(default
...
ncoaave)
...
[alg_typ,
...
algorithm,
...
regrid_algorithm]
...
ESMF algorithms: esmfbilin,bilinear|esmfaave,aave,conserve|conserve2nd|nearestdtos|neareststod|patch
...
NCO algorithms:
...
ncoaave,nco,nco_con|
...
ncoidw,nco_dwe
...
(inverse-distance-weighted
...
interpolation/extrapolation)
...
Tempest (and
...
MOAB-Tempest)
...
algorithms:
...
traave,fv2fv_flx|trbilin|trfv2|trintbilin|tempest|fv2fv|fv2fv_stt
...
At least one valid option argument for each supported interpolation type is shown separated by vertical bars. The arguments shown have multiple synonyms, separated by commas, that are equivalent. For example, -a esmfaave is equivalent to -a aave and --alg_typ=conserve. Use the longer option form for clarity and precision, and the shorter form for conciseness. The full list of synonyms, and the complete documentation, is at http://nco.sf.net/nco.html#alg_typ. The NCO algorithm ncoaave is the default (because it is always availabe). Commonly-used algorithms that invoke ERWG are esmfbilin and esmfaave. TR options are discussed below. As of E3SM v3, TR algorithms are preferred for all mappings (because they are more accurate). Peruse the list of options now, though defer a thorough investigation until you reach the "Intermediate Regridding" section.
...
| Code Block |
|---|
ncremap --l2s -a se2fv_flx -s atm_se_grd.nc -g ocn_fv_grd.nc -m map.nc # Source larger than destination ncremap -a fv2se_flx -s ocn_fv_grd.nc -g atm_se_grd.nc -m map.nc # Source smaller than destination ncremap -a se2fv_flx -s atm_se_grd.nc -g atm_fv_grd.nc -m map.nc # Source same size as destination |
As mentioned above, EAM v1 datasets are the only ones stored in an SE grid format. To accomodate the mixture of FV and SE grids needed for model evaluation, Transition to TempestRemap for Atmosphere grids describes eight specific global FV<->SE mappings that optimize different combinations of accuracy, conservation, and monotonicity desirable for remapping flux-variables (flx), state-variables (stt), and an alternative (alt) mapping. A plethora of boutique options and switches control the Tempest weight-generation algorithms for these six cases. To simplify their invocation, ncremap names these eight algorithms fv2se_stt, fv2se_flx, fv2se_alt, fv2fv_flx, fv2fv_stt, se2fv_stt, se2fv_flx, se2fv_alt, and se2se. E3SM maps with these algorithms have adopted the suffixes "mono" (for fv2fv_flx, se2fv_flx, and fv2se_alt), "highorder" (fv2fv_stt, se2fv_stt, fv2se_stt), "intbilin" (se2fv_alt), and "monotr" (fv2se_flx). The relevant Tempest map-files can be generated with
...
These maps, applied to appropriate flux and state variables, should exactly reproduce the online remapping in the E3SM v2/v3 v1 coupler. However, explicitly generating all standard maps this way is not recommended because ncremap includes an MWF-mode (for "Make All Weight Files") described below. MWF-mode generates and names, with one command and in a self-consistent manner, all combinations of E3SM global atmosphere<->ocean maps for ERWG and Tempest.
...
The E3SM v2/v3 configurations all use FV grids. Moreover, the mapfile naming convention changed in v3.
Intermediate Regridding III: MOAB/mbtempest support
Weight-generator computations (e.g., finding grid intersections) increase non-linearly with the grid size, so the largest grids are most efficiently computed with parallel algorithms. ERWG has long supported distributed computation in an MPI-environment, and NCO has always supported multi-threaded weight computation via OpenMP. A growing subset of TempestRemap algorithms have now been ported to the parallel MOAB (Mesh Oriented datABase) tool mbtempest (aka MBTR). ncremap can invoke the MOAB regridding toolchain as of NCO version 5.0.2 from September, 2021. The "spoiler" answer to "How do I get ncremap to invoke mbtempest?" is simple: Add the --mpi_nbr=mpi_nbr option to an ncremap command that already calls a TempestRemap algorithm. However, MOAB involves complex, MPI-enabled software, and support for it is continually changing and subject to important limitations. Read on to understand what to currently expect.
...
The combination of these three data manipulations defines MPAS-mode.
Advanced Regridding II: EAMXX-mode
EAMXX storage conventions and files differ from EAM (and CAM) in only two ways. ncremap introduced a -P eamxx mode to support these gotchas in 2022. Dimension permutation is the primary pre-processing step necessary to massage EAMXX datasets so that they are amenable to regridding.
...
It can be difficult to learn the ocean mesh (i.e., grid) names and thus to find the appropriate pre-made map-files. The standard low resolution ocean map-files for post-processing each version of MPAS are:
ncremap -P mpasocean --map=map_oEC60to30v3_to_cmip6_180x360_aave.20181001.nc mpov1.nc out.nc # MPAS Ocean v1ncremap -P mpasocean --map=map_EC30to60E2r2_to_cmip6_180x360_aave.20220301.nc mpov2.nc out.nc # MPAS Ocean v2ncremap -P mpasocean --map=map_IcoswISC30E3r5_to_cmip6_180x360_traave.20231201.nc mpov3.nc out.nc # MPAS Ocean v3
ncremap -P mpasseaice --map=map_oEC60to30v3_to_cmip6_180x360_aave.20181001.nc msiv1.nc out.nc # MPAS Seaice v1ncremap -P mpasseaice --map=map_EC30to60E2r2_to_cmip6_180x360_aave.20220301.nc msiv2.nc out.nc # MPAS Seaice v2ncremap -P mpasseaice --map=map_IcoswISC30E3r5_to_cmip6_180x360_traave.20231201.nc msiv3.nc out.nc # MPAS Seaice v3
Advanced Regridding II: EAMXX-mode
EAMXX storage conventions and files differ from EAM (and CAM) in only two ways. ncremap introduced a -P eamxx mode to support these gotchas in 2022. Dimension permutation is the primary pre-processing step necessary to massage EAMXX datasets so that they are amenable to regridding.
| Code Block |
|---|
ncremap -P eamxx -m map.nc dat_src.nc dat_rgr.nc # Automatically permute dimensions for horizontal regridding |
...
ncremap RRG mode supports two additional options to override parameters set internally. First, the per-region suffix string may be set with --rnm_sng=rnm_sng. RRG mode will, by default, regrid the first region it finds in an RRG file. Explicitly set the desired region with rnm_sng for files with multiple regions, e.g., --rnm_sng= . Second, the bounding-box of the region may be explicitly set with --bb_wesn=lon_wst,lon_est,lat_sth,lat_nrt. The normal parsing of the bounding-box string from the suffix string may fail in (as yet undiscovered) corner cases, and the --bb_wesn option provides a workaround. The bounding-box string must include the entire RRG region, specified in WESN order. The two override options may be used independently or together, as inthe desired region with rnm_sng for files with multiple regions, e.g., --rnm_sng= . Second, the bounding-box of the region may be explicitly set with --bb_wesn=lon_wst,lon_est,lat_sth,lat_nrt. The normal parsing of the bounding-box string from the suffix string may fail in (as yet undiscovered) corner cases, and the --bb_wesn option provides a workaround. The bounding-box string must include the entire RRG region, specified in WESN order. The two override options may be used independently or together, as in:
| Code Block |
|---|
ncremap --rnm_sng='_128e_to_134e_9s_to_16s' --bb_wesn='128.0,134.0,-16.0,-9.0' --dat_glb=dat_glb.nc --grd_glb=grd_glb.nc -g grd_rgn.nc dat_rgn.nc dat_rgr.nc |
RRG-mode supports most normal ncremap options, including input and output methods and regridding algorithms.
Advanced Regridding V: Make All Weight Files (MWF-mode)
As mentioned above in the TempestRemap section, ncremap includes an MWF-mode (for "Make All Weight Files") that generates and names, with one command and in a self-consistent manner, all combinations of E3SM global atmosphere<->ocean maps with both ERWG and Tempest. MWF-mode automates the laborious and error-prone process of generating numerous map-files with various switches. Its chief use occurs when developing and testing new global grid-pairs for the E3SM atmosphere and ocean components. Invoke MWF-mode with a number of specialized options to control the naming of the output map-files:
| Code Block |
|---|
ncremap --rnm_sng='_128e_to_134e_9s_to_16s' --bb_wesn='128.0,134.0,-16.0,-9.0' --dat_glb=dat_glb.nc --grd_glb=grd_glb.nc -g grd_rgn.nc dat_rgn.nc dat_rgr.nc |
RRG-mode supports most normal ncremap options, including input and output methods and regridding algorithms.
Advanced Regridding V: Make All Weight Files (MWF-mode)
As mentioned above in the TempestRemap section, ncremap includes an MWF-mode (for "Make All Weight Files") that generates and names, with one command and in a self-consistent manner, all combinations of E3SM global atmosphere<->ocean maps with both ERWG and Tempest. MWF-mode automates the laborious and error-prone process of generating numerous map-files with various switches. Its chief use occurs when developing and testing new global grid-pairs for the E3SM atmosphere and ocean components. Invoke MWF-mode with a number of specialized options to control the naming of the output map-files:
| Code Block |
|---|
ncremap -P mwf -s grd_ocn -g grd_atm --nm_src=ocn_nm --nm_dst=atm_nm --dt_sng=date |
where grd_ocn is the "global" ocean grid, grd_atm, is the global atmosphere grid, nm_src sets the shortened name for the source (ocean) grid as it will appear in the output map-files, nm_dst sets, similarly, the shortend named for the destination (atmosphere) grid, and dt_sng sets the date-stamp in the output map-file name map_${nm_src}_to_${nm_dst}_${alg_typ}.${dt_sng}.nc. Setting nm_src, nm_dst, and dt_sng is optional though highly recommended. For example,
| Code Block |
|---|
ncremap -P mwf -s ocean.RRS.30-10km_scrip_150722.nc -g t62_SCRIP.20150901.nc --nm_src=oRRS30to10 --nm_dst=T62 --dt_sng=20180901 |
produces the 10 ERWG map-files:
| Code Block |
|---|
map_oRRS30to10_to_T62_aave.20180901.nc
map_oRRS30to10_to_T62_blin.20180901.nc
map_oRRS30to10_to_T62_ndtos.20180901.nc
map_oRRS30to10_to_T62_nstod.20180901.nc
map_oRRS30to10_to_T62_patc.20180901.nc
map_T62_to_oRRS30to10_aave.20180901.nc
map_T62_to_oRRS30to10_blin.20180901.nc
map_T62_to_oRRS30to10_ndtos.20180901.nc
map_T62_to_oRRS30to10_nstod.20180901.nc
map_T62_to_oRRS30to10_patc.20180901.nc |
The ordering of source and destination grids is immaterial for ERWG maps since MWF-mode produces all map combinations. However, as described above in the TempestRemap section, the Tempest overlap-mesh generator must be called with the smaller grid preceding the larger grid. For this reason, always invoke MWF-mode with the smaller grid (i.e., the ocean) as the source, otherwise some Tempest map-file will fail to generate. The six optimized SE<->FV Tempest maps described above in the TempestRemap section will be generated when the destination grid has a ".g" suffix which ncremap interprets as indicating an Exodus-format SE grid (NB: this assumption is an implementation convenience that can be modified if necessary). For example,
| Code Block |
|---|
ncremap -P mwf -s ocean.RRS.30-10km_scrip_150722.nc -g ne30.g --nm_src=oRRS30to10 --nm_dst=ne30np4 --dt_sng=20180901 |
produces the 6 TempestRemap map-files:
| Code Block |
|---|
map_oRRS30to10_to_ne30np4_monotr.20180901.nc
map_oRRS30to10_to_ne30np4_highorder.20180901.nc
map_oRRS30to10_to_ne30np4_mono.20180901.nc
map_ne30np4_to_oRRS30to10_mono.20180901.nc
map_ne30np4_to_oRRS30to10_highorder.20180901.nc
map_ne30np4_to_oRRS30to10_intbilin.20180901.nc |
...
P mwf -s grd_ocn -g grd_atm --nm_src=ocn_nm --nm_dst=atm_nm --dt_sng=date |
where grd_ocn is the "global" ocean grid, grd_atm, is the global atmosphere grid, nm_src sets the shortened name for the source (ocean) grid as it will appear in the output map-files, nm_dst sets, similarly, the shortend named for the destination (atmosphere) grid, and dt_sng sets the date-stamp in the output map-file name map_${nm_src}_to_${nm_dst}_${alg_typ}.${dt_sng}.nc. Setting nm_src, nm_dst, and dt_sng is optional though highly recommended. For example,
% ncremap -P mwf -s ${DATA}/grids/ocean.QU.240km.scrip.181106.nc -g ${DATA}/grids/cmip6_180x360_scrip.20181001.nc --nm_src=QU240 --nm_dst=cmip6_180x360 --dt_sng=20240220
produces sixteen map-files. Note the (v3 standard) mapfile name is map_<src>to<dst>_<alg>.YYYYMMDD.nc. Not coincidentally, ncremap MWF (Make-Weight-File) mode generates maps for exactly these eight algorithms (in both directions). Many researchers do not want the global->ocean direction map-files. Those can simply be deleted.
% ls map*map_QU240_to_cmip6_180x360_esmfaave.20240220.nc map_cmip6_180x360_to_QU240_esmfaave.20240220.ncmap_QU240_to_cmip6_180x360_esmfbilin.20240220.nc map_cmip6_180x360_to_QU240_esmfbilin.20240220.ncmap_QU240_to_cmip6_180x360_ncoaave.20240220.nc map_cmip6_180x360_to_QU240_ncoaave.20240220.ncmap_QU240_to_cmip6_180x360_ncoidw.20240220.nc map_cmip6_180x360_to_QU240_ncoidw.20240220.ncmap_QU240_to_cmip6_180x360_traave.20240220.nc map_cmip6_180x360_to_QU240_traave.20240220.ncmap_QU240_to_cmip6_180x360_trbilin.20240220.nc map_cmip6_180x360_to_QU240_trbilin.20240220.ncmap_QU240_to_cmip6_180x360_trfv2.20240220.nc map_cmip6_180x360_to_QU240_trfv2.20240220.ncmap_QU240_to_cmip6_180x360_trintbilin.20240220.nc map_cmip6_180x360_to_QU240_trintbilin.20240220.nc
For a subset of these maps, use the --alg_lst option, e.g.,% ncremap -P mwf --alg_lst=esmfbilin,ncoidw,traave,trbilin -s ${DATA}/grids/ocean.QU.240km.scrip.181106.nc -g ${DATA}/grids/cmip6_180x360_scrip.20181001.nc --nm_src=QU240 --nm_dst=cmip6_180x360 --dt_sng=20240220% ls map*map_QU240_to_cmip6_180x360_esmfbilin.20240220.nc map_cmip6_180x360_to_QU240_esmfbilin.20240220.ncmap_QU240_to_cmip6_180x360_ncoidw.20240220.nc map_cmip6_180x360_to_QU240_ncoidw.20240220.ncmap_QU240_to_cmip6_180x360_traave.20240220.nc map_cmip6_180x360_to_QU240_traave.20240220.ncmap_QU240_to_cmip6_180x360_trbilin.20240220.nc map_cmip6_180x360_to_QU240_trbilin.20240220.nc
The ordering of source and destination grids is immaterial for ERWG maps since MWF-mode produces all map combinations. However, as described above in the TempestRemap section, the Tempest overlap-mesh generator must be called with the smaller grid preceding the larger grid. For this reason, always invoke MWF-mode with the smaller grid (i.e., the ocean) as the source, otherwise some Tempest map-files will fail to generate.
MWF-mode can take significant time to complete. To accelerate this, consider installing the MPI-enabled instead of the serial version of ERWG and MBTR. Then use the --wgt_cmd option to tell ncremap the MPI configuration to invoke ERWG with, for example:
...
| Code Block |
|---|
# EAM/ELM:
drc_in='/p/user_pub/work/E3SM/1_0/piControl/1deg_atm_60-30km_ocean/atmos/native/model-output/mon/ens1/v1' # Input directory
drc_out="${DATA}/ne30/clm" # Native grid output directory
drc_rgr="${DATA}/ne30/rgr" # Regridded output directory
drc_tmp='/p/cscratch/acme/zender1/tmp' # Temporary directory for intermediate files
map="${DATA}/maps/map_ne30np4_to_cmip6_180x360_aave.20181001.nc" # Regridding map-file
cmip6_opt='-7 --dfl_lvl=1 --no_cll_msr --no_frm_trm --no_stg_grd' # CMIP6-specific options
spl_opt='--yr_srt=1 --yr_end=500 --ypf=500' # 2D Splitter options
vars='FSNT' # 2D
#spl_opt='--yr_srt=1 --yr_end=500 --ypf=25' # 3D Splitter options
#vars='T' # 3D
export TMPDIR=${drc_tmp};cd ${drc_in};/bin/ls 20180129.DECKv1b_piControl.ne30_oEC.edison.cam.h0.0???-*.nc | ncclimo --var=${vars} ${cmip6_opt} ${spl_opt} --map=${map} --drc_out=${drc_out} --drc_rgr=${drc_rgr} > ~/ncclimo.atm 2>&1 &
# MPAS:
drc_in='/p/user_pub/work/E3SM/1_0/piControl/1deg_atm_60-30km_ocean/ocean/native/model-output/mon/ens1/v1' # Input directory
drc_out="${DATA}/ne30/clm" # Native grid output directory
drc_rgr="${DATA}/ne30/rgr" # Regridded output directory
drc_tmp='/p/cscratch/acme/zender1/tmp' # Temporary/intermediate-file directory
map="${DATA}/maps/map_oEC60to30v3_to_cmip6_180x360_aave.20181001.nc" # Regridding map-file
mpas_opt='-m mpas --d2f' # MPAS-specific options
cmip6_opt='-7 --dfl_lvl=1 --no_cll_msr --no_frm_trm --no_stg_grd' # CMIP6-specific options
spl_opt='--yr_srt=1 --yr_end=500 --ypf=500' # 2D Splitter options
vars='timeMonthly_avg_longWaveHeatFluxUp' # 2D
#spl_opt='--yr_srt=1 --yr_end=500 --ypf=25' # 3D Splitter options
#vars='timeMonthly_avg_activeTracers_temperature' # 3D
export TMPDIR=${drc_tmp};cd ${drc_in};/bin/ls mpaso.hist.am.timeSeriesStatsMonthly.0???-*.nc | ncclimo --var=${vars} ${mpas_opt} ${cmip6_opt} ${spl_opt} --map=${map} --drc_out=${drc_out} --drc_rgr=${drc_rgr} > ~/ncclimo.ocn 2>&1 &
|
Take a moment to compare the methods for EAM and for MPAS. They are nearly identical except for the variable names, experiment names and directories, map-files (so far nothing surprising or important) AND the additional MPAS options in ${mpas_opt}. We will discuss those soon. Each command-set begins with setting experiment-dependent I/O directories and a map-files. Other experiments will require changing these to the appropriate I/O directories, yet the map-file remains the same unless the native or destination grid changes. The next three or four lines in each command-set configure the splitter and regridder with options that many ncclimo/ncremap users have never before tried. Finally the list of input files and all the configuration options are sent to ncclimo. The entire procedure for the user boils down to creating then executing this one splitter command for each desired variable.
...
Floating-point mask variables (grid_imask) in SCRIP files---they are non-standard and may break some software. TempestRemap's GenerateOverlapMesh program, for example, breaks (as of this writing, 20210428) when asked to ingest a SCRIP grid-file with a floating point mask. This problem can occur when using grid-files from TR's old ConvertExodusToSCRIP program which outputs output floating point masks. The new TR program, ConvertMeshToSCRIP, appears to have fixed this problem (as of this writing in 20240110). Also, users often create masks from floating-point variables (as described in the next section) and inadvertently leave the mask as a floating point variable. The solution to the problem of floating-point masks can be as simple as a straightforward conversion of the mask to an integer:
...