...
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
ncks --chk_map
request: add min/max of map file frac_a, frac_b data to output
request: check for NaNs when printing weight min/max
for MPAS->atm grid, how come frac_b min/max/ave is all near 1? even when there are bad weights (where there is a rowsum=3) and since MPAS is not a global grid, many rowsums should be between [0,1].
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.