The best route

From Ocean Navigator #106
May/June 2000
As night settles on the deck of the boat, a glow emanates from the nav station. It used to be red, to protect the night vision of the deck watch. Increasingly, it’s an irritating bright blue streaming from a computer screen. The light first appeared on racing boats, but that, too, has been changing. Computers are becoming ubiquitous on virtually any boat that has owners, captains, or navigators who want more information and more from that information. No longer are we satisfied with mere positioning information from the nav station. Weather, communication, performance and even routing suggestions are also available to us, leaping off the screen, day and night. But, like all tools, the software programs have their limitations as well as their benefits. Getting the best out of the programs requires that you also understand both the pros and cons of this increasingly capable technology.

While merchant ships and racing sailboats have used weather routing services for years, the technology has only recently been available to voyagers. Routing software allows you to avoid the worst weather while taking maximum advantage of available winds.
   Image Credit: Andy Rogers

Computers have always been good at gathering, collating, and calculating data. Feed in the information, and let the computer spit out the answer. The ultimate navigation question is “How do we get from here to there?” Whether we’re racing or voyaging, the question remains much the same. Routing software endeavors to help us find that answer. It doesn’t give us the answer. To better understand the tool, we need to understand three key elements: the vessel’s performance characteristics, the weather and oceanographic input, and the routing software and its assumptions.

Basically, routing software of all kinds takes a boat’s known performance in a variety of conditions and combines that with a digital weather forecast presented in a particular machine-readable format and gives the navigator the route that will minimize the time to travel from one point to another. Arranged in tabular form, the performance analysis measures true wind speed versus true wind angle and lists the resultant boat speed that can be expected. The table may also indicate the most efficient angle to sail the boat when going to weather or when running downwind. If the graph of the information was plotted for each wind speed, the resulting curve would look a bit like a butterfly’s wing. The distance from the center of the graphor polar curveto the actual line would represent the optimal boat speed one could expect in those given conditions. The more accurate the polar information, the more accurately the routing software will be at choosing an optimal route.

Refining polar data

Most routing programs, such as Deckman for Windows, RayTech (formerly KiwiTech), and MaxSea, have sub-programs to assist in developing accurate polar diagrams. These programs do not automatically update polars; rather, they help in collecting data, displaying it in an understandable way, and giving the navigator the option of manually modifying the vessel’s polar tables. The initial data can be created by mathematicians such as Peter Schwenn, well-known in the racing community for calculating polar values. They can provide a theoretical performance expectation based on vessel length, displacement, sail area, and so forth, but that information should be further refined by actually sailing the boat and recording the data.

For example, before the start of the 1989 Whitbread Round The World Race, I was involved in the polar development for The Carda maxi ketch entered in the race. Using an earlier version of MaxSea for data collection, we learned that the theoretical polars designed for the boat were generally low by one knot to 1.5 knots. Over the course of two days of racing, we could be as much as 72 nm farther down the track than our theoretical polars indicated. We could literally be in a completely different weather pattern, further compounding error in our expected optimal route.

Prior to collecting raw data for polar refinement, it’s extremely important to have accurately calibrated instruments. The raw data that is collected includes position, heading, boat speed, apparent wind angle, apparent wind speed, and so forth. This data provides the basis for calculating other data such as true wind angle, true wind speed, true wind direction, course over the ground (COG), speed over the ground (SOG), set, drift, percentage of performance, and so forth. Without an accurate upwash (air that slides upward as wind blows across the sail) calibration, as an example, there can be as much as a 15% error in the indicated true wind speed when a boat bears off from a beat to a run. There can also be errors of several degrees between tacks, leading to errors in the polar diagram’s true wind angle. Because of the importance of accurate calibration, Deckman and KiwiTech offer steps to help in that calibration process.

When you’ve determined your vessel’s capabilities, the next variable to consider is the expected weather and oceanographic features to be encountered. Deckman, RayTech (KiwiTech), and MaxSea can all accept weather forecasts and current information in GRIB format. The term GRIB merely means graphics in binary. It’s an efficient means of transmitting data point information that can be overlayed and displayed on a variety of charts. Since the information is just the weather overlay rather than an entire chart as a graphics file, the file size is much smaller and more easily and quickly transmitted and received. Since it’s in binary form, computers can churn through the information, and the data can be used for calculations. If you were to open a GRIB file, it would look like some form of hieroglyphics, but to the computer it looks like a series of points with numbers relating to various conditions. True wind speed, true wind direction, barometric pressure, current speed and direction, and other variables can all be transmitted in GRIB format.

Working with GRIB files

With few exceptions, most GRIB files are based on computer-generated models. NOAA has a web site that offers GRIB forecasts, but since the information is for the entire world, it proves to be somewhat unwieldy for most private users. GRIB “choppers” have been developed for weather forecasting services, however, that cut the files down to data for specific geographic areas. Also, GRIB files in a useable size are available for individuals at several sites; among them are Raytheon’s site at: and MaxSea’s site at: The people at MaxSea will even e-mail the forecasts to you or your vessel for a small fee.

The forecasts are for 48 hours out and cover most of the world. Commander’s Weather can provide computer-generated GRIB files out to five days. Additionally, the company has created its own forecasts based upon several models, observations, and subjective know-how and converted them into GRIB format for several special projects in the past, including, for example, for Pyewacket and Magnitude during their successful TransPac campaigns in 1999. Those forecasts went out to seven days, and even on the approach to Hawaii their accuracy proved uncanny.

For other events, Jenifer Clark has produced her Gulf Stream analysis in GRIB format in order to help refine the ocean current data going into RayTech (KiwiTech) routing software.

Computer generated models and GRIB data are not the answers to all prayers, however. In order to be able to best use a tool, it is also equally important to understand its limitations. Some routing programs like KiwiTech and RayTech can animate the forecasts. A series of forecasts are put into the program, such as the 12-hour, 24-hour, and 48-hour surface predictions. These are “snapshots” of what the meteorologists or computer models think will be the conditions at the various valid times. In order to animate the forecasts smoothly, the weather display software interpolates the data and allows for various time steps between the specific forecasts30 minutes, 45 minutes, 60 minutes, or whatever the user requests. The animations are smoother, and it gives the user an idea of what direction things are moving, but, in smoothing the animation, erroneous conclusions can be derived. Weather doesn’t move in such a smooth, interpolated fashion.

As an example, if a weather GRIB file implies that at 1200 Z the wind is going to be 240° at 15 knots at your location, and after the front goes through by 1200 Z the following day, it will be 300° at 15 knots, a smooth interpolated animation will tell you that at 00 Z, between the forecasts the wind is 270° at 15 knots. In reality, the front with the associated wind shift may have gone through much earlier or later, and the wind could have gusted to 35 knots during that frontal passage.

Forecasts not infallible

During the 1999 hurricane season, I tracked the forecast positions of a number of hurricanes as they approached the U.S. East Coast. The GRIB files indicated the wind speeds in these hurricanes at about 40 knotsin some cases more than 100 knots too low. This isn’t meant to say that GRIB files and computer-generated weather models are wrong, as such, but rather that they have their own limitations. They don’t pick up and accurately portray relatively localized events such as actual fronts and tropical storm systems. They work well for the larger-scale gradient wind patterns and over longer-term forecasts that humans may have difficulty in predicting without the aid of computer models. Generally, they’re quite good, but they do not provide an absolutely infallible answer.

Where GRIB files excel are around high pressure systems and near tropical areas. During the recently completed Cape Town to Rio Race, we were able to predict with some accuracy how the weather would evolve on an hourly basis as we raced to Brazil aboard Zephyrus IV. We had a good idea of when to expect a gybe to be necessary and which tack we would be on. In areas of frontal passages, we knew that we could expect to tack or gybe, but the timing was somewhat skewed. GRIB weather files are designed to expedite the transmission of computer-generated weather forecasts. They have been adopted and adapted to provide weather-routing information. But that adaptation makes interpolated assumptions. The assumptions help to make the weather forecasts more understandable to the user and provide a set of information, but some of those same assumptions distort the reality somewhat.

Even with those distortions, however, we gain an added understanding of what we may be able to accomplish when we integrate the GRIB weather forecasts and current data with the vessel’s polars. Our polars provide us with a digital view of what we can accomplish in a given weather situation. GRIB files provide us with a digital view of the weather forecast. And routing software provides us with a means by which we can quickly sort through various possible routes and select the quickest. But these solutions can also have their own set of problems that the user should understand in order to have an insight into what is actually being implied.

In calculating the optimal routes, most routing programs create a set of lines or “isochrones” that ripple out from the point of origin. The isochrones represent a series of points that a vessel can attain in the same time step. In other words, if a boat heads off at any heading between 110° and 200° in an attempt to get to Bermuda from Newport, R.I., given the boat’s performance and the expected weather forecast, it will be somewhere along that line after one hour. It will be somewhere along the next, nearly concentric line after two hours, and along the next line after three hours, and so on. The point along the lines that gets the boat the closest to Bermuda in the least time will represent its greatest average VMC (velocity made good on a course). In other words, the routing software is always searching for ways to minimize the distance between the vessel and its destination.

Outrunning a forecast

What happens if the route is too long for the weather forecast, such as a boat going from Florida to Gibraltar and getting a GRIB weather forecast that covers four or five days? We know that the weather forecast will run out long before the boat gets halfway across the Atlantic. If the only waypoints input in the route are the point of origin and the destination, in most cases the software will provide a reasonable route for the first couple of days. Then, in an attempt to minimize the distance to the finish before the weather forecast runs out, the route offered will head the boat up into the mid-Atlantic high pressure area (the Bermuda high) in order to generate more apparent wind and therefore more boat speed. The solution to the problem would be either to input a longer-range forecast that sufficiently gets the boat past the high pressure system, or to “fool” the software into creating a reliable route by indicating waypoints north or south of the high.

Older routing software didn’t allow for the possibility that forecasts sometimes go wrong. Newer software has been developed that allows the user to modify the various wind barbs. If a user decides to change the weather forecast based upon what he is actually experiencing, care should be taken to make sure that the new weather information that is being input isn’t based solely upon local conditions. Perhaps the wind is too light or too strong and needs to be changed, but it shouldn’t be changed in the routing software if the difference in the weather being experienced is because the boat is currently under a large towering cumulus cloud that is generating a strong local effect.

It is assumed that racing sailors are always racing their boats to their optimal polars. That may or may not be the case. Voyagers, on the other hand, have a unique set of conditions that they can input into their polars to help in accurately optimizing a route. When the wind drops below a particular point, voyagers or boat delivery captains often turn on the engine. Most of the more advanced weather routing software packages will allow for different sets of polar data. If, for example, the wind drops below four knots, and you intend to motor directly to your destination at eight knots, that can be indicated on the polar file. You can create a different set of polars if your threshold for motoring is raised to six knots or eight knots. If low wind speed motoring isn’t accounted for in the polars, the optimal route will be wrong. West Coast navigators have known for a long time that the fastest way to return a boat from Hawaii was to motor northeasterly into the eastern North Pacific High, cross the High north of San Francisco and reach down to southern California. Routing software can imply the same thing, if its polars are set up correctly to reflect the actual way that the boat will be handled.

Different routing software products have a variety of features. Some, like MaxSea, have been around for a decade or more. Unknown to most people, MaxSea works equally well on Windows or Macintosh computers. MaxSea’s ease of use and chart quilting features help people not only with route selection, but also with automatically charting their progress across a variety of charts and chart scales.

Other routing programs, such as Raytech (KiwiTech), pay particular attention to handling large amounts of data and providing a vast array of sophisticated options. The original KiwiTech program was developed for use by some of New Zealand’s America’s Cup competitors. While KiwiTech is still available through some sources, Raytheon has purchased the company and further development is being done under the RayTech banner. Using its vast resources, Raytheon intends to further enhance the user interface, simplify use and provide more extensive customer support.

Working navigators

Deckman for Windows, developed in the U.K. by Graeme Winn, is a rapidly growing, sophisticated routing and performance analysis software. A growing number of professional offshore navigators are using Deckman for Windows to monitor their vessels’ performance and provide tide-and-current sensitive weather routing.

Some navigators, such as Mark Rudiger, the winning navigator aboard E.F. Language in the last Whitbread Round the World Race, use several software products to get the best that each can offer. Rudiger uses KiwiTech for its script chartstime plots of wind speed, angle, performance and up to 240 other variableswhile he uses Deckman for Windows to compare optimal routes to those provided by the KiwiTech software.

Other navigators, such as Dee Smith, winning navigator in the most recent Admiral’s Cup, prefers to learn just one performance analysis software. He likes the way that Deckman for Windows handles tides and currents in European waters and helps him to get to waypoints or approach areas in coastal regions so that he can set up for thermals. Smith understands that the displayed GRIB files represent the gradient wind pattern and may be influenced and changed by local conditions as he’s approaching a coastline. While Deckman’s wind barbs can be scaled to the chart being used, the actual value of those data points may be affected by local conditions.

Whether you use one or more routing software packages, they are certainly worth a look. But it’s important to realize that they are tools to be used with an understanding of their own unique requirements and implications. They can help to confirm your original thinking or call that thinking into question. They are there to help you find the answer, but, like all navigational tools, they, too, should be questioned.

A four-time Whitbread Round the World Race veteran, Bill Biewenga is a writer, professional race navigator, and yacht delivery captain who lives in Newport, R.I.

By Ocean Navigator