Bug in AMWG diags: regridding

[bertinia]

From @cecilehannay on April 21, 2017 20:46

Hi Cecile,

I dont know if you've been following this issue we've been having in ACME
on confluence. When running the AMWG diagnostics (generating plots),
we've been first doing offline interpolation to an FV style grid with NCO
and then running the diagnostics. However, for some plots the
diagnostics package will choke. I think (but not 100% sure) that the
issues is because the diagnostics package mis-detects the grid as a
Gaussian grid, and then tries to generate Gaussian weights. The Gaussian
weight NCL routine will fail if nlat is odd (yielding no plot). If nlat
is even, then it will succeed, but now we have the problem that we will be
using Gaussian weights instead of equi-angle weights, which will introduce
a small error.

I think the problem is because the diagnostic package relies on the
presence of the CAM-FV "slat" array to determine if it is a FV grid or
Gaussian grid, and this array would not be present in interpolated CAM-SE
data. Have you thought about this issue? Any plans to make the
detection algorithm more robust? Algorithms I've used in the past, none
of which are perfect are (1) FV grids should have a point on the pole, and
Gaussian grids will not or (2) check the spacing between different
latitudes (non-equal spacing suggests a Gaussian grid).

Mark

Copied from original issue: CESM-Development/cime#488

[bertinia]

From @gold2718 on April 21, 2017 21:24

One idea would be to check attributes (cesm1_5_beta02 or newer, ACME commit 7a3eefd5d5d5edb1acad7f304da1921fd4243ead (tag v1.0.0-alpha.1) or newer). Both Eulerian history files and FV history files have an attribute named 'gw', however, the long name for the Eulerian case is 'gauss weights' while the FV long name is 'latitude weights'. This attribute long name can be used to distinguish between these two dycores.