-
Notifications
You must be signed in to change notification settings - Fork 26
Description
Describe the Problem
During development for issue #2729, I uncovered problems in how the range/azimuth grids are defined based on the configuration file settings. These grids are used by the by the TC-Diag and TC-RMW tools.
- There is an off-by-one error when defining the azimuths.
This issue is in the TcrmwGrid::set_from_data(const TcrmwData & d)
function on this line of code:
# INCORRECT
RLLD.delta_rot_lon = 360.0/(Azimuth_n - 1);
The longitude rotation increment is defined as the number azimuths minus 1, and that - 1
should be removed. While doing development for #2729 and comparing the diagnostic output produced by TC-Diag to the output from the Python TC Diagnostics code, removing the - 1
made the previously inconsistent results much, much closer.
- There is an off-by-one error when defining the range increment.
Internally, MET computes and stores the maximum range value. Since the ranges always start with a range of 0 km, this line of code is correct. We should divide by n-1 when computing the range delta:
# CORRECT
RLLD.delta_rot_lat = range_max_deg/(Range_n - 1);
One bug is in the TC-RMW source code when defining that maximum range value on this line of code. We are multiplying by n_range
when it should be n_range-1
.
Another bug is in the TC-Diag source code when defining that maximum range value of this line of code. We are multiplying by n_range
when it should be n_range - 1
.
- TC-RMW always defines ranges relative to the radius of maximum wind and never as a fixed number of kilometers.
That same TC-RMW line of code from above contains another bug. Note that we're always multiplying by the radius of maximum winds to define the maximum range. The logic to differentiate between RMW ranges and fixed KM ranges is missing.
- The RMW grid configuration options are over-specified.
In the TC-RMW config file, specifying n_range
, max_range_km
, and delta_range_km
(or rmw_scale
) over-specifies the ranges. Only 2 of the 3 are actually required. After consulting with @KathrynNewman, we determined that max_range_km
should be removed, and rmw_scale
should be set to a default value of bad data (i.e. NA
).
To be consistent with the existing documentation, if rmw_scale
is set to something other than NA
, its value should take precedence over the delta_range_km
setting.
Note that the TC-RMW application code needs to be updated to implement this logic correctly.
Expected Behavior
The longitudinal rotation increment should be be computed simply as 360 divided by the number of azimuths (360.0/Azimuth_n
). This differs from the latitudinal increment for which Range_n - 1
really should be used. Since the xml/unit_tc_rmw.xml
tests use 180 azimuths, it's easy to overlook this very small difference in results since the 360/180 and 360/179 are very similar numbers.
To Reproduce
I tested this using the simplest setup I could imagine, using only 2 azimuths. With only 2 azimuths, the bug is obvious:
RLLD.delta_rot_lon = 360.0/(Azimuth_n - 1) = 360 / (2 - 1) = 360
... versus ...
RLLD.delta_rot_lon = 360.0/Azimuth_n = 360 / 2 = 180
With this bug in place, rotating a fully 360 degrees should result in identical values being extracted for both azimuths. And indeed, that's exactly the behavior I found.
Describe the steps to reproduce the behavior:
1. Modify internal/test_unit/config/TCRMWConfig_pressure_lev_out
by changing:
-n_azimuth = 180;
+n_azimuth = 2;
2. Run perl/unit.pl xml/unit_tc_rmw.xml
3. Observe the duplicate output values:
ncdump -v TMP test_output/tc_rmw/tc_rmw_pressure_lev_out.nc
TMP =
302.540002441406, 302.540002441406,
302.615292718035, 302.615292718035,
302.690582994665, 302.690582994665,
302.2719353873, 302.2719353873,
301.782571564577, 301.782571564577,
...
Setting n_azimuth = 2
should extract values from opposite sides of the storm but clearly the same values are being extracted 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: Recommend asking @KathrynNewman to review.
Labels
- Review default alert labels
- Select component(s)
- Select priority
- Select requestor(s)
Milestone and Projects
- Select Milestone as the next bugfix version
- Select Coordinated METplus-X.Y Support project for support of the current coordinated release
- Select MET-X.Y.Z Development project for development toward the next official release
Define Related Issue(s)
Consider the impact to the other METplus components.
- METplus, MET, METdataio, METviewer, METexpress, METcalcpy, METplotpy
No impacts, but will change the results of existing METplus use cases. - Remove the
TC_RMW_MAX_RANGE_KM
configuration option METplus#2513 to remove thetc_rmw_max_range_km
config option from the TC-RMW wrapper. - Update Truth: For dtcenter/MET#2840 METplus#2526 to update the METplus truth data due to TC-RMW and TC-Diag diffs.
Bugfix 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 main_<Version>.
Branch name:bugfix_<Issue Number>_main_<Version>_<Description>
- Fix the bug 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 main_<Version>.
Pull request:bugfix <Issue Number> main_<Version> <Description>
- Define the pull request metadata, as permissions allow.
Select: Reviewer(s) and Development issue
Select: Milestone as the next bugfix version
Select: Coordinated METplus-X.Y Support project for support of the current coordinated release - Iterate until the reviewer(s) accept and merge your changes.
- Delete your fork or branch.
- Complete the steps above to fix the bug on the develop branch.
Branch name:bugfix_<Issue Number>_develop_<Description>
Pull request:bugfix <Issue Number> develop <Description>
Select: Reviewer(s) and Development issue
Select: Milestone as the next official version
Select: MET-X.Y.Z Development project for development toward the next official release - Close this issue.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status