Generalize support for automated derivation of wind speed and direction and rotation of winds from grid to earth-relative

[JohnHalleyGotway]

Describe the New Feature

This issue arose when applying MET to the Air Force testing and evaluation projects. The MET tools have the ability to automatically derive wind speed and direction on the fly from the U and V components. However, that derivation only works for GRIB1/2 datasets and when the U and V components are named UGRD and VGRD, respectively.

This task is to generalize MET's support for the derivation of winds in the following contexts:

• When processing NetCDF input files.
• When processing GRIB1/2 files where the U/V variables are NOT named UGRD/VGRD (e.g. the Air Force names them U/V).
• Also consider the reverse, deriving U/V from the wind speed and direction variables.

These tasks apply to the processing of gridded fields of data... and not point observations. The MET library code needs to know how wind components are named.

One possible solution to consider is adding a new "map" entry to the ConfigConstants file (https://github.com/dtcenter/MET/blob/main_v9.1/met/data/config/ConfigConstants). Something like:

wind_variable_names_map = [
 { key = "U_WIND";         val = "UGRD,U,UU";     },
 { key = "V_WIND";         val = "VGRD,V,VV";     },
 { key = "WIND_SPEED";     val = "WIND,WIND_SPD"; },
 { key = "WIND_DIRECTION"; val = "WDIR,WIND_DIR"; }
];

These define a group of variable names for each of the wind components. Enhance the is_u_wind()/is_v_wind()/is_wind_speed()/is_wind_direction() functions to check this mapping.

We need to make sure this solution works for all the MET tools, including the preprocessing (pcp_combine, gen_vx_mask), statistics tools, and plotting (plot_data_plane).

Remember to add/update unit tests to exercise this new functionality.

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 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

• 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.

[JohnHalleyGotway]

On 2/16/21, Liz pointed out that NRL needs python embedding to support U and V wind components, meaning create VCNT line type via python embedding.

[mpm-meto]

Met Office have an increasingly urgent requirement for this capability to verify output from an AI NWP model.

[JohnHalleyGotway]

A related topic was discussed in dtcenter/METplus#2370. MET should also be enhanced to handle wind rotation from grid to earth-relative for non-GRIB inputs.

Ideally, we'd like for MET to be able to read U/V input or Wind Speed/Direction inputs, automatically rotate them when needed, and then verify them against observations of U/V wind or Wind Speed/Direction.

[mpm-meto]

dtcenter/METplus#2410 discussion refers. I was wondering where we are with prioritising support of netcdf wind speed derivation (a la GRIB WIND) and the support for is_u_wind and is_v_wind for EnsembleStat as it is currently only in PointStat and GridStat. Has this been considered for MET12.0.0?