Document issues with our mapping file generation tool chain at high resolution.
Analysis Mapping files
Mapping files are needed for remapping native grid output to lat/lon grids for conventional analysis tools. Often exact conservation is not required making TR’s integrated bilinear a good option: it’s accurate, has built in downscaling and is monotone so it wont introduce spurious oscillations making it good for plotting.
TR “intbilin”
several issues with loss of precision documented on (ADD PAGE LINK)
SE GLL to SE GLL
These mapping files are mostly used to generate initial conditions. Remapping the cam.i file from a spunup NE30 simulation will generate a reasonably well spunup initial condition file for higher resolutions.
TR “mono”
ne30np4 → ne256np4
ne30np4->ne512np4
MBTR “mono”
MBtempest currently crashes for SE → SE maps. Vijay M has reproduced the problem.
ESMF “bilin”
ne30np4->ne256np4
ne120np4->ne1024np4
ESMF “aave”
We dont consider these maps. We are trying to move away from these maps since they require the “dual grid”, which is difficult to produce and unnatural for GLL grids.
MPAS → pg2 grids
We expect SCREAM will ultimately be running on the ne1024pg2 “phys grid”. To create these compsets, we first need to create a domain file which needs the monotone map from the MPAS ocean grid to the pg2 grid.
Note that these maps are FV to FV maps and thus avoid the issue of having to construct GLL dual grids even for ESMF maps.
TR “mono”
oRRS18to6 → ne256pg2
takes about 7h to produce (single processor)
MBTR “mono”
oRRS18to6 → ne256pg2
ESMF “aave”
oRRS18to6 → ne256pg2
<20min to produce, single Haswell node.
oRRS18to6 → ne512pg2
oRRS18to6 → ne1024pg2
Outstanding issues
loss of precision in TR maps
Bad weights in TR maps
Bad weights in ne1024 ESMF maps
Issue with ncks --chk_map