Refactoring of the grid handling to possibly support more complex data structures

[oloapinivad]

A first tests of GridInspector() class and some gridtype based operation as discussed in #32
Target is still far but the idea is in place.

[oloapinivad]

🚀 🚀 🚀

[oloapinivad]

After all this machinery, everything is now working as it was originally, meaning that the Gridtype introduction allow for backward compatibility, at least with the current testing strategy

A lot of things must be still improved:

• Rationalize the regrid2d and regrid3d in order
• Read the vertical_dim from the weight when initialize the Gridtype through weights
• Cleaner GridInspector dealing with Dataset or DataArray.
• when writing data from xarray dataset, bring also bounds variable
• Verify if the vertical_dim should be a possible argument of the Regrid class to guarantee flexibility
• Extend tests to make it compatible with AQUA cases. There are cases within AQUA with complex cdo_extra arguments which are not covered here. Also increase coverage should be an option.
• Review docstrings
• Documentation: a first draft is available and set up on read the docs
• Compatibility test with AQUA: need to run AQUA with a specific installation of smmregrid
• Have a CdoGenerate() class which support for weights creations
• Move the generation capabilities of areas from AQUA to smmregrid
• Consolidate the apply_weights_function()

Long terms ideas

• Move some the grid handling from AQUA to smmregrid
• cdo_weights_generator can receive as an argument Gridtype and store some of it into the weights file to be later reused. This is fundamental for the future support for multiple grids

[oloapinivad]

@jhardenberg @mnurisso this can be considered ready to me. I will move the remaining issues (e.g. the creation of a class for generation of weights) to new issues and possibly develop this in the future.

It will be interesting to see which of the features of AQUA should be moved here for a cleaner operativity. For example, now all the dimensions guessing is done inside smmregrid so it should be completely redundant what is done in AQUA. Also, given the properties of the tool, also the grid are generator can be moved here as a specific class (or a twin object of the generation of weights).

[mnurisso]

Has this to be reverted?

[oloapinivad]

not really, it is a lot of calculation, we might want to avoid

[mnurisso]

I'd revert this as well before merging

[oloapinivad]

well, it depends if we keep or not the python matrix. I have noticed test failure when retrieving the cached env with matrix active, not fully sure if these are related though.

[oloapinivad]

I spotted a couple of cases that slipped through the tests, most importantly the one when the time dimension has been dropped. We could make a bit of discussion on the implementation of the GridType class in order to see if there are better possible definitions. Now everything should be back in place.

[oloapinivad]

Trying to address #34, first tests are positive. We need to extract more information from the CDO weights, since there are data structure details on which we can build

[oloapinivad]

I created a new class CdoGenerate() which has two exposed method, one is weights() and the other is areas() so that it can produce both weights and areas and easily port them to python.

I tried to divide the many options available in order that the ones CDO-related all fill into the class while the other goes into the method. Feel free to suggest improvements. I still need to write some tests to check everything works as expected, but it is quite straightforward since I am using direct cdo calls.