New Use Case: GFDLTracker for TC tracking

[TaraJensen]

Replace italics below with details for this issue.

Describe the New Feature

Need to develop wrapper and use-case to run GFDL tracker in TC-tracking mode

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

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]

Here is some info from an email from Biswas with paths on Cheyenne to use for testing:

The compiled source code is at /glade/work/biswas/standalone_gfdl-vortextracker_v3.9a. I set up an HWRF output case for you on Cheyenne (/glade/work/biswas/data_tracker/hwrf_v3.9a). The input files are in GRIB1 format (file names should be in a similar format). There is a run.sh script that creates the grib index files. The namelist file (input.nml) list all the parameters needed to run the tracker incl file name info under &fnameinfo section. You need to run the tracker by <path_to_gettrk.exe>/gettrk.exe < input.nml (e.g. /glade/work/biswas/standalone_gfdl-vortextracker_v3.9a/standalone_gfdl-vortextracker_v3.9a/trk_exec/gettrk.exe < input.nml). It creates the fort.6* files. You may look at the fort.64 file which has all the TC info for all the forecast lead times. The tracker can be run with some other configurations (e.g. one big GRIB file etc).

[georgemccabe]

Update: I have developed a wrapper for the GFDL tracker and tested it using the data provided by Biswas on Cheyenne. The work is in a branch called feature_615_gfdl_tc_tracking. The output is being reviewed. To add this new use case to the automated tests, we will need to install the GFDL tracker for use in Docker. The Intel and PGI compilers are currently not available in the Docker container we have been using for the tests. Biswas forwarded an email with changes that a user made to install with gfortran/gcc. We will either have to get the supported compilers installed or add the patches needed to install using gfortran/gcc.