-
Notifications
You must be signed in to change notification settings - Fork 1
Visualize Wind Data #45
Comments
I'm not sure if you're aware, but sometimes wind is given in u and v vector components and other times in 2 separate fields as wind speed and wind direction. You'll want to check to see how it is in your data. |
@bonnystrong The NetCDF files we have break the wind data into u- and v-components. What do the u- and v-components mean? Is it something like knots east (for u; a negative value indicating that the wind is blowing west) and knots north (for v; a negative value indicating that the wind is blowing south)? |
@esheehan-gsl That's right. For the u-component of wind it is normally defined as m/s in the east direction (with negative values indicating west), and the v-component is m/s in the north direction (with negative values indicating south). |
Hi @esheehan-gsl, @BenjaminBlake-NOAA. Bonny asked me to chime in here if necessary, and I'll add one thing to what you both have discussed. Usually I think of the U and V components of wind being parallel to the x and y axis of the model domain. This means that in order to get a true earth relative wind direction, some rotation will be necessary at most grid points relative to the orientation longitude of the domain. However, this is all irrelevant if the rotation has already happened before the model output is generated. Grib2 has a metadata flag indicating if winds are already rotated to earth relative (N/S) or remain model relative, so hopefully netCDF has an equivalent |
@BenjaminBlake-NOAA hmm… I’m not seeing anything in the NetCDF file’s data variables that looks like it might indicate whether the vectors were rotated or not. @guoqing-noaa, @terraladwig, do either of you know whether the wind vector components are relative to the model domain or to the earth? |
@esheehan-gsl I think sometimes they are grid-relative winds and other times they are Earth relative, but yeah unfortunately I don't know of a good way to check netcdf files for that information. I know how to look for it with grib2 files though. Maybe Guoqing or Terra will know more. |
Winds from the diagnostic files from the data assimilation step (GSI) should be earth relative (i.e. consistent with the observation with which they are paired to generation the observation minus forecast). |
Thanks, Jacob. Alright, my next question is: how do I interpret these values? Given some location for an observation Can I calculate the wind speed simply by taking magnitude of (u, v) like this: If I want draw a line on a map to indicate the direction of the wind, is it as simple as drawing from |
Yes - that calculation is correct for wind speed. To calculate wind direction in degrees, interpreted the direction from which the wind is blowing, on would do (forgive my notation): And probably add a final check so that dir is between 0-360deg. Not sure if that answers your question. But everything vector and vector calculus-related applies here. |
It makes things a lot more clear. I have a couple more questions. Is With this calculation does a direction of 0° (or 360°) indicate that the wind is blowing due North and 90° is due East? |
excellent. Yeah it's the same function as the numpy arctan2.
Close. 0deg (or 360deg) is blowing from North and 90deg is from east. |
Alright, I just need to double-check my understanding so that I’m sure my tests are testing the right values. If we have an observation whose If we have an observation whose And if we had an observation whose Do I have all of that correct? |
I think I might be adding some confusion here. See this page page from the NCL documentation which has a few examples: http://ncl.ucar.edu/Document/Functions/Contributed/wind_direction.shtml |
No, I think you explained it well, I just may not have articulated it back clearly. I checked the examples in the NCL docs against the values I had written into my test case and they all matched. |
It sounds like you got it now, but I will repeat your examples with the correct descriptions... If we have an observation whose u component is -1 and v component is 0, we would expect the direction to be reported as 90° because it is blowing from East to West. And if we had an observation whose u component is 1 and whose v component is -1, we would expect the direction to be reported as 315° because it is blowing from the Northwest to Southeast. |
Problem
Add wind as another variable to the application.
Wind is a vector, so adding support for wind in the application will help us develop appropriate visualizations for vector variables (in addition to scalar variables, like temperature).
Solution
We can treat wind speed and direction as scalar values and show the same kinds of histograms for$O - B$ and $O - A$ that we did for temperature. Wind speed (in meters per second) is the magnitude of the vector ($u, v$ ).
Wind direction can be calculated thus:
This gives the direction in degrees where 0° indicates the wind is blowing from the North, 90° indicates it’s blowing from the East, etc.
In addition to the distributions of these two scalar values, we can plot the wind vectors on a map to highlight how different geographic areas performed in during data assimilation.
No Gos
We will not add UI for adding/removing variables to the display. Eventually we will want to give users control over what variables are displayed and how they’re visualized—e.g. add wind to the display and choose to display it as a scalar (speed or direction histograms) or a vector (map). For now, we will just hard-code all of these displays into the UI.
We will not support zooming on the map yet.
Rabbit Holes
We could end up spending a lot of time getting geographic border data displaying in the map to provide context. For now, we’ll stick with state and continent borders so that we don’t have to deal with optimizing county borders (which can be a lot of data) and determining when it is appropriate to display them.
Tasks
The text was updated successfully, but these errors were encountered: