Page Comparison

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 described above are that the old grid has 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, ERWG, 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. In other words, it adjusts the output values of the field (FSNT, in this case) such that the integral of those values times its internally-diagnosed area-weights equals the input global integral. Some local values of FSNT in the output file are therefore scaled by an unrealistic factor, and this is non-obvious from looking at only the global integral.

Next we see The third row of both tables shows that the "gw"-weighted answers change when migrating, and that the new answer is not correct (both old and new "gw"-weighted answers are incorrect, i.e., does they do not agree to double-precision ) with the native grid either. Here "gw" is the name of the variable holding the latitude-weights (which may or may not be Gaussian weights) for the output grid. So Hence we will prefer to call the contents of "gw" the latitude-weights. They Latitude-weights are diagnosed from the user-specified gridcell interfaces on of the output grid. Because the improved grid-files change the interfaces (for both FV and Gaussian grids), the latitude-weighted answers change in both cases. The The latitude-weighted answers change (from old to new) if the latitude-interfaces change. Latitude interfaces do not change for FV grids, and do change for Gaussian grids. All latitude-weighted answers are (still) incorrect with the new map-files (i.e., the middle column) because those the latitude-weights are applied to the field-values (e.g., FSNT) consistent with the internally diagnosed area, and that area embodies the assumption approximation that gridcell vertices are connected by great-circle arcs (whereas small-circles not great-circles connect points with the same latitude in FV and Gaussian grids). In other words, the new latitude-weights are correct but ERWG has adjusted the fields to be consistent with its internal notion of area, which is based on great-circles and is therefore incorrect for rectangular lat/lon grids.

The answers in the third column all agree to double-precision, yet we do not recommend using those mapfiles which look identical to those in the second column except that ERWG received a single additional argument, --user_areas, in producing them. This argument tells ERWG to normalize with respect to (and to output) the areas provided in the user-supplied grid-files, rather than to generate its own based on the provided grid boundares. However, ERWG can only perform remapping in a manner consistent with its internal assumption of great-circle (not small-circle) connected gridpoints so it still internally generates and uses its own area, though it outputs the user-specified area. The --user_areas switch forces ERWG to adjust the field values so that the global sum of each value, times the ratio of its user-supplied area to its internal area, is the same on input and output grids. Since the correct grid interfaces are present in the new map-files, the correct latitude-weights are diagnosed. And these weights times the fields times the area ratios are correctly normalized globally. 

Why then do we not recommend and use the mapfiles in the third column? Because they produce correct global integrals, but the have worse local precision than the middle column. Here is why: Consider a constant field, say 1.0, on the native grid. The values on the output grid must satisfy the imposed global conservation the user-supplied areas. Thus the regridding remaps 1.0 to 1.0*area_ESGF/area_True where area_ESGF is the internally diagnosed area (i.e., great-circle-based area) and area_True is the user-provided, true area (i.e., small-circle-base in latitude, great-circle-based in longitude). Although the ratio area_ESGF/area_True is near but not equal to 1.0. Thus the remapping turns a constant input field 1.0 into a spatially varying output value 1.0+epsilon where epsilon depends on latitude. Error characteristics of this remapping, such as the L2-norm, are inferior to those of the middle column. Moreover, a plot of the formerly constant field shows an artificial dependence on latitude which though small, is visually distracting.

To summarize, there is not yet a weight-generator which correctly handles both unstructured (great-circle-connected) grids and rectangular (small-circle-connected) lat/lon grids. In the absence of that, the mapfiles produce weights with some drawbacks. We advocate using the map-file with the best overall error characteristics for the job at-hand. For general-purpose regridding, that is the mapfile shown in the middle-column above.