Wind Direction in Grib2 Model Forecasts

Errata added May 18, 2023. 

This article was intended to point out a limitation in the HRRR data provided by several sources in that the wind directions on the two US coasts could be off by 10 to 15º. Several sources corrected the output shortly after this observation was reported, but others took longer to correct. Now we can report that all sources we originally referred to have updated the data output.  It appears now that the HRRR data  from the various public sources  are now identical to what we would get from a direct NOAA download. We have not confirmed this for the other models in grib 2 Lambert format shown below.

____________

Our lead weather instructor, Dave Wilkinson, serves on the race committee boat for setting up the race courses based on local forecasts in Port Townsend, WA. He uses several regional models for this, but his workhorse has been NOAA's High Resolution Rapid Refresh model (HRRR). He obtains the forecasts and views the data by two independent methods: the LuckGrib app running in an iPad and the qtVlm app running on a PC laptop. LuckGrib provides the HRRR data directly from their server; qtVlm offers an internal method of getting the data from a third party server.

As races came and went, he noticed a consistent discrepancy in these two presentations of what we all thought was the identical forecast—double-checking that the area covered, and, more importantly, the computational time of the forecasts were the same. HRRR is updated every hour and extends out 18 hr.

qtVlm has a convenient way to make this comparison as we can load both grib files and show them overlaid with different wind barb colors, as shown below.

The white barbs are from the LuckGrib server; the red wind is from a third party server we call S1 below. We see there is a consistent shift in direction. We have an even better way to compare this in qtVlm by opening a meteogram on the page and then selecting Compare gribs.

Now see more specifically that the wind speeds are about the same, but the directions are shifted about 18º in this example.  The slight differences in speed can be understood as noted later, but the direction issue must be sorted out—as we learn below, this difference depends on both the source of the HRRR forecast and the grib viewer software in use.  Also looking ahead, I am using HRRR model data for this analysis, but this issue also applies to other popular model data such as NAM, and others.

To my knowledge, there are 5 or 6 popular sources (apps and online services) for the HRRR model data, one of which is the primary source at NOMADS, which individual navigators can access though the NOMADS Grib Filter option—although that is more work than the push-button sources available elsewhere.

For now we look at four sources, LuckGrib (LG), NOMADS (NM), and two others, S1 and S2, and for now we use  three different apps to view the data, LuckGrib and two other apps we found that can read and display the files in question called here app A1 and app A2—although it is important to stress that neither one of these apps advertise that they support the type of file we are looking at. Thus anomalies in display are not unexpected.  I make these comparisons in any event because it is common for navigators to use files from various sources in their weather analysis, especially when the data may be unique high-resolution products.

Shown below are only part of the data studied: just 1 location and 1 time—conclusions were double-checked using a second time and a second location in each of the four data files. The data being used are from the 12h forecast (of the 19 available) computed on 9/9/22 at 21z, making it valid at 09z on 9/10/22. My reasons for singling out the LuckGrib products will be clear shortly.

First a look at what we see, then a look into what might be taking place.

We are looking at a unique model forecast that originated at NOMADS, but in its travels and display something changed. Every app and every source agrees on the HRRR wind speed forecast for this location and moment in time, but they do not agree on its direction. The directions in this table should all be the same. The fact that they differ means something is wrong. We see three directions (290, 306, and 322) and I think we can understand where the differences come from. 

The HRRR model data is in the grib2 format, but more to the the point here, the model is computed on a Lambert conformal map projection (grid), which is similar to a great circle projection, whereas all grib1 data (and some grib2 data) are on a rectangular coordinate system, similar to Mercator or an equidistant Lat-Lon grid. 

Looking into how the grib files are presented and wind directions defined, I believe that this coordinate system distinction is the source of the issue at hand, along with its broader implications. Most of the US high-res models use this Lambert grid, which is notably tilted relative to a rectangular grid over many areas. Below shows the coverage distribution of several grib2 models that are not on a rectangular grid. Images from the LuckGrib Model Explorer function.

The issue comes about because the model computation in grib2 has the option to specify wind directions relative to either the grid orientation or what they call N/S. It is possible to look into a grib file to see what choice has been made using a tool called wgrib2. We then ask for the parameter vector_dir. Here are those results for the four sources in hand:

C:\Users\macdavid\Desktop\wgrib2>wgrib2 -var -vector_dir LG_HRRR.20220909.21.grb2

1:0:UGRD:winds(N/S)

2:335:VGRD:winds(N/S)

C:\Users\macdavid\Desktop\wgrib2>wgrib2 -var -vector_dir  NM_NOMADS_direct_HRRR.grb2

1:0:UGRD:winds(grid)

2:545:VGRD:winds(grid)

C:\Users\macdavid\Desktop\wgrib2>wgrib2 -var -vector_dir S2_HRRR_09_09Sep22_224022.grb

1.1:0:UGRD:winds(grid)

1.2:0:VGRD:winds(grid)

We cannot run wgrib2 on the S1 file, because that source is actually a custom one that has been converted from grib2 to grib1, which is in general a tremendous service for mariners who do not have an app that will display grib2 data.

Wind in most grib files (not all) is presented as a vector, giving the E-W speed (UGRD) and N-S speed (VGRD) in m/s, then the display app computes the direction and magnitude from these components.

What we learn from this is that NOMADS themselves publish the HRRR data with the reference direction aligned with the grid and not with N/S.  This is also true for the source we call S2.  Source S1 is automatically N/S, because that is all that grib1 has.

And we see the notable thing about the LuckGrib data that is what led me to focus this note around that product. LuckGrib has taken the raw data from NOMADS and converted it to N/S, so if the data are exported to another app that is limited to N/S they will still be able to read it properly. 

So to read the wind direction properly from a NOMADS model with grid reference, we either need to get it from a source that has converted grid to N/S, or we need an app that recognizes this parameter (vector_dir) and makes the correction at the display stage. LuckGrib actually does both. Note in the table above that LuckGrib gets the right wind direction from NOMADS directly (NM) as well as from S2, both of which are grid referenced files, and it gets it right from its own data (LG) which are N/S referenced.

Looking at the table above for app A1, we see that it gets the direction right for LG data, but it gets it wrong for the other 3 sources, and I think there are two independent reasons for that. First, it seems that this version of app A1 is not making the grid to N/S correction, so it treats all wind as referenced to N/S, which for gridded data at this location is an error of 16º (discussed below). But these S2 and NM results also agree with the S1 results, which is grib1 and thus automatically N/S. This seems to tell us that S1, when they converted grib2 to grib1, did not make the conversion of the reference. So that the  S1 source of HRRR is off in wind direction by the local angle between the grid orientation and N/S.

When we turn to the app A2 results, we see something still different. It has the direction right with the LG data, which is N/S, and it has the same error in the S1 data as app A1 reported, so it seems that it is reading N/S info correctly, but on the two sources with grid reference it does not get the right value.  Instead of converting the 306 to 290 by subtracting 16º it appears that it added the 16 to the 306 to get 322. In other words, it appears that this version of app A2 is making the grid to N/S correction, but applying the correction in the wrong direction.

At least that is how I see it, based on the pictures below.

This display in LuckGrib puts a dot on the actual grid points. Wind barbs in between are interpolated. Most grib viewers let users show such a display or show just wind on the actual grid points, which is an important option to prevent us from over estimating the resolution of the actual data.

By drawing a line (or leg of a route) between grid points you can read the orientation of the grid at your location, in this case it is 344T, which is 16º to the left of north.

Below we look at wind directions relative to the grid and to the N/S line.       

Since we do see app interactions with the grib files, I double-checked the actual content of the grib files using another function of wgrib2. This one lets us ask for the specific values it contains for a specific location. Here we ask for the UGRD and VGRD components at the point and time in question.

This is a section of a homemade spreadsheet that computes the magnitude and direction of the wind from U and V.  We see that the data in the files are indeed what we expected them to be based on grid vs N/S reference.

I have checked with the developers of app1 and app2 who both agreed with observations above, and both have made updates that correct this display issue. So with good data, all apps we know of now show the right display. If any questions remain about your data source, look at the coverage maps above to get a rough estimate of the grid angle at your location, which can then be measured as noted, and kept in mind if discrepancies are noted.

A wind direction error of up to 18º or so is, on its own, not that much of an error when we realize that the model forecasts and the buoy and ASCAT reports we use to check them are only ±10º or so. The bigger factor comes into play with optimum routing computations where a consistent shift of 10º can  make a big difference,  and having it off prevents us from getting the best evaluation of a  model forecast. Thus if you have more than one source of HRRR data you might run the route using both of them to see if there is any difference.

Thanks again to Dave Wilkinson for his sharp eye and prudent navigator's practice to not let something slip by that does not make sense.

And thanks to Craig McPheeters, developer of LuckGrib, for ongoing invaluable discussions of grib files and weather models. His overview of models available at luckgrib.com/models and related blog posts on details remain the standards we refer to.

––––––––––––––––

To check these ideas with another model we look at 3-km NAM CONUS model on the East Coast, just off of Cape Cod, where the grid is tilted the other direction, to the right.  We get the model data from LG and from NM. This model is not so readily available as the HRRR—noting we are not using the more popular 12-km NAM. Using the same abbreviations as above, we have the table below summarizing the results.

The apps A1 and A2 are the same as above. We see the actual forecast was for 211, and we see in app A1, which does not correct for the effect, a display of 193. We are on the East Coast with the grid to the right (see coverage maps above), so the grid based wind direction is too low.  The correction must be added on the East Coast and subtracted on the West Coast.  Then app A2 version we have, which does make a correction, sees a grid wind of 193 and corrects in the wrong direction to display 176.

This seems consistent with what we see in HRRR on the West Coast to confirm this research, but  again I stress that both app A1 and app A2 have fixed this display issue in their latest builds.

If you want to test this, here is a link that will get you HRRR model forecast that you can customize as you like, keeping in mind these are hi res files that get big fast.  The date used has to be present day or yesterday, and the latest run will be about 2hr old. Time and date UTC.

https://nomads.ncep.noaa.gov/cgi-bin/filter_hrrr_2d.pl?file=hrrr.t18z.wrfsfcf03.grib2&lev_10_m_above_ground=on&var_UGRD=on&var_VGRD=on&subregion=&leftlon=-70.6&rightlon=-70.0&toplat=42.0&bottomlat=41.7&dir=%2Fhrrr.20220917%2Fconus.   

This is the 3rd  hr forecast computed on 9/17/2022 at 18z  (valid at 21z 9/17) for the lat lon box shown. Change these inputs as needed and paste into a browser to get the grid referenced HRRR forecast.