Bugfix: GridDiag add option for pairing fields and files

[georgemccabe]

This came up from disussion #3166.

Currently, the GridDiag wrapper adds each input file with its own -data argument, e.g. -data input1 -data input2.

According to the Required Arguments for grid_diag section of the Grid-Diag Tool chapter of the MET User's Guide:

When -data is used once, all fields are read from each input file. When used multiple times, it must match the number of fields to be processed. In this case the first field in the config data field list is read from the files designated by the first -data, the second field in the field list is read from files designated by the second -data, and so forth. All files within each set must be of the same file type, but the file types of each set may differ. A typical use case for this option is for the first -data to specify forecast data files and the second -data the observation data files.

It is not currently possible to configure the GridDiag wrapper to run with the former configuration, that is to process all fields from each input file.

Describe the Enhancement

Add a GRID_DIAG_PAIRED METplus configuration option to control this behavior.

If unset (default to preserve backwards compatibility) or set to True, then add the -data argument before each input file path to tell the tool to pair the fields (set via BOTH_VAR<n>_NAME/LEVELS) with the files, one-to-one.

If set to False, pass the -data argument once with each file path separated by spaces to tell the tool to run all of the fields from each of the input files.

With these changes, update the METplus documentation:

• GridDiag Description section of the Python Wrappers chapter - Add information about how to set fields (BOTH_VAR_ or FCAT_VAR_ variables) and how the GRID_DIAG_PAIRED option behaves
• GridDiag METplus Configuration section of the Python Wrappers chapter - Add BOTH_VAR<n>_ and FCST_VAR<n>_ so it is clear what can be used by this tool. Consider reviewing other tools in this chapter and add these variables as appropriate.

Time Estimate

~1 day

Sub-Issues

Consider breaking the enhancement down into sub-issues.

• Add a checkbox for each sub-issue here.

Relevant Deadlines

7.0.0

Funding Source

UKMO

Define the Metadata

Assignee

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

Labels

• Review default alert labels
• Select component(s)
• Select priority
• Select requestor(s)

Milestone and Projects

• Select Milestone as a METplus-Wrappers-X.Y.Z version, Consider for Next Release, or Backlog of Development Ideas
• For a METplus-Wrappers-X.Y.Z version, select the METplus-Wrappers-X.Y.Z Development project

Define Related Issue(s)

Consider the impact to the other METplus components.

• METplus, MET, METdataio, METviewer, METexpress, METcalcpy, METplotpy

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.
• Add any new Python packages to the METplus Components Python Requirements table.
• For any new datasets, an entry to the METplus Verification Datasets Guide.
• 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 Development issue
  Select: Milestone as the next official version
  Select: METplus-Wrappers-X.Y.Z Development project for development toward the next official release
• Iterate until the reviewer(s) accept and merge your changes.
• Delete your fork or branch.
• Close this issue.