Routing Philosophy
This page states the contract every WindMar route is computed and reported under. It governs both search engines and every number shown in the app.
One physics, one reported surface
Every engine prices a candidate leg the same way: the attainable speed through water is solved from the ordered engine setting against the local resistance (calm-water hull resistance + wind + added wave resistance, one calibration), speed over ground follows from the current triangle, and fuel = brake power × SFOC × hours. The search therefore seeks favourable conditions by construction — calmer water and fair current mean more miles per hour and less fuel per mile.
Whatever an engine explores internally, the route you see is re-sailed on one accounting surface (~30 nm rhumb sub-legs, midpoint weather) and reported only from there. Savings figures always name their comparison basis, and honesty flags — partial delivery, truncation, an unmet arrival ceiling, a legality refusal — are structural: they are never traded for a prettier number.
Best ETA (mode A)
Operational case: the ship must arrive as soon as possible within the limits of her speed instruction.
The baseline is your drawn route sailed at the ordered calm-sea speed; weather turns that into an SOG profile, an ETA, and a fuel total. Best ETA searches for a better route at the very same engine speed. At a fixed setting, fuel = power × SFOC × time — so the soonest arrival and the least fuel are the same optimization, with no tension between them.
The baseline ETA is treated as a ceiling (arrive by, never later), not a target: a genuinely better route arrives sooner with less fuel, and both benefits are reported separately. What the system will never do is slow the optimized route down to match the baseline's arrival minute — that would sell your own time gain back to you as fabricated fuel savings. A route that cannot hold the ceiling at the same speed is flagged, never silently slow-steamed into compliance.
JITA — Just-In-Time Arrival (mode B)
Operational case: the vessel must arrive by a deadline — laydays/cancelling, or a terminal slot.
JITA is the reverse problem. Given the deadline, it minimizes fuel by searching the best conditions that allow arriving by it, and determines the constant RPM that meets it, weather impact included. The delivered plan is one constant engine setting plus the route that makes it sufficient.
It exists to kill two seamanship anti-patterns: running fast early to "build margin" (fuel burned for nothing), and losing time in adverse weather then arriving late anyway. The weather-aware solve replaces both with one honest number.
A JITA saving is deadline-anchored: it legitimately includes the cube-law benefit of the (usually lower) solved speed, and it is labelled as such — never presented as a same-speed route saving, which is Best ETA's claim. An infeasible deadline gets a named refusal with the earliest achievable ETA — never a silent overspeed.
Consistency guarantee: set the JITA deadline to the baseline's own ETA and it must find a route very similar to Best ETA's, at a solved RPM slightly below the ordered speed, burning less fuel than Best ETA's same-speed figure — because the better route needs less time, and JITA converts that slack into slower steaming.
Why variable speed (±5 rpm)
Once either mode's constant-speed answer is set, one question remains: can consumption be reduced — or the ETA improved — by modulating speed along the way? The variable-speed pass redistributes RPM within ±5 rpm of the commanded setting: push through ahead of a weather system, ease behind it.
The headline figure holds the constant plan's arrival time (iso-ETA), so its saving is pure conditions exploitation — never a hidden speed change. An improve-ETA alternative is shown as its own labelled option. Because the arrival is pinned, the gain is second-order (measured 0.02–0.4% on benchmark routes): it is a trim on top of a well-chosen route and RPM, not a slow-steaming lever — deadline slack belongs to the JITA solve, not to this test.
Weather beyond the forecast horizon
A long voyage outruns each weather source's horizon at a different hour. What the search sails on past each horizon is a fixed, per-field policy — and a voyage priced partly on constructed weather is always recognisable as such (warnings on the result, provenance and a confidence tier on every sample, and a degraded weather-quality badge).
| Field | Beyond its horizon |
|---|---|
| Wind & waves | Best historical analogue for days 10–20 where a regional analogue library exists (a physically consistent wind+wave pair, blended smoothly into the forecast). Never a seasonal average: added resistance is convex in wave height and wind, so an averaged field would smooth the storms away and systematically under-price the weather — an analogue is a real historical weather evolution, so its day-12 storm is a plausible storm. Where no library covers the region, the field holds the last forecast frame — and the result says so explicitly. |
| Currents | The last frame relaxes to the monthly climatology over a 48 h ramp — a persisted eddy sits at a systematically wrong position, while the climatology is honest about the mean flow. |
| Sea temperature | Persists — thermal inertia of weeks makes the last frame the best estimate. |
| Visibility / fog | Persists for 24 h only (fog has no forecast skill weeks out), then the seasonal fog climatology where the leg is in a covered region and season; otherwise unrestricted. |
| Sea ice | Persists — and missing data fails closed: where the ice field is absent, the search treats it as a wall, never as open water. |
Past-date departures are exempt: historical replay sails ERA5 reanalysis for the whole passage, so nothing is constructed.