Describe the Enhancement

Pull request #2315 for issue #392 added a new TCDIAG line type to the output of TC-Pairs. That issue contained the majority of the work but some cleanup tasks remain. Please see below:

• @jvigh write the Storm Diagnostics section of the tc-pairs.rst chapter.
• @jvigh (Unrelated to the MET repository) Consider adding METplus use case(s) to demonstrate the use of these diagnostics in TC-Pairs. When doing so, consider documenting details about these diagnostic data sources in the METplus Verification Datasets Guide.
• @JohnHalleyGotway update docs to remove references to the -tcdiag and -lsdiag command line options that were consolidated into a single -diag command line option.
• @JohnHalleyGotway investigate why tc-stat is relatively slow reading the tc-pairs output and try to speed it up.
• @KathrynNewman this is somewhat related. MET distributes an old version of the watch/warning file. Should we update that with each release?
• @JohnHalleyGotway modify usage statement to indicate that LSDIAG_DEV is not currently supported but will be added in the future.
• @jvigh will coordinate with CSU folks to figure out what we should name their diagnostics data source. Currently there's a namespace conflict between calling the CSU data "TCDIAG" as well as the output line type "TCDIAG" and the proposed new MET tool "TC-Diag".

Do NOT plan to do this for version 11.0.0:

• @jvigh and @KathrynNewman continue learning about the realtime and development LSDIAG data sources. Consider how realtime LSDIAG track information should be handled.
• @JohnHalleyGotway add support for the developmental LSDIAG data source which contains 20+ years of data in a single file.
  • Consider adding use_diag_track = TRUE/FALSE; config file option. If true, use the diag lat/lon location to define the track rather than matching to an existing ADECK track. This idea requires more thought. Would this be a benefit or just cause confusion We could add logic to bool TrackInfoArray::add_diag_data(DiagFile &diag_file, const StringArray &diag_name) for this.

Time Estimate

Estimate the amount of work required here.
Issues should represent approximately 1 to 3 days of work.

Sub-Issues

Consider breaking the enhancement down into sub-issues.

• Add a checkbox for each sub-issue here.

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 for this set of changes.

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.