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

JohnHalleyGotway commented 3 years ago

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 commented 3 years ago

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.

scatt11 commented 2 years ago

Hello there, Just chiming in to add support for this new feature. The ability to do this with netCDF would be very beneficial! The particular use case in mind is validating 10-meter windspeed from raw wrfout.nc files. Python embedding is a workaround, but that a much less streamlined process. Further, that leaves more room for user's to make errors. Lastly, the 2D limitation for python embedding makes this process quite tedious to validate for the duration of a WRF simulation.

mpm-meto commented 1 year ago

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

JohnHalleyGotway commented 11 months ago

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 commented 3 weeks ago

https://github.com/dtcenter/METplus/discussions/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?

dtcenter / MET