Field Notes · Method
A thousand trips: what a Monte Carlo run knows
A plan is a single path through a set of probabilities, and running it a thousand times shows the shape of the risk instead of one guess at it. Here is how the simulator draws the paths, what its numbers mean and where it is wrong.
Suppose you have five days in Ilulissat in July, one guided boat day booked, and a flight home on the sixth. Fog closes the airport on about one day in six in July; the boat is cancelled by wind on about one day in five. What is the chance you see the glacier front and catch the flight? You can work it out with a pencil for one boat day, and then the plan changes and the pencil is not enough. A Thousand Trips answers by running the plan a thousand times.
What it draws
For each simulated trip, each day draws a weather loss with a probability derived from the month’s rain days divided by the days in the month, scaled by the realm: a rain day in the Amazon costs less than one in the Faroes, and one in the Namib does not exist. Each transfer draws a delay with a probability from the remoteness score. The key activity draws a cancellation with a probability from the realm and from whether the month sits inside the place’s window. The trip then plays out: lost days consume buffer days, and a trip that runs out of buffer before the key activity is a trip that turned back.
What it reports
A histogram of days lost across the thousand runs, which is the shape of the risk, and three numbers: the share of trips that completed the plan, the share that lost a day but still completed, and the share that missed the key activity or the flight. Run it with zero, one and two buffer days and the completion rate climbs and then flattens; the point where it flattens is the buffer that the trip needs.
Where it is wrong
It treats days as independent, and weather is not: a fog in Greenland lasts two days more often than one, and a storm in the Faroes takes the whole weekend. The model therefore undercounts the bad weeks and overstates the completion rate by a few points. The probabilities are our estimates from the normals and the realm, not from operator records. And it does not know about you: a group that turns back at the first delay has a different rate than one that waits.
How to use it
As a comparison, not a forecast. The same plan with one more buffer day; the same place in a different month; two places in the same month. The differences between runs are more reliable than the absolute numbers, and the differences are what decide the plan. The Faroes in June with a buffer day complete the puffins a little over half the time; without one, about one run in five. The Danakil in January with a buffer sees the lava lake in about three runs of four; in May the same plan falls under four in ten, and in reality the tours do not run at all that month, which is exactly the kind of thing a model does not know.
Why we built it
Because every trip report we read described the day that went wrong, and none of them had planned for it. The buffer day is the single most valuable line in a remote itinerary, and it needed a number to argue for it.
Questions people ask
Why a thousand?
Enough runs for a stable histogram, few enough to run in a browser in a fraction of a second. Ten thousand changes the numbers by less than a point.
Is the completion rate accurate?
It is optimistic by a few points, because the model treats days as independent and bad weather clusters. Treat it as a comparison between plans rather than a forecast.
