Optimization engine configuration
The grid resolution controls the cell size of the search graph. Smaller cells produce more accurate routes but take longer to compute. For most ocean voyages, 0.2° (approximately 12 nm) is a good balance.
The variable resolution option uses a two-tier grid: a fine 0.05° grid within 50 nm of the coast (where precise navigation around headlands and islands matters) and a coarser 0.5° grid in the open ocean (where small deviations have minimal impact). This significantly improves coastal routing accuracy without the computational cost of a uniformly fine grid.
Select one or more ADRS areas for CMEMS weather coverage (waves, currents, SST, ice). Wind and visibility use global GFS data and are not affected. Multiple areas can be selected for adjacent coverage.
After adding a new area, use the startup area selector or the weather panel to download data for the new region.
What it does: Instead of maintaining a constant commanded speed for the entire voyage, the calculator tests multiple speeds on each leg (from 50% to 100% of the set speed) and selects the one that minimizes a combined fuel + time score. In heavy weather legs, the vessel slows down significantly — saving fuel because power scales with the cube of speed. In calm legs, the vessel maintains or slightly increases speed.
When to use it: Enable variable speed when you want to see how much fuel could be saved by adapting speed to weather conditions along the route. This is most effective on routes with mixed weather — a few legs with strong headwinds where slowing down saves significant fuel.
How it works: Fuel consumption is roughly proportional to speed³. A 20% speed reduction on a heavy-weather leg saves approximately 50% of fuel for that leg, at the cost of taking 25% longer. The optimizer balances fuel savings against transit time to avoid extreme slow-steaming.
What it is: Pareto analysis explores the trade-off between fuel consumption and transit time. Instead of finding a single "best" route, it generates a set of routes that represent the best possible compromises — no route on the Pareto front is both cheaper and faster than any other.
How to read the chart: Each dot represents one candidate route. The X-axis is fuel consumption, the Y-axis is transit time. The bottom-left corner is the ideal (least fuel, shortest time) but usually unreachable. The Pareto front is the curve of non-dominated solutions — moving along it, you can only reduce fuel by accepting more time, or vice versa. The yellow dot marks the recommended balanced solution.
When to use it: Enable Pareto analysis when you want to understand whether a small increase in fuel consumption would yield a significantly shorter transit time, or whether slowing down by a few hours would save meaningful fuel. It is most useful for routes with strong weather gradients where the trade-off is non-obvious.
When you press Optimize Route, Windmar runs two independent optimization engines at three safety weights each, producing up to six candidate routes:
A fast graph-search algorithm that expands cells from origin to destination, guided by a heuristic that estimates remaining cost. Good for most routes and produces results quickly.
A more sophisticated engine that uses a time-expanded graph where the vessel can choose to reduce speed voluntarily in heavy weather, waiting for conditions to improve. This produces better results in severe weather but is slower to compute.
The optimizer finds alternative geographic paths that avoid adverse weather or exploit favourable currents. It does not optimize the speed profile along the original route — that is a separate capability planned for a future release.
Windmar is designed as a local-first application. All data processing, weather interpolation, and route optimization run on your machine. This means the first launch after a fresh install or container rebuild involves several one-time initialization steps that add latency before the app is fully responsive.
The API server uses Cartopy for land-avoidance checks. On first boot, Cartopy downloads Natural Earth shoreline shapefiles (~30–60 s). Until this completes, route calculation requests will queue. Subsequent boots use the cached files and skip this step entirely.
The weather pipeline fetches global forecast data from NOAA GFS (wind) and Copernicus CMEMS (waves, currents, ice, SST, visibility). A full refresh downloads and processes ~2–5 GB of GRIB2/NetCDF data into the local database. The weather panel shows a “stale” indicator until the first successful refresh completes.
The frontend loads vector tiles from OpenStreetMap on first paint. Tile loading depends on your internet connection and the initial viewport size. Route drawing is available as soon as the map canvas is interactive.
Typical first-boot time: 30–90 seconds before the API is fully responsive, depending on network speed. After the initial boot, restarts take only a few seconds because all downloaded data is persisted in Docker volumes.
If the app feels unresponsive: Check the API container logs (docker logs windmar-api) for download progress. The weather panel's “stale” badge clears once the startup prefetch completes. There is no periodic refresh — after boot, weather data updates on demand when you activate a layer or trigger a manual resync.