gold2718
commented
7 years ago 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.
bertinia
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