Bugfix- WindRose plot shows incorrect legend when max wind speed is less than requested

[bikegeek]

Describe the Problem

When users request the max wind rose break that is above the maximum wind speed in the data,
the legend for the last break is incorrect. For instance, the data has a max wind speed of 11, but 12 was requested for the max in the wind_rose_break setting. The legend shows the max wind rose break as 12-11 m/s.

When this is encountered, do NOT include this information in the legend.

Expected Behavior

Provide a clear and concise description of what you expected to happen here.

Environment

Describe your runtime environment:
1. Machine: (e.g. HPC name, Linux Workstation, Mac Laptop)
2. OS: (e.g. RedHat Linux, MacOS)
3. Software version number(s)

To Reproduce

Describe the steps to reproduce the behavior:
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error
Post relevant sample data following these instructions:
https://dtcenter.org/community-code/model-evaluation-tools-met/met-help-desk#ftp

Relevant Deadlines

List relevant project deadlines here or state NONE.

Funding Source

2702701 NCAR Base for Opt 3 listed below

Define the Metadata

Assignee

• Select engineer(s) or no engineer required
• Select scientist(s) or no scientist required

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

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.
• Add any new Python packages to the METplus Components Python Requirements table.
• 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: METplotpy-X.Y.Z Development project for development toward the next official release
• Close this issue.

[pfisterggp]

Currently the wind roses take the values of fcst and obs separately to define the top break and distribution of frequency circles. This makes it hard to compare fcst and obs directly. Having both fcst and obs wind rose use the same breaks and frequency rings would allow to directly compare the wind rose plots for forecast and observations.
I did take a look at wind_rose.py in METplotpy and it seems to overwrite the top wind speed break with the one specified in the yaml file, one only needs to comment out line 255:
breaks.append(max(wind_speed))
However, then the problem is that the code seems to ignore any of the wind speeds higher than the top break in the plotting, so that's also not helping. So I wonder if the solution would be to set the top break to the maximum value from measured and forecasted wind speeds? And do the same for the frequency?

[CPKalb]

As an additional note, it looks like the code actually takes the maximum wind speed and adds a bin on to the top that runs from the last user specified bound to the maximum of the data. I don't believe any data is ignored in the creation of the wind rose plot.

[CPKalb]

I'm honestly not sure what the best path forward would be here. I can see in lines 192 - 200 of the wind rose code, the dataset is selected (either forecast, observation, or difference). The wind rose plot proceeds to calculate wind speed and direction from the u and v components, so we only have the maximum for the dataset we are plotting. It seems like we have a few potential paths forward, most of which Minna mentioned in her email:

1. Enhance the code to calculate the wind speed and direction for both the model and observations and use the max wind speed from here. The main drawback of doing this would be that both datasets would need to be present to calculate a wind rose (rather than just one that we need now). This will make the code longer, and we would need to determine if we want to continue supporting the ability to make a single wind rose without having both the model and observations.
2. Allow the user to specify the maximum wind speed to be plotted. The main drawback of doing this would be that we would omit values if our data max is greater than the maximum we specify, which is not desirable.
3. Omit the last wind rose break and corresponding marker when the max requested is greater than the data max. The drawback here is that although the wind roses would still be comparable between the model and observations, their labels will not be exactly the same.
4. Adjust the legend to correctly order the values (ie. 12-11 becomes 11-12). The drawback of this is that the bin below would still be labeled as 8 - 12, so I think it's perhaps equally as confusing as the current behavior.

Personally I would vote for either 1 or 3. I think selecting 2 and 4 could cause other problems moving forward that would also be undesirable.

[pfisterggp]

Thanks for the analysis, Tina. Either 1 or 3 would be ok with me. I agree that 2 and 4 are too confusing.