Supports ingesting arbitrary MPAS output files (in general, input info from namelist and streams files)

[pwolfram]

The MPAS analysis framework is expected to support stand-alone MPAS workflows, as well as ACME workflows. As such, the analysis framework should be capable of ingesting MPAS output, regardless of how it was generated.

NOTE: This could imply that an input to the analysis framework should be the namelist and streams file used to generate the output, which can then be parsed to easily understand what output was generated, and where it should exist.

[milenaveneziani]

@pwolfram: this definitely needs to be prioritized, and made more general. For example, right now, our scripts will fail on ACME alpha8 output because we have changed the filename_templates in our default streams there, and the python scripts are not taking this change into account.
Other things that will be affected, as we talked about on Wed, are: variable filenames, existence of certain output depending on whether specific analysis member was run, details of mpas_xarray, regional computations (when we introduce them).

Can we discuss what would be the best way to solve this? At what level do you check for namelists and streams: in the run_analysis.py?

[xylar]

@milenaveneziani and @pwolfram, this is another thing that I could help with once I'm back in 2 weeks. I'll check with you then to see where things stand.

[pwolfram]

@milenaveneziani, as far as I can tell, the main problems and potential solutions are:

Need	Possible Solution
1. Automate selection of input files opened and used by the analysis function	Obtain path to file from streams / namelist parsing
2. Ensure that a particular variable can be renamed and this is accounted for in the analysis without error	Register new variable to analysis-specific keyword with python class / dictionary (shared file across analysis)
3. Check for existence of model output	Needs to be tested for cases of 1 and 2 above

I'm a little unclear about what does / doesn't need changed or validated for mpas_xarray as well as what we need to do for regional computations. Additional details would be really helpful.

Once we have a full list of the problems I think we should be able to design some simple and clean solutions to the problems via a module that contains code that should streamline this process, to probably be put in shared/io.

I think we should be able to assume that namelist / streams are of proper format. The key things is their location and this is going to be one of the first things that is potentially checked, probably right about here after we check to see if the model directory exists: https://github.com/MPAS-Dev/MPAS-Analysis/blob/master/run_analysis.py#L21. If the namelist and streams files don't exist I'm thinking we issue a warning and just go with some set of defaults, recognizing the analysis may fail because additional information is needed but not provided (streams/namelist).

[milenaveneziani]

@pwolfram, @xylar: here are the specific things I can think of right now:

1. whether a certain AM is run or not (from namelist)
2. filenames (from streams)
3. variable names (from streams)
4. for mpas_xarray: does xtime_start and xtime_end exist? and how are these quantities called exactly? (not sure if this is something we would get from the streams or the registry: tagging @jonwoodring here also). If xtime_start/xtime_end do not exist, use daySinceStartOfSim.
5. and then there is the regions issue. What I am thinking of at the moment is not the regional stats AM, but rather the regional computations that we would like to do for some existing am's, such as the MOC, the MHT, the layerWeightedAverages and the surfaceAverages. At the moment, we have a placeholder for iregions, but we need to find a way (using the regional mask files and their attributes, I suppose) to identify the regions that are associated with a certain group, for example, and apply the analysis script to those regions only. I am still a bit vague about how this would be implemented in practice, but I think it will be useful to look at a regional mask file and the way that that is used in evolving AM's such as the MOC and the regional MHT.

[milenaveneziani]

Of the list above, we need to prioritize 1-3, because at the moment the scripts will break if running on ACME alpha8 output, for example (because we introduced different namelist/stream names defaults in alpha8).

[pwolfram]

@milenaveneziani and @xylar, #26 and #27 are partial parts of the code we need to handle this issue, specifically 1 and 2. I think variable names is much trickier and am envisioning that we use an approach that is something like the following:

We store a list of different possible variable names for each given quantity we plot. All variables with the mappings could be stored as a dictionary in an easy to edit file. Essentially, there would be a key word in the plotting script, e.g., sst that is the key in the dictionary. This key could be mapped to data from a dataset where a list of possible variable names, e.g., ['time_avg_avgValueWithinOceanRegion_avgSurfaceTemperature', ...] is iterated over for the dataset until the correct variable is found. Once this happens, this data is returned. This would be done with a function that could replace code like

SSTregions = ds.time_avg_avgValueWithinOceanRegion_avgSurfaceTemperature

with

SSTregions = get_dataset_data_from_generalized_name(generalvariablenames, 'regionalavgsst', ds)

noting that generalvariablenames['regionavgsst'] = ['time_avg_avgValueWithinOceanRegion_avgSurfaceTemperature', 'avgSurfaceTemperature'] is specified in a config file via a dictionary.

[xylar]

@pwolfram wrote:

We store a list of different possible variable names for each given quantity we plot.

Let me make sure I understand the purpose here. Are we wanting to support backward compatibility with various ACME versions where variables have been renamed? If so, I think @pwolfram's dictionary idea might work okay. It seems to me that there is always a unique, correct variable name for each ACME version corresponding to a given variable name in the current ACME version. So if we have a way of knowing the ACME version, we should be able to map a current ACME variable name uniquely to its equivalent in previous ACME versions. This would be somewhat better than just having a list of possible variable names and picking whichever one you found first, since there is always the chance that the new name of one variable happens to be the old name of another.

Mapping variable names between ACME versions is going to be a bit of a pain. How important is this capability? How often are we going to want to use the latest MPAS-Analysis on old versions of ACME? I just want to make sure the effort is in proportion to the need.

[pwolfram]

@xylar:

Let me make sure I understand the purpose here. Are we wanting to support backward compatibility with various ACME versions where variables have been renamed?

My understanding is 'yes' to this query, would you agree @milenaveneziani?

I'm also guessing that once we settle out of alpha / beta versions the need to support multiple versions of ACME will not be as great for the long term. I think it is ok to "break" as ACME is incremented from major version numbers, e.g., 1.0 to 2.0 etc. However, I'm not sure if everyone agrees with this assessment and it would be good to get feedback from @jonbob who has much better experience than I on how this works in both theory and practice.

[milenaveneziani]

@xylar, @pwolfram: yes, we do want some level of backward compatibility, especially now that we are still a moving target. Right now for example, I can already see 3 namelist/stream names versions: pre-alpha8, alpha8, and alpha9. We need to be able to support all these versions for now.
I figure when things will be more stable (especially as far as basic MPAS analysis members go), we will be less likely to break, and at that point we can decide whether we can declare the very old versions 'unsupported' and focus on the newer changes.

[xylar]

@pwolfram and @milenaveneziani, now that #27 has been merged, what are the next steps for addressing this issue? Can we create a checklist? I'd be happy to do some of the work if we can break this into smaller tasks that are easier to wrap my head around.

[pwolfram]

@xylar, I've started a checklist at the bottom of the description for the issue above. @milenaveneziani, can you please review these and edit them if necessary?