v2024.09.24 Design Critique

[nocollier]

Take a look at this code as a first stab at a design. Let's hash out what works and what we would need and if you like the interface. In this release, the general idea is:

• Models are initialized with a name, color (optional), and a list of paths wherein to find netCDF files/variables.
• Models can have synonyms associated with them which can be expressions.
• When you need a dataset, you ask the model object for it with get_variable().

See the README for code examples.

[nocollier]

@tomvothecoder @lee1043 @pochedls Can you all help me tag the relevant people for this discussion?

[pochedls]

@chengzhuzhang

[tomvothecoder]

@rljacob

[chengzhuzhang]

@nocollier thank you so much for initializing this discussion! I went back to review some approaches that within E3SM and what has being attempted by ESMvaltools. Maybe it helps for brainstorming, setting up the scope and requirement.

Within E3SM alone, we have three different approaches for deriving variables (for analysis and cmorizing) :(

1. E3sm_diags: derived variable with E3SM var name as target. Derived variable dictionary
2. E3sm_to_cmip: handlers with CMIP var name as target. Variable handlers.
3. zppy: hard coded variable conversion for arithmetic calculation. Example

Other efforts in the community, example:
ESMvaltool's effort to cmorize on the fly has limited support for datasets in native format (ESMvaltool is pretty comprehensive also complex, I had made it work once, but haven't tried its cmorization recipe).

The main pain point so far with native E3SM variable output is that a portion of the variables are not cf compliant. Sometimes, we need to support more than one variable naming convention during model development. These will be tackled in model development and shouldn't affect our effort to create an E3SM class/configuration to support analysis.