First step at rationalizing vertical handling in ExtData

[bena-nasa]

Not sure how to describe this issue. After more consultation with the GCHP developers and consulting CF conventions, it seemed we needed another tweak to how the vertical information is handled in ExtData. Still more confusion on the whole flipping, what is the TOA etc ...
Looking at this the fundamental issue is this:
ExtData really needs two piece of information.

1. What is the vertical grid of the import, right now it is model levels, but which way is up, i.e. is index 1 the TOA or surface. We have an implicit assumption it is TOA is index 1 but this is independent of the external data.
2. What is the vertical grid of the file, once again independent of the incoming data

We really should be using BOTH these pieces of information to make decisions but right now we have no concept even of a vertical grid or a mechanism to attach that to the grid on the imports being fed to ExtData in a sound enough way to make decisions.

I have made a small change to how we handle the vertical in ExtData as a baby step.
I've gotten rid of this whole "flip" logical as it is confusing. Instead I define two parameters, and instead define a vertical direction for the import and the file. Since we have no way right now of passing the vertical information via the fields, the import direction is always "down" i.e. index 1 is TAO. (it would be easy to add an option to change this in a global way for ExtData).

The vertical direction of the file is determine first by checking for pressure in the vertical level. if it is pressure just look at the level coordinate, otherwise look for a "positive" attribute to determine the vertical direction.

Now if the vertical directions don't match you have to flip the file data to match the import. In addition there was a fill field function we made for GCHP that the idea is if you have fewer levels (but we are not doing vertical regridding) fill up from the surface. I've fixed this as well.

[atrayano]

Down the road we should look into properly supporting 3d ESMF grid or at least add more metadata as attribute to describe the vertical coordinate. Then simply querying the grid would solve this issue.

[tclune]

A few weeks back I started giving some thought on how to do 3 regridding correctly. Nothing novel in the grand scheme, but it does include the fact that horizontal and vertical regridding are not as orthogonal as they are usually treated. (And by extension, there are implications for temporal interpolation as well.) I'll try to sketch this a bit in PPT or sharelatex and then come back to it.

My big fear is that we may effectively lose ESMF regridding just after finally being able to use it.

[tclune]

Ignore that bit about temporal interpolation.

[mathomp4]

Reexamined on 2021-Apr-12 with @bena-nasa and @tclune