# Weather Routing Plugin for OpenCPN

### Introduction

The Weather Routing Plugin is designed to compute iteratively positions the boat could possibly make at a certain time. By merging the results of many calculations, it is possible to form a map determining the best route to any given location within the map.

### Quick Start

First, load the grib file used for routing using the grib plugin. Next, open the Weather Routing plugin from the main toolbar and right click the map and Select "Weather Route Position" at the starting location. Repeat this step for the destination. Now, in the Weather Routing window from the Configuration menu (next to File) Select "New". From here you must configure your vessel correctly in the boat dialog. When ready, select "Compute" from the Configuration menu to compute the weather route.

### Background

Integration with the grib plugin allows for knowledge of weather conditions. The climatology plugin can also provide a source of data for longer voyages, but be warned that using the climatology data, especially in variable wind areas is unlikely to give realistic results. Using climatology for currents is more useful and can be used with grib wind data when grib current data is not available.
For example, in the case where data is valid from both sources, grib will always be choosen. If current data is available from climatology, and only wind from grib, then the grib wind is used with the climatology current.

The grib time selected on the timeline at the time the computation is started can be syncronized. From there, the grib timeline data is accessed as the computation proceeds. Once a computation is completed, the course and position of the boat as it sails along the computed route can be viewed during grib playback.

Wind data is required; if no Current or Swell data is available, they are assumed to be zero.

### Configuration Options

- Time Step Time to sail before considering a course or sail change. This is the difference in time between the isochrons on the map. Small time-steps are needed to navigate through narrow channels and give a more accurate result. Generally the route's computed time becomes faster with smaller time steps as it can find a more optimal route with more variation, however it will take longer to calculate (generally four times longer for half the time step).
- Grib Enable using current grib from grib plugin.
- Climatology
  - Disable Do not allow climatology to be used.
  - Currents Only Use climatology for currents, but never wind.
  - Cumulative Map Pretend the wind comes from all of the directions in the wind atlas for the percentage of time based on the atlas. For this mode to work optimally, you should sail at all angles from 0 to 360, and check "optimize tacking" in the vmg tab of the boat dialog. This will allow the program to assume you will tack as needed in intervals shorter than the isochrons to take advantage of wind shifts.
  - Cumulative - Calms Like Cumulative Map, except the boat also drifts without sailing during calms.
  - Most Likely Use the interpolated most likely wind data from the wind atlas, with the most likely wind speed.
  - Average Use wind vector average for wind direction, and wind magnitude average for wind speed. This is the fastest to compute, but not very realistic (it may be close in prevailing conditions).
- Last Valid Wind Data if Deficient Continue to navigate on last valid wind data even if there is no more valid wind data in the area/time. Currents will be assumed to be zero if data is deficient. Cases with deficient data include navigating outside the space or time of the grib file without climatology data, or into an area also not covered by climatology.
- Wind Strength Percentage Multiply wind strength from data source by this percentage to allow computation of possible "what if" scenarios of greater or lesser wind strength.
- Integrator Newton's method is default and fastest, but doesn't take into account changes in wind/current along each step. Rutta Kunge (4th order) is much more accurate taking 4 samples, but a lot slower. Generally Newton's method with a smaller time step is recommended for more accuracy.
- Detect Land Use GSHHS coastline data to avoid sailing through land. This check is quite slow and should be optimized in the future. It is recommended to upgrade to the high resolution background map available here.
- Inverted Regions This is relatively rare, but in some cases it may be possible to reach a location from two different routes (imagine either side of an island) which is further away from the destination before the destination can be reached. At this point, the algorithm must invert and work inwards on this inverted region (rather than outwards) to possibly reach the destination. This case can occur when routing around islands, or occasionally when routing near a high pressure system. Normally this should be disabled, and extra computations are avoided. NOTE: this mode has bugs
- Anchoring In some cases, it may be preferable to anchor (assuming it isn't too deep) rather than continue to navigate if there is a contrary current which is swifter than the boat can travel. This allows the route to reach the destination sooner by sitting in place until the current abades.
- Max Diverted Course Maximum course error to continue toward destination. Not all possible courses will be considered and therefore the most optimal route may not be found. This usually (but not in all cases) is obvious when the optimal route is sometimes near the edge of the graph. Using a reasonable value can greatly speeds the rate of computation.
- Max Course Angle Like Max Diverted Course, except the search range is based from the starting position to the destination. Normally should be set to 180.
- Max Search Angle This specifies how much the boat course can change between propagations. A value of 180 gives the maximum flexibility of boat movement, but increases the computation time. A minimum of 90 is usually needed for tacking, a value of 120 is recommended with strong currents. Smaller values (60 or less) can give very fast results, but should be used with care, as if the other settings are not appropriate, an inaccurate graph will result. For example, if tacking is needed at any time, then in this case, all courses (0-360) must be specified as degree steps and the boat polar optimized for tacking (see below: VMG tab of boat dialog)
- Max True Wind Knots Do not navigate in areas with more true wind than this value.
- Max Apparent Wind Knots Do not navigate in areas with more apparent wind than this value. This should be set to a high value (ie: 100) if not used to avoid extra calculations.
- Max Swell Meters Do not attempt to navigate in areas with more wave average height than this value.
- Max Latitude Do not navigate above (or below in the southern hemisphere) this latitude.
- Max # of Tacks Does not attempt to tack more than this number of times. Currently it tacks as much as it likes initially, then stops tacking at the limit, therefore if a very low number or an even/odd mis-match is given, a very sub-optimal track may be produced. For this reason a value of -1 (unlimited tacks) is recomended
- Tacking Time Penalty for course change from one tack to the other in seconds. This is normally irrelevant for ocean passages, but could be useful for routes in tight quarters Setting to 0 avoids extra calculations.
- Wind VS Current When wind opposes current rough seas can be produced. This constraint takes the dot product of the current and wind vectors, and if the result exceeds this value, navigation in this area is avoided. For example, a value of 60 would avoid 30 knots of wind opposing a 2 knot current as well as 20 knots of wind opposing a 3 knot current. Higher values allow for rougher conditions; the special value 0 (default) allows any conditions.
- Avoid Cyclone Tracks Uses climatology cyclone tracks to avoid routings which cross historic cyclones. The settings in the climatology configuration for windspeed, pressure elnino etc are used, so only visible tracks are considered.
- Courses (relative to true wind) A list of courses to attempt sailing. Excluding certain values can force the route to explicity show tacks/jibes. Another option is to remove all upwind values to find a course which is always running off the wind (even if it is much longer.) Good results typically have a course every 3-5 degrees; more steps takes longer computation time.

### Batch Mode

Once a weather route is successfully computed, it is possible to determine the best time to leave. To do this, many configurations must be generated each with a different start time. Starting by selecting a single configuration with the earliest starting time. From the configuration menu, select batch (ctrl+b) From here, enter the number of days/hours to generate spans. Using decimal values for hours is allowed (ie: 0.5 for half-hour) Once generate is selected, many configurations should appear. Now, "Compute All (ctrl+a)" can be selected from the configurations menu. A total progress bar can be seen under the configurations. Finally a report describing the routes is available from the View menu.

### Boat

The boat dialog displays the polar plot of the boat's speed vs true wind direction as well as showing other details. An xml file specifies the boat parameters and each sail plan. Two file types of polars are supported; CSV (same as qtVlm) and xml parameters which describe how to compute the polar.

#### Plot tab

specifies the parameters for the plot displayed.

- Polar Typical polar diagram showing boat speeds at a given wind speed.
- Speed Plot boat speed across all wind speeds at a given wind angle.

The tracking displays give data based on the mouse position over the plot.

#### Polar Config tab

Configure the polar data to use. Either Compute with various parameters, or specify a CSV file which contains a table of boat speeds for all possible true wind speeds and directions.

#### VMG tab

Shows the best courses for up and down wind on each tack for a given true windspeed. Optimize Tacking makes the polar reflect these tacking options on the relevant courses. If this option is chosen, then the boat will assume the ability to sail in these angles (it is assumed the captain will tack periodically to maintain any course.) If tacking is not optimized, then weather routing will tack only at the isochrons, resulting in overlapping alternate routes, and potentially slightly less optimal course (but will specifically display where to tack.) It also may take significantly longer to compute courses in areas with rugged coastlines.

#### Switch Plan Rules

It is possible to specify several sail plans (eg: spinnaker or normal sails) and then for each plan specify a different polar. You must make rules for when it is appropriate to switch to a different sail plan. The computed plot will display squares whenever a sail change occurs (if selected in the settings)

#### Statistics

Displays miscellaneous statistics about the boat.

### Boat Performance Information

Most users should measure their boat performance (speed at each wind speed and direction relative to true wind) and load a CSV polar file of these records instead of computing them automatically. In the future, the computations could be greatly improved with more parameters to yield more accurate results.

It is also possible to compute boat polar from an augmented sailboat transform calculation. The original sailboat transform:

                                    2
                      /  sin(A/2)  \
       sin(W) sin(A) |  ----------  | = VW eta
                      \ sin(W - A) /

    W is true wind angle
    A is apparent Wind angle
    VW is true wind speed
    eta is a boat specific constant specifying it's sailing efficiency.

Solving for boat speed based on apparent wind we get:

                        __
                  A    /VA
    VB(t) =  sin (-)  /---
    t->inf        2 \/ eta

This computation is very useful for the standard rig, but doesn't really apply correctly in many cases. It also doesn't really factor in a huge range of variables as there is only one constant.

I have augmented the sailboat transform to also take into account two types of drag in the hope that it may come closer to resembling the sailing characteristics of more vessels. This way hull speed is properly taken into account, and for boats with planing ability, you may get the right result if the correct values are used.

The Frictional drag reduces the maximum speed based on the square of its speed. The Wake drag component uses a complex math formula to compute the energy lost creating a wake:

                                           2
               /      sin(Pi - F^-2)      \
       Drag = |  -----------------------   |
               \ (Pi - F^-2) (1 + Pi F^2) /

                  ___
        V = F * \/g l

        F = sqrt(g * l) / V;

        g = 9.8 (gravity constant)
        l is length of vessel in meters
        V is meters per second

        Reaches a peak at F=Pi^-.5 which is about .56

        The huge increase starts at F = .4  (normal hull speed setting)

        Also interesting to note that at 80% of normal hull speed, the wave
        drag is zero as well, but the first hump occurs from .32 to .4, and
        therefore causes more drag than right at .4.

        In theory, this equation is correct for wave drag for all speeds, from displacement to planing mode.

The basic polar describing boat speed at various wind settings fails on many fronts. First of all, various sail combinations become impractical in certain sea states, even if the actual wind speed is the same. The boat also does not sail the same speed in these cases, so the actual boat speed may widely vary with identical wind speed/direction values in different sea states. Secondly, the wind is 3 dimensional, and near land often has a noticable vertical component not accounted for. Thirdly, there may be certain areas conditions, or times when the user may selectively want to use a different polar diagram (sail plan, navigating in fog or near ice, night vs day, autopilot vs wind vane) Fourthly, the actual speed of the boat may change due to various parameters besides currents, wind, and sea state. (more on this below) There are many more reasons as well.

There is also extension for the possibility of other sources of propulsion besides wind power (namely PV-solar electric, and/or human power both which I use for navigation when wind is unavailable) These are normally used in conjunction with sails. This form of power falls into the category of weather routing as it is dependent on solar radiation for photovoltaics, and temperature (sculling a yacht in tropical heat has less range than in cooler weather). It may be possible to consider storing generated electrical power (one possible case would be charging batteries with a hydro tow generator sailing in strong winds, this energy is then to be used the next day when the calm sets in) in an electric drive it is possible to reach the final destination at a sooner time than without this consideration. (all of this is mostly still unimplemented)

It is also possible to factor slow changing, but important changes to the boat's passage-making ability over the course of the voyage. One example is bottom growth, and the rate it might grow given the sailing course and various parameters. This would enable you to gauge how essential it is to actually paint a bottom, or if you don't mind (as I have done many times) to clean your bottom in the middle of the ocean, you could calculate how much time it would save (hopefully more than the time spent scraping the growth off). There is also the case of sails losing shape, and becoming less efficient over the course of a very long passage.

### Todo list:

- Improve boat polar computation
- Optimize ll_gc_ll
- Optimize climatology wind atlas
- implement depth and overhead height from vector charts
- fix runge kutta for grib to use the right timeslices
- Fix issues where routes are not fully normalized
- Fix merdian problem, so we split the world on the opposite of end longitude, and don't propagate past it
- User option for grid reduction resolution?
- Determine best way way to reduce excessive propagations at the edge of graph
- Make segment intersection test smarter and thus avoid deleting points in almost all cases
- Fix inverted region anomallies, analyze child routes, and remove if end is not contained
- Optimize end calculation by using only positions which are parents of non-propagated positions
- Make position removal avoid rebuilding skip list

#### The Weather Routing plugin is written and maintained by Sean D'Epagnier

Please contact me with questions, suggestions and feedback.