On Tuesday I gave my first talk as developer advocate at Tidewell Labs, at the September ops-research meetup. Thank you to everyone who came, and especially to the person who asked about spring tides during the Q&A: you were right, and it is now slide seven.
The talk walks through how Tidewell Berth plans a busy week at a small port, roughly 400 berth assignments once you count shifting and re-berthing, and why we hand the hard part to a constraint solver instead of writing clever heuristics.
The short version
- A port call is an interval. It has a start that may move, a duration we can estimate, and a berth. Everything else is a rule about intervals.
- The tide decides the start. Deep-draft calls can only start inside a tide window. We compute those windows first and hand them to the solver as allowed start ranges.
- No-overlap does most of the work. One berth, one ship, plus a clearance gap for lines and fenders. Pilots and tugs are cumulative resources on top.
- Repair beats re-solve. When an ETA slips we penalise moving calls that were already announced, so the new plan looks like the old one wherever it can.
What did not make the slides
A few people asked how long a full solve takes. For a week at a port with a dozen berths it is usually a few seconds, and repairs are faster. The honest answer is that the model matters more than the machine: most of our speed-ups came from giving the solver tighter tide windows, not from bigger servers.
If you want to go deeper on the tide side, Juno’s post on why our berth planner thinks in tide windows is the companion piece.
Questions, corrections or a port you think would break the model? Write to hello@tidewell-lab.xyz. I read everything.
Mira