Optimization
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 readonly, 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 readonly 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 "n1" and the time for secondtolast
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 ChicagoMackinac 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 Parameters
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,610,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 longrange 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 lessrefined, 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 SAILFLOWtype forecast, a largerscale COAMPS
forecast, and a hemispherescale 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.

Sensitivity:
This is
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
ETE).
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*(1x)) 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.