Add a class in order to access vertical coordinates and metrics

[apatlpo]

Have you already thought about how you wanted to that Julien?

[lesommer]

The natural approach is probably to create a generic_3d_grid class in oocgcm.core.

Some of the methods that work in generic_2d_grid will need to eventually be externalized so that we can reuse them in generic_3d_grid (e.g : change_grid_location).

It is probably safer to start by duplicating the methods available in generic_2d_grid, write the unit test and then rationalize the duplications.

any timeline for this functionnality on you side ?

[apatlpo]

This is not critical for us, it can wait a few weeks.
We will eventually perform vertical and volume integrations.

[simon3122]

Hi Julien,
we were wondering with Aurelien what was your timeline about the implementation of the vertical grid in oocgcm?
we'll soon have to deal with it and if you don't have much time to do it we could give it a shot provided we agree on the overall structure of the code / way to proceed.
cheers

[apatlpo]

Hi all,

The following commit ce67ffd is a first draft at implementing vertical coordinates in oocgcm.
It's heavily inspired from what was done for the horizontal.
A thorough clean up of the code will follow soon (leftovers parts from the horizontal code remain).

Some food for thought:
Doing this I got a bit worried about how grids are treated in the current version of the code.
For nemo's z levels application, I think the present structure will do fine.
But for other vertical coordinate systems such as terrain following ones, horizontal and vertical
grids are intimately related (think about pressure gradient computation typically) and I don't think
the present structure will handle these situations well.
In these cases the vertical grid object will have to directly build upon the horizontal one (which may be
common among different grid systems) and I don't think we'll get around having one object that
relies on both grids.

cheers