Bugfix #2841 develop tang_rad_winds

[JohnHalleyGotway]

Expected Differences

Please review this at the same time as PR #2920, to fix this bug in the main_v11.1 branch.

• Do these changes introduce new tools, command line arguments, or configuration file options? [No]
  
  If yes, please describe:
  

• Do these changes modify the structure of existing or add new output data types (e.g. statistic line types or NetCDF variables)? [No]
  
  If yes, please describe:
  

Pull Request Testing

• Describe testing already performed for these changes:
  
  Confirmed that the diffs flagged for this PR are limited to 5 output files from tc_rmw, rmw_analysis, and tc_diag:

file1: /data/output/met_test_truth/rmw_analysis/rmw_analysis_out.nc
file1: /data/output/met_test_truth/tc_diag/sal092022_gfso_doper_2022092400_cyl_grid_parent.nc
file1: /data/output/met_test_truth/tc_diag/sal092022_gfso_doper_2022092400_diag.nc
file1: /data/output/met_test_truth/tc_rmw/tc_rmw_hwrf_gonzalo.nc
file1: /data/output/met_test_truth/tc_rmw/tc_rmw_pressure_lev_out.nc

4 of these are the same as the diffs for PR #2920. But the TC-Diag file (file1: /data/output/met_test_truth/tc_diag/sal092022_gfso_doper_2022092400_diag.nc) is the new difference for this PR.

I used ncdump to dump to ascii and compare the results. Some diffs are way out in the 8th or more decimal place, but real differences only occur for 850TANG, 850VORT, and 200DVRG as planned/hoped:

I'll note that while the diagnostics are modified, they do not resolve the discrepancies noted in MET #2729.

• Recommend testing for the reviewer(s) to perform, including the location of input datasets, and any additional instructions:
  

Please find the code for testing on seneca in:
/d1/projects/MET/MET_pull_requests/met-12.0.0/beta5/MET-bugfix_2841_develop_tang_rad_winds

• Do these changes include sufficient documentation updates, ensuring that no errors or warnings exist in the build of the documentation? [Yes]
  I updated the docs to clarify that azimuths are in degrees counter-clockwise from due east.

You can find the updated documentation for this PR at this link:
https://met--2921.org.readthedocs.build/en/2921/Users_Guide/tc-rmw.html

• Do these changes include sufficient testing updates? [Yes]
  No new tests are needed, but output from existing tests will change.

• Will this PR result in changes to the MET test suite? [Yes]
  
  If yes, describe the new output and/or changes to the existing output:
  
  Modifies all output from TC-RMW and TC-Diag.

• Will this PR result in changes to existing METplus Use Cases? [Yes]
  
  If yes, create a new Update Truth METplus issue to describe them.
  Output from any unit tests that run TC-RMW or TC-Diag will be modified.

• Do these changes introduce new SonarQube findings? [???]
  
  If yes, please describe:
  Unknown.

• Please complete this pull request review by [Fri 5/21/24].
  
  The main_v11.1 bugfix (PR Bugfix #2841 main_v11.1 tang_rad_winds #2920) is needed by 6/21/24 to be included in the MET-11.1.1 bugfix release on that date.

Pull Request Checklist

See the METplus Workflow for details.

• Review the source issue metadata (required labels, projects, and milestone).
• Complete the PR definition above.
• Ensure the PR title matches the feature or bugfix branch name.
• Define the PR metadata, as permissions allow.
  Select: Reviewer(s) and Development issue
  Select: Milestone as the version that will include these changes
  Select: Coordinated METplus-X.Y Support project for bugfix releases or MET-X.Y.Z Development project for official releases
• After submitting the PR, select the ⚙️ icon in the Development section of the right hand sidebar. Search for the issue that this PR will close and select it, if it is not already selected.
• After the PR is approved, merge your changes. If permissions do not allow this, request that the reviewer do the merge.
• Close the linked issue and delete your feature or bugfix branch from GitHub.

[JohnHalleyGotway]

@JohnHalleyGotway and @KathrynNewman met to review this PR and found the following:

• The lat/lon location for azimuth = 0 degrees is correct, meaning that it now points due east which matches the HAFS python plotting script logic.
• However, while MET rotates through azimuths in a counter-clockwise direction, the HAFS plotting script does it clockwise.
• Recommend updating MET to also rotate through the azimuths in a clockwise direction.

[JohnHalleyGotway]

I was able to update the logic in tcrmw_grid.cc to reverse the x dimension of the range-azimuth grid, effectively switching from a counterclockwise rotation of azimuths to clockwise. Here's what that change looks like in the latitudes:

Moving left to right, as the azimuth increases from 0 degrees to 360 degrees, the CCW data on the left INCREASES in latitude before decreasing. Whereas the updated CW data on the right DECREASES in latitude before increasing.

A similar result can be seen in the reversed pattern of the range/azimuth gridded data. Here's 500mb RH, CCW on the left and CW on the right:

I also see the clockwise rotation by inspecting the lat/lon locations reported in the DEBUG(4) log messages from by TC-RMW. Compare the center point to the lat/lon of 4 points for range ~= 200km. Here's a selection:

DEBUG 4: wind_ne_to_rt() -> center lat/lon (25.3, 84.8), range (km): 199.8, azimuth (deg): 0, point lat/lon (25.2867, 82.8149), uv (-22.29, 3.51), radial wind: -22.29, tangential wind: 3.51
DEBUG 4: wind_ne_to_rt() -> center lat/lon (25.3, 84.8), range (km): 199.8, azimuth (deg): 90, point lat/lon (23.5052, 84.8), uv (-21.41, 2.45), radial wind: 2.45, tangential wind: 21.41
DEBUG 4: wind_ne_to_rt() -> center lat/lon (25.3, 84.8), range (km): 199.8, azimuth (deg): 180, point lat/lon (25.2867, 86.7851), uv (-18.19, 3.81), radial wind: 18.19, tangential wind: -3.81
DEBUG 4: wind_ne_to_rt() -> center lat/lon (25.3, 84.8), range (km): 199.8, azimuth (deg): 270, point lat/lon (27.0948, 84.8), uv (-20.07, 3.66), radial wind: -3.66, tangential wind: -20.07

Note that I also dumped the data from some of these lines into Excel to "manually" derive radial and tangential winds to confirm that MET is computing them correctly. The manual output matches the values reported by MET.

I also compared the U/V values reported in these log messages to the values shown in the NetCDF range-azimuth file and confirmed that they are consistent... just to make sure there wasn't a problem in how the data is being read from the file.