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.