New Use Case: Verify 15min WRF-LES forecasts using high temporal resolution ARL tower observations

[DanielAdriaansen]

John Raby from the Army Research Laboratory shared a use case during the November 2023 Advanced Training Series for Python embedding. Many details can be found in #2469. A summary of my understanding of the use case is provided here.

Describe the New Use Case

Observation data (non-standard text format):

• air temperature
• relative humidity
• pressure
• U wind
• V wind

Observation levels:

• 2m
• 10m

Observation times:
U wind/V wind:
20 times per second, or 1200 times per minute, or 18,000 times per 15 minues
Temperature/RH/Pressure:
1 time per second, 60 times per minute, 900 times per 15 minutes

Forecast data (GRIBv2 format):

• TMP
• RH
• UGRD
• VGRD

Forecast levels:
Custom application to align with obs

Forecast times:
Every 15 minutes (:00, :15, :30, :45)

Goals:

• Run point_stat to verify the WRF data at the tower locations
• Time average the observations in 15 minute windows around the forecast valid times (e.g. :52:30 - :07:30, :07:30-22:30, :22:30-:37:30, :37:30-:52:30 for :00, :15, :30, and :45 valid times).
• Determine whether ASCII2NC time_summary option can be used instead of Python embedding
• Perhaps use Python embedding if custom averaging or other requirements outside MET functionality is required
• Coordinate with user on matching forecast data at 2m and 10m with the observations at 2m and 10m

Use Case Name and Category

Provide use case name, following Contributor's Guide naming template, and list which category the use case will reside in.
If a new category is needed for this use case, provide its name and brief justification

Input Data

Sample data are here: seneca:/d1/projects/METplus/discussions/2469

Acceptance Testing

Describe tests required for new functionality.
As use case develops, provide a run time here

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

Projects and Milestone

• Select Repository and/or Organization level Project(s) or add alert: NEED CYCLE 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, METdataio, 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.
• Add any new Python packages to the METplus Components Python Requirements table.
• 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 Development 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.

[jwraby]

Just to clarify that ARL does not having any funding to support the development of this new use case. Another clarification regarding the "Observation times" is that the description given above (20 times per second) is accurate for the wind component observations.. For the TMP and RH observations, the times are 1 time per second.

[DanielAdriaansen]

Just to clarify that ARL does not having any funding to support the development of this new use case. Another clarification regarding the "Observation times" is that the description given above (20 times per second) is accurate for the wind component observations.. For the TMP and RH observations, the times are 1 time per second.

Thanks @jwraby, I have edited the description to reflect the timing of the observations accurately. Noted on the funding.

[jwraby]

Thanks @DanielAdriaansen . Good catch on the pressure obs.

[jwraby]

Hi @DanielAdriaansen. Just wanted to clarify that I haven't used Python embedding for the testing I've done for this project. The new discussion at #2498 is related to this issue (2487) as I'm still looking for a way to improve the way that the tower observations are reformatted into the 11-col format. The new discussion is about a problem I'm having with getting Point-Stat to generate matched pairs for the tower observations which are at non-standard AGL levels such as TMP at 10m AGL and UGRD/VGRD at 2m AGL. I had been using vertical level verification by assigning the non-standard observations the message type ADPUPA and verifying on a pressure level, but I think it would be be better to verify on fixed AGL levels is possible. If the problem identified in the discussion (2498) can be resolved then then all the tower observations will be verified on fixed AGL levels.

[jwraby]

The use of ARL tower data is still an ongoing research project for us. Just learned that the U-wind (UGRD) and V-winds (VGRD) in the sample tower data files which were provided to Julie Prestopnik to support this issue are formatted so that the U and V wind components do not use the WRF standard for orientation. The Gill sonic anemometers on the towers are oriented such that there is a 90 degree difference between the WRF orientation and the sonic measurements. Stated more simply, U+ (gill) = V+ (wrf) and V+ (gill) = -U (wrf). I believe that the following logic statements will convert the sonic UGRD and VGRD into the WRF convention which is the standard used by MET:
IF U+ and V+ then transform the values to U- and V+
IF U+ and V- then transform the values to U+ and V+
IF U- and V+ then transform the values to U- and V-
IF U- and V- then transform the values to U+ and V-
I will send an Excel spreadsheet to Julie P. which provides a diagram of both orientations and some examples of the transformation from the sonic orientation to the WRF orientation that I used to derive the conversion logic. If you see an issue with my logic feel free to contact me. Thanks and sorry for bringing up this change at this time and not before.

[jprestop]

@jwraby Thanks for sending along the spreadsheet.

@DanielAdriaansen @georgemccabe @j-opatz I have put this sonic_anemometer_winds.xlsx spreadsheet with the other data and documentation from #2469 on seneca at /d1/projects/METplus/discussions/2469.

[jwraby]

After consultation with our modeler, I have come to the conclusion that the use of UPP post-processed output for the ARL tower data at the non-standard levels (2m AGL winds and 10m AGL TMP) is not considered suitable for use in our verification for the WRF-LES. We plan to try verifying these variables using vertical level verification on the model pressure level 869 hPa. This approach is described in the Word document provided to Julie Prestopnik in support this use case. This document is named "20220705 test case.docx. I believe that the data was distributed to DTC on seneca at /d1/projects/METplus/discussions/2469.