Grib Offsets for Routing in qtVlm

When we compute the optimum sailing route in a nav app like qtVlm, we use the polar diagram of the boat to provide its performance expectations in various wind conditions, and we rely on a numerical weather model forecast of the wind, such as the GFS global model for ocean routes and the HRRR regional model for the inland and coastal routes leading to the ocean.

The route always starts from our present position and present time, using the forecasted wind for that time and place. It is indeed always a forecast we are using, because even if we download the forecast when first available it will be based on the most recent synoptic time (00, 06, 12, 18z), which will be some 5 hr in the past when we get it.

It could be, for example that the model's surface analysis, valid at the synoptic time, was very close to the right winds we had then, but now, at the time of the actual route computation, 5 or 6 hours later, the wind could differ from what the model forecasted.

Here is an example. At the start time and place, the forecast for the wind is 8.6 kts from 219, but when we determine the true wind from our own (calibrated) instruments it is 12.5 kts from 248. It would not make sense at all, to compute a route starting with this wrong wind. The result could be significantly wrong, and difficult to correct.

Luckily, most sophisticated routing routines give us the option to account for this wind difference, and here we look at how qtVlm does this.  The function is accessed from the Grib Config page under Corrections (windsock icon in the toolbar).

Here we force the wind to be the right speed and direction observed, and then choose how long you want it to take to linearly blend back into the forecasted value. When doing this underway, there is a button to read the wind instruments values, and to set the start time to now.

In the example below we choose to blend our forced wind back to the grib value in 3 hr. Then we would have to compare again the forecast with the wind instruments. If the wind is steady in the forecast and instruments, we could extend this longer, if not, we reset the wind, and run the route computation (called a routing in qtVlm) again.

_____________

To see how this works, you can load a grib wind forecast, then create a 4 or 5 hour route across the wind, and to simplify the analysis, turn the engine on at a fixed speed of say 6.0 kts.  

Then we can set the route's logbook display to a 60-minute interval. This lets us see what the app thinks the wind is for routing at each hour along the route. Below are sample outputs.  At the end there is a link to a video that shows more specifically how this can be set up for testing. 

In the above, the set up screen is on the right, and top left is the model forecasted wind at each hour with the forced wind turned off.  Next to it is the wind at each hour with the forced start time wind turned on and set to return to the grib in 3 hr.

This is an easy to use tool, and indeed required operation for any routing underway. It is the navigators job to monitor the forecasts with the observations to know when to re-tweak the winds and run the route again.

_____________

Now we need to say (or at least mention) the often unspoken part: for this to work, we need to have accurate (calibrated) instruments. We measure the apparent wind (AW), typically at the masthead, and then we convert that to true wind (TW) at 10 meters (33 ft) above the surface, which is what the forecasts tell us that are comparing to. Some sophisticated wind instruments do all this for us, but with basic  instruments, we count on qtVlm to make the vector conversion from measured AW to derived TW based on the COG and SOG from the GPS.  

The anemometer height correction for the speed is explained in Appendix 9 of our textbook Modern Marine Weather — in a steady wind, the wind speed increases with height above the water, because the surface friction slowing it down decreases as we get farther from the water.

Since the anemometers of boats over 25 ft or so are higher than 10 m above the water level, the wind they read will be higher than the wind at 1o m. For a 70 ft (21 m) mast, the correction would be about +10%; taller masts have larger corrections. 

In other words, with a 10% height correction, a model forecast of 8.6 kts means you should read 1.10 x 8.6 = 9.5 kts TWS for exact agreement. In the example above, we read 12.5 kts, so the actual correction we want is 12.5/9.5 = 1.32, which is an improvement over the 1.46 we used above. 

In other words, when you press the "Wind from instruments" button mentioned above, it reads the wind from the masthead (12.5 kt), but we would want the forecast at 10 m to be 10% less, so we should reduce that to 12.5/1.10 = 11.4, then we are making the right scaling 11.4/8.6 = 1.32.

Which, granted is a small correction. Indeed, the accuracy of the wind forecasts and actual official wind measurements from buoys, stations, and ASCAT is something like ±2 kts, and we should be happy if our own measurements are that accurate, but that does not mean we should throw out or ignore corrections of that magnitude that we know exist. The force of the wind is proportional to the square of the wind speed, so we don't want to lose any accuracy we do not have to. There are enough other uncertainties in the routing process to deal with.

_____________

qtVlm also has an option for simply shifting the wind to desired values and leaving it at those values till it is changed. But this is more for just creating a wind without any grib input for practice with simulated routes and routing. This is illustrated below. 

Here we see the wind throughout the forecast (top right) is increased by 146% and shifted by 29º relative to the underlying grib wind (top left). However, we would get this same wind if we just shut off the grib forecast completely. In other words, this function is not presented as an underway routing aid, it is more a simulation and training aid.

_______________

The treatment of currents in routing is another crucial factor in many cases. When we do a routing computation we load at least two grib files. One for the wind and one for the currents. Global wind models extend out 10 to 16 day, but ocean current forecasts often do not extend out over the full duration of an ocean route (see table below), but routing apps usually have the option to extend the last currents forecast to the end of the route. In qtVlm this is done at menu Config/Gribs and Harmonics/Grib and turn on "Automatically extend Current grib last date."

Generally this is not a problem because most ocean currents do not change rapidly with time. In some cases, it could mean that the ends of longer routes into areas with notable current may not be right on early route computations, but this is often the case, even without currents. We will be running the routing computation multiple times a day, so this takes care of itself.

Current data from Modern Marine Weather.

In some ocean popular races, Newport to Bermuda and Sydney to Hobart come to mind, currents can be a key factor in optimum routing, and navigators usually spend a long time trying to figure what the best data will be. But the current, like the wind, is something we can measure underway, and then correct the  current forecasts accordingly. 

The measurement is similar to measuring wind for wind corrections in that we need well calibrated instruments: in this case a heading sensor, to get course through the water (CTW), and a knotmeter, to get speed through the water (STW). Then, like the wind, we need qtVm to do the vector math to get the current, which is the vector difference between [CTW, STW] from your instruments and [COG, SOG] from the GPS.

This is not an instantaneous measurement. The vector solution will bounce around, but we can get a useful average with time to compare with the forecasts.  We can, for example,  view a plot of the current speed (CS) and direction (CD) in the histogram tab in the route log, and this way find good values to use for the present current. 

Once we know the current we have two options in qtVlm for corrections.

(1) With no current model to work with, we can just force the current to be what we measure and use that for short term routing.  This is also the control we use to just simulate current for practice with current sailings and routing.

(2) If we have a model forecast, we can figure the percent correction in speed and direction, and enter it, but even with a model forecast we have to monitor this. In some areas we have steady currents over large areas and time, but in others we have to deal with meanders and eddies. In some cases the eddies in the middle of the ocean can be just some several hundreds of miles in diameter.  

We might run across vagabond rivers (sides of an eddy) of over a knot in the middle of the ocean, that could be a gold mind or lead ballon, depending on what side we are on.  Knowing this and careful monitoring is key.  You will know from the forecasts is such eddies are likely, but they are not likely to be precisely where forecasted.

An important use of the current offsets comes with the use of the OSCAR current data for ocean routing. See starpath.com/OSCAR.  In many cases we have found that the flow pattern of the OSCAR data are the best guide line for ocean routing, but you may find that the OSCAR speeds are too low by 20 or 30%, because they are an average over 24 hr. So you can download the OSCAR data (it will be for one day alone, 3 days ago) and then extend it as noted above to the end of your wind grib data, and then enhance the speed at the start of the routing by say 125% but leave the direction unchanged. Then once you get some reliable current measurements you can adjust the corrections.

Note this is for ocean routing. In US waters, we would start off with the Operational Forecast System (OFS) tidal currents till we get some distance off shore. They account for local tides, winds, and pressures. 

We have more general notes on currents at starpath.com/currents.

Access Historic OSCAR Currents in GRIB Format

We have long suggested that the satellite based measurements of ocean currents called OSCAR (Ocean Surface Current Analyses Real-time) are often the best guide for optimum sailboat routing. See this video note on the 2025 Sydney-Hobart race.

The present form of the NRT (near real time) data (0.25º resolution; avg depth 15m, 24-hr averages, run daily, but with a 3-day latency) are available since 2020, but the raw data are in NetCDF format, which is not compatible with most navigation applications (electronic charting systems, ECS).

Recently we have outlined how to get archived yacht race routes into various ECS along with how to get the historic winds and waves in GRIB format (reanalyzed ECMWF) for the same time of the race.

Now we want to show how you can also get the historic OSCAR currents for these past races, so when you practice with your own routing to compare with the historic tracks you have all the data needed. 

For direct access to the OSCAR data, you will need to set up a free account at the NASA Earth Data site. This takes just seconds and is totally non-invasive, plus offers other features as well.

Step 1. Get a subsetted copy of the data in NetCFD format from this link:

OSCAR by Lat, Lon, and Date

Step 2. Convert that file to GRIB format with this link:

Convert OSCAR from NetCDF to GRIB

Notes:

(1) If no one has used our conversion service recently, then it will have gone to sleep, and we have to wait about a minute for it to wake up, and then it will complete the task. The next conversion will happen quickly.  This is a fair price we pay for using the free mode of a powerful app server. In the wait we learn about what they offer.

(2) You can also get the most recent OSCAR currents this way, but that is more convenient from LuckGrib or SVSarana, as discussed at starpath.com/currents.  The latest data will always be three days old, regardless of where you get it, but doing as outlined above, you would have to enter a date three days ago.

(3) Here is an 8-min video example.

Let us know if you have any questions about this at helpdesk@starpath.com

(4) OSCAR data locations are moving around in 20226. Here are the latest links we have on data access:  Latest Near Real Time (NRT) data and Historic Final versions back to 1993.