Feature/tclune/mapl3 latlongeomfactory

[tclune]

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Trivial change (affects only documentation or cleanup)

Checklist:

• I have tested this change with a run of GEOSgcm (if non-trivial)
• I have added one of the required labels (0 diff, 0 diff trivial, 0 diff structural, non 0-diff)
• I have updated the CHANGELOG.md accordingly following the style of Keep a Changelog

[bena-nasa]

@tclune, I don't see a hook in the new GeomFactory for the equivalent of append_variable_metadata that was in the old factory

[tclune]

@tclune, I don't see a hook in the new GeomFactory for the equivalent of append_variable_metadata that was in the old factory

I'm hoping that we do not need it in the new design. Basically Geom produces the baseline metadata. Other layers can append, but Geom is the initializer.

There are few other "missing" things that are in a similar state: I'm hoping I can avoid the need. If not ... we circle back and add them back.

[bena-nasa]

I see a lot of the helper procedures needed to specify the bounds for the output file are no longer here. Append_variable_metdata caught my eye first, that probably needs to be returned. The rest generate_file_bounds, generate_file_reference*, the question can the logic that those were implement be done in a way that it need not be attached to the specific grid for the IO layer.

[bena-nasa]

@tclune, I don't see a hook in the new GeomFactory for the equivalent of append_variable_metadata that was in the old factory

I'm hoping that we do not need it in the new design. Basically Geom produces the baseline metadata. Other layers can append, but Geom is the initializer.

There are few other "missing" things that are in a similar state: I'm hoping I can avoid the need. If not ... we circle back and add them back.

The one I would insist on being restored before I approve is append_variable_metadata.

The rest we can find other ways as you say.

The generator_file_reference and generate_file_bounds stuff, that could be put into a generic layer and queue off the fact that the cube grid is a multi-tile grid (making the assumption the tile index gets its own dimension). Some of the others such as get_grid_vars, get_file_format_vars could be derived from the metadata once that is made.

[bena-nasa]

Seems zero diff to the old lat-lon grid factory.
I do think that the append_variable_metdata helper procedure needs restoration. That is the only helper procedure from the old factory I see that I could not work around or that could be derived from the metadata and keep our existing IO system working with this new layer.

[tclune]

The one I would insist on being restored before I approve is append_variable_metadata.

Why does the metadata object need to be 1st created somewhere else? The create metadata routine is the former "append" plus the assumption that it will be first in the pipeline. I can't immediately recall how I convinced myself of this, but will certainly amend the interface as the use cases come in. Trying to keep it simple for the moment - just the stuff I can immediately see how it fits in the process.

[bena-nasa]

The one I would insist on being restored before I approve is append_variable_metadata.

Why does the metadata object need to be 1st created somewhere else? The create metadata routine is the former "append" plus the assumption that it will be first in the pipeline. I can't immediately recall how I convinced myself of this, but will certainly amend the interface as the use cases come in. Trying to keep it simple for the moment - just the stuff I can immediately see how it fits in the process.

Please go look at what the old append_variable_metdata is doing, I don't think you are understanding what it is for. This is NOT for appending the overall file metadata.
We add grid specific meta to the file variables, at least in the case of the cube, go look in the old factory. We add specific metadata to the variables so that panoply knows how to plot them. The append_variable_metadata was a way to know for a particular grid, if any extra metadata needs to be attached to the file variables we will be writing. Someone needs to know, if I'm a cube, every variable in the file needs these extra attributes.
In reality every factory that is not a basic lat-lon should be adding "coordinate" attribute to the variables according to CF. So there really does need to be a place in general if I'm grid foo, there may need to be some extra attributes that need to be added to the variables.

[tclune]

OK - I understand. But still, it can wait for now. It will be straightforward enough to bring in when the time comes. Yes - we have to implement it for each factory subclass, but it's the same work now as it will be then, and my short term need is to use the factory to produce distinct grids so that generic can induce a regrid operation.