Describe the Enhancement

The Grid-Diag tool can be run to compare multiple variables from the same set of input files. However, it can also be run to compare the same variable from 2 different sets of input files. In both cases, it uses the name of the variable being read to construct output NetCDF variables. The results in a naming conflict and runtime error when reading the same variable from 2 different sets of input files.

The current workaround is using the set_attr_name and/or set_attr_level configuration options to rename one or both variables being read to make the output variable names unique. While that option should remain available, this task it to provide more user-friendly behavior by default.

When doing a fcst vs obs comparison by specifying two different -data file_list command line options, enhance the logic to make the output variable names unique. To be consistent with METplus wrapper settings consider adding a "VAR#_" prefix or "_VAR#" suffix to the variable names to make them unique.

Recommend coordinating with @mpm-meto to define desirable behavior.

Be sure to update the user's guide and be sure to add a new unit test if a fcst vs obs example does not yet exist.

Time Estimate

1 day

Sub-Issues

Consider breaking the enhancement down into sub-issues.
None

Relevant Deadlines

List relevant project deadlines here or state NONE.

Funding Source

Define the source of funding and account keys here or state NONE.

Define the Metadata

Assignee

• Select engineer(s) or no engineer required
• Select scientist(s) or no scientist required

Labels

• Select component(s)
• Select priority
• Select requestor(s)

Projects and Milestone

• Select Repository and/or Organization level Project(s) or add alert: NEED PROJECT ASSIGNMENT label
• Select Milestone as the next official version or Future Versions

Define Related Issue(s)

Consider the impact to the other METplus components.

• METplus, MET, METdataio, METviewer, METexpress, METcalcpy, METplotpy
  No impacts.

Enhancement Checklist

See the METplus Workflow for details.

• Complete the issue definition above, including the Time Estimate and Funding Source.
• Fork this repository or create a branch of develop.
  Branch name: feature_<Issue Number>_<Description>
• Complete the development and test your changes.
• Add/update log messages for easier debugging.
• Add/update unit tests.
• Add/update documentation.
• Push local changes to GitHub.
• Submit a pull request to merge into develop.
  Pull request: feature <Issue Number> <Description>
• Define the pull request metadata, as permissions allow.
  Select: Reviewer(s) and Linked issues
  Select: Repository level development cycle Project for the next official release
  Select: Milestone as the next official version
• Iterate until the reviewer(s) accept and merge your changes.
• Delete your fork or branch.
• Close this issue.