New Use Case: GFDL tracker for Extra-TC tracking

[TaraJensen]

Replace italics below with details for this issue.

Describe the New Feature

Develop use-case example of running GFDL tracker for Extra-TC tracking which uses a different config file

Based on Guang-Ping's presentation at: https://www.emc.ncep.noaa.gov/mmb/gplou/emchurr/verify/EMC_seminar.ppt

This configuration may be as simple as just using the MSLP parameter for tracking.

From an 2017 email - here's a description of what should be in the files on kiowa

The two files contain the same tracks, but in different format.
"storms.gfso.atcfunix.glbl.YYYY" is in original ATCF format, which gives each storm a number in that cycle.

"trak.gfso.atcf_gen.glbl.YYYY" is in "modified" ATCF format, which gives extra storm IDs, such as "2017072506_F180_400S_0452W_FOF", that is used through out the storm's lifetime. There are also more parameters that reflect storm structure, which you probably don't need it for now.

Acceptance Testing

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

Time Estimate

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

Sub-Issues

Consider breaking the new feature down into sub-issues.

• Add a checkbox for each sub-issue here.

Relevant Deadlines

List relevant project deadlines here or state NONE.

Funding Source

2788881

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

• Review projects and select relevant Repository and Organization ones or add "alert:NEED PROJECT ASSIGNMENT" label
• Select milestone to next major version milestone or "Future Versions"

Define Related Issue(s)

Consider the impact to the other METplus components.

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

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.
• 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), Project(s), Milestone, and Linked issues
• Iterate until the reviewer(s) accept and merge your changes.
• Delete your fork or branch.
• Close this issue.

[georgemccabe]

Downloaded files for this use case to seneca:/d1/personal/mccabe/data/gfdl_etc
Info from an email from Guang Ping on 7/13/2021 about the data:

The GFDL tracker you are working on is somewhat different from mine. The only input my tracker needs are the model data and NHC issued TCvitals. I've put these data on Hera:
/scratch2/NCEPDEV/stmp1/Guang.Ping.Lou/tracks
gfs.2021071200.tar gfs.2021071212.tar gfs.2021071300.tar gfs.2021071312.tar
gfs.2021071206.tar gfs.2021071218.tar gfs.2021071306.tar syndat_tcvitals.2021

They are in GFS grib2 format and TCvitals is text file.
The resolution of the GFS data is 1.0 degree. Each tarball contains 180 hour forecasts with every 6 hour interval. The 7 tarballs represent 7 cycles from 2021071200 to 2021071312.

File syndat_tcvitals.2021 contains all NHC issued tcvitals for 2021. The tracker will get corresponding dates' tcvitals from this file in my tracker.
I don't need/have files "tcvit_rsmc_storms.txt" (was this just tcvitals?), and "nput.nml".

The fort.xx files you mentioned are probably generated from another code in the tracker system "supvit_main.f" that sorts out TCvitals.