Page Comparison

...

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.
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
  - weights are bad: max 2.6
  - issue: ncks --chk_map row sum error 3e-11 ( so not seeing the 2.6 weight - it’s probably in a region with frac_a or facefrac_b << 1)
  - AnalyzeMap reports rowsum = 3 (consistent with 2.6 weight)
  - ncks --chk_map conservation error: 3.1e-11
  - AnalyzeMap:
  - Status: NOT USABLE

...

TR mono maps have large loss of precision. can be used for development, but not acceptable long term
MBTR maps have bugs (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.
ESMF “aave” and “bilin” maps are good up ot ne512pg2, but both produce too large weights with ne1024pg2
AnalyzeMap
- for MPAS->SE map, row sum calculation reports large errors, probably because it does not mask for points where frac_b<<1. is this due to lack of normalize row sums with frac_b?
- add min/max of frac_a, frac_b to output
- check for NaNs when printing min/max
ncks --chk_map
- add min/max of frac_a, frac_b to output
- check of NaNs when printing min/max
- for MPAS->atm grid with bad weights (> 1.0) not detected in row sums. Is this due to normalzation of row sums by frac_b?

Versions Compared