The optimization button on the Route Manager window allows you to optimize legs of the selected routes. When you select one or more routes in the Route Manager window and push "Optimize," for each selected route the following actions occur:
- The chart area covered by wind data from loaded GriBs is subdivided into a 2D grid of points, the optimization grid. The horizontal and vertical distance, in nautical miles, between adjacent grid points is determined by the Grid Size route option.
- Each old route leg listed in the "Optimize Legs" route option is optimized to minimize the travel time between its endpoints. The old leg is replaced by a bunch of new legs as determined by the router. Each new leg consists of a great circle course between grid points in the optimization grid.
The optimizer assumes that you will sail at best VMG along each new leg. This may require tacking or gybing. The optimizer charges zero time for tacks and gybes. This simplifies the calculations, but obviously you won’t be tacking and gybing every minute that you sail along a leg. You should plan to tack or gybe so that you stay within the same grid squares as the leg you are following. This should be around after traveling a distance equal to one half the Grid Size value. So if the Grid Size value is 60 nautical miles, you should tack or gybe every 30 nautical miles in order to achieve the predicted finish time. However, you may require the optimizer to only generate legs on which there is no tacking or gybing, by selecting Simple Legs in the optimization options for the route.
The "optimized route" is only an approximation, because it is restricted to traveling in great circle lines between optimization grid points. As you reduce the grid size, the grid becomes denser and denser, and the route gets closer and closer to the true optimum. But the time required to perform the optimization also increases. The running time is proportional to the number of grid points. Thus a 20x20 grid will take 4 times longer to solve than a 10x10 grid. All known planning programs (Deckman, Expedition, etc.) compute some kind of approximation to the true analytical function. We like our approximation better.
If the endpoint of an old leg is not marked "read only", then the ETA for that endpoint is updated and used as the start time when optimizing the next leg. If it is marked read-only, then the ETA at that endpoint is not updated, and the existing time at that point is used as the start for the next leg. If intermediate legs are skipped, then the old arrival time is used. If no old arrival time is available, optimization is skipped.
So, to compute an optimization for an entire route, make sure the read-only flag is cleared for all points, set the "at time" route option to the start time of the race, set "optimize legs" to "-", and push optimize.
To only optimize the last leg of the route (say the nth leg), set legs to "n-1" and the time for second-to-last route point to your desired start time.
If your route starts at a point in water, whether ocean, lake or pond, then the optimizer will not create a route that crosses land. If it cannot complete the route without crossing land, it will fail with the error “Endpoint unreachable”. This does not necessarily mean that there is no actual way to sail between the start and finish points, but only that the optimizer, which approximates reality, cannot find a way. This can occur with a large Grid Size value and an endpoint inside a tight bay, or when there is a narrow neck of water to pass through, as in the Chicago-Mackinac race, at the Mackinac straits, because all the straight lines between grid points cross land. The way around this is to either make the Grid Size smaller, or to add route points that guide the boat through the constricted areas of the voyage without optimization.
If you choose to start a route at a point on land, then the program will assume that you know what you are doing, ignore land restrictions entirely, and compute the best possible route as if you were sailing some kind of hovercraft.
Optimization is controlled by various parameters that can be changed through the Route Options window. The Legs to be optimized are specified in the same way you specify pages to print in Windows: "1,4,6-10,12" would mean legs 1, 4, 6 through 10, and 12. The single entry "-" means all legs. Legs are counted starting at zero: leg zero is the leg from the first route point to the second route point, and so on.
The parameter “Max Range” determines the maximum length of a new leg in the optimized route. Smaller Max Range makes the computation faster but less accurate. The parameters “Distance Resolution” and “Time Resolution” control the accuracy of the estimated travel times, as discussed in the performance section.
Selecting Wind Data
The optimizer computes the wind at each grid point from the most detailed wind data available at that point in space and time. If the grid point is covered by multiple GriB wind sequences (that are marked "usable for routing"; see Grib Manager) then the “best available” wind data is used. Precisely, the wind sequence that has the maximum grid density and is also valid at the time of departure from the grid point is used.
For example, you might load
a long-range GFS wind GriB, with 14 days’ worth of
forecasts covering the entire 2000 nautical mile route you expect to sail
along, but only defined at grid points 2° (120 nautical miles) apart. You might simultaneously load a SAILFLOW
GriB, defined at grid points every 4 km, but only providing
2 days’ worth of wind forecasts after the race start time, over a 60 nm area around
your starting mark. The wind
calculation will use the SAILFLOW data when possible, in the region of the
start, but fall back to the GFS data at later times further down the course.
Thus you can use the most detailed wind available at the start, and go to the less-refined, longer range values only when you have to.
Any number of wind forecasts can be stacked up in this manner. In practice, however, you’ll probably only want three: a very local SAILFLOW-type forecast, a larger-scale COAMPS forecast, and a hemisphere-scale GFS forecast.
The optimizer will not compute a route that goes outside the latitude and longitude boundaries of the largest wind GriB. But when the arrival time at a route point falls after the valid time ranges for all wind data, then data from the last forecast period of the coarsest wind set is used. Therefore, if you only have wind data for five days, but the optimizer tells you that the minimum travel time is ten days, you should be suspicious. For the last five days of the trip, the optimizer has assumed that the wind is constant at the values given in the last forecast period. Always try to get wind forecast data that covers the entire trip time.
Analyzing the Quality of the Optimized Route
When optimization is completed, several data sets are created in Grib format and added to your set of loaded Gribs. You can work with them via the Grib Manager. These data sets allow you to analyze the quality of the routing solution. You can control which data sets are created through the “route options” window. The data sets are:
- Isochrones: The arrival time for each grid point is determined by the optimization. An isochrone is simply a contour line in this data set. A contour line labeled t is the set of positions that can be reached from the starting point, leaving at the start time, and sailing as fast as possible for t hours.
- Routing Tree: The best route to arrive at each grid point is displayed. This always takes the form of a tree rooted at the starting point.
- Reverse Isochrones: Having fixed an arrival time T at the finish point, the latest time that a grid point can be left while still ensuring that the boat arrives at the finish point at time T is computed. Reverse isochrones are the contour lines of this data set. A line labeled -t is the set of positions that can be left t hours before T. For reverse isochrones, T is set to be the optimal finish time computed by forward computation plus 10%.
- Reverse Routing Tree: Same as the routing tree, except shows minimum time paths inbound to the finish, assuming you arrive 10% later than the fastest time from start to finish.
computed from isochrones and reverse isochrones, and is intended to give you a
rough idea of how far you can sail away from the computed optimal route and
still arrive within 10% of your estimated optimal time. Roughly, if you sail a course anywhere
inside the contour labeled x, then with probability x you should
get to the finish no more than 10% later than the optimal time. (i.e., your ETE will be no more than 1.1 times the computed optimal
The intent of sensitivity analysis is to provide you, the navigator, with some notion of how flexible the optimal route is. If you have other tactical or strategic considerations, such as maintaining a controlling position on competitors, or a different sense of how the weather will develop, then sensitivity analysis gives you an idea how far you can wander from the optimal route and still be pretty close to the optimal time.
Obviously, you cannot sail arbitrarily inside a sensitivity contour -- sailing around in circles for a while is unlikely to be successful. The technical definition: for any grid point within the contour labeled x, if you sail to that grid point optimally, and then sail from that grid point to the finish optimally, it will take you no more than
(1 + .1*(1-x)) times the optimal time. For example, sailing within the .80 contour region should get you to the finish within 2% of the minimum time.
To get isochrones and the forward routing tree, check “Isochrones” in the route options window. To get Reverse Isochrones and the reverse routing tree, check “Rev. Isochrones”. To get Sensitivity, both boxes must be checked.