New Use Case: Buoy wave heights to wave watch model III output via GFSv16

[j-opatz]

Describe the New Use Case

This use case will look at Altimeter wave heights, comparing their output to the wave watch model. This is timely, as the next wave watch model upgrade is integrated in the GEFS and GFS.

Use Case Name and Category

Use case name is unknown for now, but should follow:
PointStat_fcstGFS_obsNDBC_WaveHeight

Note that WaveWatch output, the model of focus, is included in GFS and GEFS.

This use case can reside in the Marine_and_Cryosphere category, as it deals with wave heights.

Input Data

Fcst source: wave watch model data (need size, type)
Obs source: NDBC buoy Altimeter data (ASCII, ranging in size from 600KB to 2.5KB)

Work to ingest the Altimeter wave height data was previously accomplished by Jake Campbell, who graciously provided his scripts to us for use. This work included taking the above data sources and combining them into a conglomerate netCDF, which this use case will be provided.

George pulled copies onto Seneca, under: /d1/projects/METplus/METplus_Data/development/WW3_data.

Acceptance Testing

Success of this use case will be two things: a successful run through METplus with the datasets listed above, and meaningful output for OPC that their center can utilize.

As use case develops, provide a run time here

Time Estimate

1-3 days
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

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)
• Select privacy

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, METdatadb, METviewer, METexpress, METcalcpy, METplotpy

New Use Case 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 your changes. Merge branch into develop.
• Create a second pull request to merge develop into develop-ref, following the same steps for the first pull request.
• Delete your fork or branch.
• Close this issue.

[j-opatz]

Current work is waiting on release of a new data output; buoy data is released on a 45 day window, with data newer than 45 days being included in a bulk release that is not QC'd (quality controlled). While the data could be downloaded and reordered in a way that allows METplus work to resume, the possibility of bad observations is undesirable and outweighs the wait time drawbacks.
In the meantime, WW3 data and altimeter data has been assembled and work is expected to resume at a quick pace once the accompanying buoy data is made available.

[j-opatz]

Work on the Python embedding script was slow moving; the field setup to be accessible via MET's tools (e.g. Point-Stat) was very convoluted, and is prompting development to investigate why there is an error when passing anything above 145 stations. That issue can be found here: 2292.

This work has also kicked off the discussion of allowing users to utilize the 11-column method for ingesting point data via point_data dictionaries in addition to the met_point_data dictionary. That work is described here: 2285.

While both of these issues are opportunities for improvement, 2292 would be required for this use case to proceed forward. With the limited time and full schedules ahead, that may not be an option.

There has been concurrent work on getting standard buoy data (defined as those observations in the < 45 days old category) read in natively via ASCII2NC. This work is documented in 2276. This issue has moved into the PR stage and will quickly be in the develop branch of MET.

In the interest of releasing this use case in beta4, work will pivot slightly: the Python script currently being developed will be shelved, to be corrected when time and funding permits (and to provide a desperately needed example of reading in point data and passing it via Python to PointStat), and instead utilize a two-step system. The first step will be to call ASCII2NC's new buoy data reading ability and read in ~100 stations worth of data. The second step will call PointStat to read in the resulting netCDF file and verify against the WW3 data.

Because of this quick pivot, a final change will be made to the use case. Instead of the additional verification against satellite, this use case will focus solely on WW3 and buoy data. The comparison between WW3 model data and satellite wave heights can be done at a later time.

[j-opatz]

The planned satellite altimeter observation comparison has been shelved in the interest of time. The following has been moved from the original use case description for posterity:
link to webpage that showcases the data.
https://coastwatch.noaa.gov/cw/satellite-data-products/sea-surface-height/along-track.html <- this is a source for several satellite datasets, including Jason 3, Sentinel-3A/3B, CryoSat-2, and SARAL.