Document issues with our mapping file generation tool chain at high resolution. Instructions on using MBtempest: Offline remapping workflow with mbtempest
Status
For PG2 grids, we currently do not have an acceptable solution that would allow us to run at 3km (ne1024).
TempestRemap: Highres maps have poor conservation and consistency (1e-6).
MBTempestRemap: NaN’s or too large weights. conservation/consistency errors similar to TR.
ESMF: For PG2 grids, we can rely on ESMF ‘aave’ maps, which are good up to ne512pg2. Unacceptable at ne1024pg2
For NP4 grids, Ben Hillman has been using TR mapping files with similar conservation/consistency errors. These are acceptable for development/testing, but not appropriate for coupled simulations.
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 HOMME-NH dycore scaling to 1km
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
NaNs in weights.
issue: ncks --chk_map and AnalyzeMap ignore NaNs when computing weight min/max.
issue: AnalyzeMap ignores NaNs when computing row sum
Status: NOT USABLE
ne30np4->ne512np4
NaNs in weights.
Status: NOT USABLE
MBTR “mono”
ne30np4->ne256np4
--monotonic 1: mapping weights have NaNs
--monotonic 3 --noconserve (“intbilin” option) weights are bad, max = 2.5
Status: NOT USABLE
ESMF “bilin”
ne30np4->ne256np4
weights between [0,1]. row sums are perfect. mapping file frac_a=0 (BUG?), but frac_b=1
ncks --chk_map col sums “frac_a” min/max=0. (perhaps because file’s frac_a=0?)
Status: GOOD
ne120np4->ne512np4
Status: GOOD
ne120np4->ne1024np4
10M out of 120M weights are bad, >> 1.0. max row sum = 5.0
Status: NOT USABLE
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.
Note2: these maps have a “mask_a,mask_b” and “frac_a,frac_b” variables. It appears “mask” is used to mask out point not used by that component model. For a global atmosphere grid, mask_b=1 for all points. For an MPAS grid, mask_a=1 for all points since the grid only contains ocean points. A POP grid is probably the only example where mask would contain both 0 and 1 values. The MPAS grid has frac_a=1 for all ocean points = all points in the grid. The mapping file value of frac_b ranges from 0..1 (we should check this) on the atmosphere grid, with coastlines given by the fractional values.
TR “mono”
oRRS18to6 → ne256pg2
takes about 7h to produce (single processor)
Weights are good. Row sums are bad (1.2e-6) Column sum error 1.1e-6
Status: usable for development. NOT USABLE FOR PRODUCTION
oRRS18to6 → ne1024pg2: too expensive/too much memory. need MBTR to compute in parallel.
MBTR “mono”
oRRS18to6 → ne256pg2
Weights are good, but 316 MPAS grid points have weight=0. This is incorrect and corrupts other diagnostics.
Status: NOT USABLE
ESMF “aave”
oRRS18to6 → ne256pg2
weights are good. row sum error 1e-11. Conservation error 1.5e-11
Status: GOOD
oRRS18to6 → ne512pg2
weights are good. row sum error 1e-11. conservation error 1e-11
Status: GOOD
oRRS18to6 → ne1024pg2 . ( /global/project/projectdirs/acme/taylorm/mapping/map_oRRS18to6v3_to_ne1024pg2_aave.nc.BAD )
weights are bad: max 2.6
issue: ncks --chk_map row sum error 3e-11 ( so not seeing the 2.6 weight - why not?)
bad row (using 0 offset indexes) below. frac_a and frac_b are very close to 1.0. Row sum should be 3.0
i=23671483 row=16793415 col=440074 S(i)=0.01081445249957359
i=23671484 row=16793415 col=2185371 S(i)=0.01693720477026149
i=23671485 row=16793415 col=2291461 S(i)=0.06794085597402247
i=23671486 row=16793415 col=2859389 S(i)=0.219621083467022
i=23671487 row=16793415 col=2985682 S(i)=0.01041498955477845
i=23671488 row=16793415 col=3331746 S(i)=2.674271413734307
AnalyzeMap reports max rowsum = 3 (correct)
ncks --chk_map conservation error: 3.1e-11
Status: NOT USABLE
Outstanding issues
TR mono maps have large loss of precision. can be used for development, but not acceptable long term
MBTR FV->FV error - missing source points. It appears MBTR maps have a similar loss of precision as TR maps, but this could be corrupted du to the missing source points.
MBTR SE->SE: montone weights are bad, either NaN or >1
ESMF “aave” and “bilin” maps are good up to ne512pg2, but both produce too large weights with ne1024pg2 (both SE->SE and FV->SE)
AnalyzeMap
request: add min/max of map file frac_a, frac_b data to output
request: check for NaNs when printing weight min/max
for non global (MPAS) source grid, prints tens of thousands of useless consistency warnings
ncremap supports “fv2fv” option:
fv2fv(synonymsrll2rll,accurate_monotone_nonconservative_fv2fv),Options: ‘--in_type fv --in_np 2 --out_type fv --out_np 2 --mono3 --noconserve’
question for Paul Ullrich is “--mono3 --noconserve” supported for FV2FV maps? Some initial results suggest this map is NOT monotone.