Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This page is under construction...explanation and links will be added in the coming days and weeks...feedback welcome!

...

...

Weightingmap_ne30np4_to_ t42_aave.001005.ncmap_ne30np4_to_ t42_aave.20150901.ncmap_ne30np4_to_ t42_aave_ua.20150901.nc
Native2.441241149902344e+022.441241149902344e+022.441241149902344e+02
area2.441241149902344e+022.441241149902344e+022.441241149902344e+02
gw
2.441290893554688e+02
2.441119842529297e+02
2.441241149902344e+02

Ignore the last column (with --user_area = "_ua" mapfiles) for now. The alert reader will see that the first two rows of both tables are identical, i.e., weighting by "area" produces identical answers whether or not one migrates to the new mapfiles. This surprised us because issues 1, 2, and 3 cause the old grid to have a gap (for FV maps) and non-precise weights with mis-positioned centers and interfaces (for Gaussian maps). How can global-mean area-weighted answers from the flawed maps agree to double-precision with the updated maps? There are two reasons for this. First, ESMF_RegridWeightGen, by default, constructs its own areas for all grids it receives. Here it somehow decides that the grids it receives are global (even though the FV grids are missing a longitude strip), and it builds its own internal representation of these grids with total surface = 4*pi sr. Second, it imposes the normalization requirement for first-order conservative remapping, meaning that it guarantees global integrals on the source and destination grids agree.