...
The five issues identified in the pre-migration (pre-20150901) toolchain and fixed by migration are:
1. ACME used adopted flawed FV grids (rectangular and regular lat/lon grids with some funny business regular in latitude, except at the poles) grids that omit omitted a small strip of longitude to the east of Greenwich. This problem was identified independently by Charles Doutriaux and Doutriaux and myself. For FV 129x256, this amounts amounted to 0.2% of global area, that might appear as a gap or blank strip when plotted. Maps based on the flawed grids somehow reapportion area so that total area is conserved (4*pi sr), yet this necessarily redistributes weights from their true positions. This causes a mismatch between "area"- and "gw"- weighted statistics. The solution is to generate grids with the proper interfacesthat center Greenwich in the first zonal gridcell, and to base maps on those grids. Fixed FV grids and maps (with suffix .20150724.nc) are in
/lustre/atlas/proj-shared/cli115/zender/[grids,maps] on rhea
With With these grids, the gap disappears and "area"- and "gw"-weighted statistics agree to double-precision. Together with the Gaussian grid problems described below, this shows that ACME (and CESM) should migrate to more accurate structured 2D grids.
2. SCRIP introduced, and CESM and ACME inherited, coordinate storage in double precision (yay!). Unfortunately, every Gaussian grid that I have examined has grid center latitudes (= sine of the Gaussian quadrature points) accurate to no greater than eight digits. This goes all the way back to grand-daddy SCRIPproblem appears in files in the SCRIP distribution, and in all files produced by NCL that I have examined. The solution is to base latitudes on quadrature points (i.e., Legendre solutions) computed to full double precision. NCO now generates SCRIP-format Gaussian grids accurate to sixteen digits, the best that double precision can reach.
3. The All SCRIP /and CESM/ACME -maintained Gaussian grids that I have examined (T42, T62, and T85) infer gridcell interfaces as midpoints between Gaussian quadrature points/angles. Software then infers the gridcell areas from gridcell interfaces. The problem is that interfaces defined by the midpoint rule will always produce areas inconsistent with those implied by the quadrature weights. this This causes a mismatch between "area"- and "gw"- weighted statistics. NCO now uses Newton-Raphson iteration (instead of the quadrature midpoints) to determine the gridcell interface location that exactly matches areas determined by the (now double-precision) Gaussian weights. With these grids, "area"- and "gw"-weighted statistics agree to double-precision. This procedure The Newton-Raphson iteration moves interfaces by, typically, a few tenths of a degree (for moderate resolution spectral Gaussian grids) from their previous locations as quadrature midpoints. With these grids, "area"- and "gw"-weighted statistics are consistent and agree to double-precision.
4. Some regular lat/lon grids historically produced by NCL and fed to ESMF_RegridWeightGen utilize and used in the CESM community utilize the continuous form of the weighting function (i.e., cosine(lat)) evaluated on the discretized grid, rather than the exact discretized weight function (i.e., the difference of the sine of the latitudes bounding the zone). And some of these regular lat/lon grids are in fact used as staggered/offset FV grids for FV dynamics variables (e.g., U, V). All regular lat/lon grids must have the same functional form for weights as the FV grid itself, since they are simply offsets of eachother. Without this correction, statistics of variables computed on the FV dynamics grid may be misdiagnosed (fxm: last sentence not yet verified). Users of all regular grids, including staggered FV grids/maps , should ensure their grids /maps were produced with the correct weighting function. One way to do this is to verify the "area" variable, if present, exactly matches the area between the gridcell interfaces. If unsure, consider generating a new regular grid with the instructions below, or ask me and I will be happy to generate one for you and keep it in a standard location where others may access it.
5. For historical reasons, mapfiles generated by ESMF_RegridWeightGen using (up to and including version 6.3.0rp1) using bilinear interpolation do not include complete output grid information. In particular, they lack gridcell area, perhaps because the presence of a diagnosed area could be misconstrued to imply a conservation property of the mapping which, by their nature, interpolative schemes lackESMF team thought area would not be desired by users employing non-conservative mapping. However, it is helpful to include area so long as users understand that interpolative maps are non-conservative. The new mapfiles include gridcell area for bilinear interpolation maps.
...