CMORsnack: success across almost all, if not all, variables

[ilaflott]

i.e. there should be as few "special cases" as possible.

remaining cases from the bite:

• 4. atmos gr1 / Amon / ta
  • allow no-lon coordinate axis case
• 6. ocean gn / Omon / sos
  • [ ] nc_copy bug
  • rewrite ocean file with missing lat(yh, xh), lon(yh, xh) from statics if avail
• 7. ocean gr / Omon / so (three dimensional ocean)
  • [ ] nc_copy bug
  • expecting olevel, has z_i, z_l instead.
• 8. atmos gn / Amon / ch4global
  • allow no-lon coordinate variable case
  • allow no-lat coordinate variable case
• 9. LUmip gr1 Emon / gppLut
  • [ ] come up with an edge-case work around for non-typical coordinate in place of a more typical vertical coordinate
  • rewriting example
  • rewrite the landfile to use a landuse coordinate variable to be string-valued

[ilaflott]

related issues: #250, #241

[ilaflott]

case 4 works as of #243 / 5fb52ce

[ilaflott]

case 8 works as of #243 / 30adf0f

[ilaflott]

RE case 9, LUmip gr1 Emon / gppLut, coordinate variable landUse must be present and string-valued, instead of an integer flag e.g. landuse. rewriting example

RE cases 6 and 7, nc_copy bug now irrelevant because nc_copy is not needed for copying. It's not clear why it failed and it doesn't matter.

RE case 6, ocean gn / Omon / sos specifically: CF conventions and CMIP demand that for every yh, xh coordinate on a native ocean grid, there should be a corresponding lat(yh, xh) and lon(yh, xh) appended for easy reference. I thought there might be a way to do this conversion on-the-fly, but that was before i learned how tricky the tripolar grid is to describe analytically. 1) tripolar grids aren't so simple that one can just ask for a general implementation of projections back to spherical coordinates... and even if i found one that did what i wanted specifically, 2) this thing is likely embedded in regridding routines that do far more than what i need: a simple projection operation.

Somewhat anti-climactically, by convention, these numbers are usually already computed and present in a corresponding statics file provided by fre-bronx workflows. run_test_file_cases.py comments/notes updated accordingly. to do: proof-of-concept rewriting script ala land file.

RE case 7, ocean gr / Omon / so (three dimensional ocean), CF/CMIP are looking for olevel, which is particularly opaque. I've got some leads and am parsing the details now. This is on the spherical 1x1 degree lat/lon grid, so i won't run into the same problem as I have with case 6.

[ilaflott]

case 7 now works as of #243 / 920a361

computing z_l's bounds from z_i in the same file, and calling it depth_coord to cmor, is what was needed.

i suspect i can do the same thing with case 9 now.

[ilaflott]

case 9 now works as of #243 / 83eaaa5

my speculation from the previous comment was correct