New Wrapper: PairStat

[JohnHalleyGotway]

Describe the New Feature

Issue dtcenter/MET#3006 adds a new tool named Pair-Stat to read already paired forecast/observation data from input files, filter as requested, and compute/write ASCII output statistics. This logic is pretty similar to the existing Point-Stat tool, however we'll only have a single input data source rather than separate ones for forecasts and observations. The initial implementation will support two data source types:

• ASCII MPR data generated by Point-Stat or provided through Python-embedding
• IODA pairs

The specifics of the usage statement and configuration file contents are still under development, but will be noted here once they are finalized.

Pair-Stat Usage:
TDB

Pair-Stat Configuration File:
TBD

Acceptance Testing

List input data types and sources.
Describe tests required for new functionality.

Time Estimate

Approx 1 week?

Sub-Issues

Consider breaking the new feature down into sub-issues.
None needed.

Relevant Deadlines

Do not charge 7730022 past 12/30/2024.

Funding Source

7730022 NRL METplus

Define the Metadata

Assignee

• Select engineer(s) or no engineer required: @georgemccabe will implement
• Select scientist(s) or no scientist required: @DanielAdriaansen will advise.

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
• No impacts to METplus Analysis expected since Pair-Stat will create .stat files with existing line types.

New Feature 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.

[DanielAdriaansen]

At the same time this work is done for the new wrapper, we should develop a corresponding met_tool_wrapper use case to demonstrate it's functionality. Maybe that's a separate issue but @JohnHalleyGotway mentioned that @georgemccabe may have off-the-shelf scripts or code to set up a basic use case to demonstrate the tool, so it may be contained within this issue. @georgemccabe please advise if you feel strongly about a separate issue. Thanks!

[georgemccabe]

Part of the process of adding a new wrapper is to include a met_tool_wrapper basic use case to demonstrate its use.