Optimize tide-predictor for predicting multiple stations at a time

[joeberkovitz]

It is often valuable to efficiently predict tides and currents for many stations at a time, say, in the 100 to 1000 station range.

For example, a useful class of visual interfaces for understanding tides and currents displays predictions for many stations at once, within some region of interest, at a single time. In this approach, plots against time are not used; instead, predictions for a time of interest are represented graphically over a base map. The prediction time can be changed smoothly by the user, yielding corresponding smooth changes in the graphics. One example of this is the website floatingtrails.com.

The present tide prediction approach in neaps seems to optimize the expense of node corrections for a single station over a period of time. Which is great but when dealing with a large number of stations, it looks like it recomputes the node corrections for each station, even though those corrections will be identical for all stations for any single prediction time.

It's not clear how much of a problem this is yet, but as the corrections computations are already optimized for a single station over a time series (caching node corrections for a given station within a 24-hour interval) I figure it's likely to be a problem in the many-stations use case too:

neaps/packages/tide-predictor/src/harmonics/prediction.ts

Lines 193 to 236 in 57aea20

	const prepareParams = (correctionTime: Date): ConstituentParam[] => {
	const correctionAstro = astro(correctionTime);
	const params: ConstituentParam[] = [];
	for (const constituent of constituents) {
	if (constituent.amplitude === 0) continue;
	const model = constituentModels[constituent.name];
	if (!model) continue;
	const V0 = d2r * model.value(baseAstro);
	const speed = d2r * model.speed;
	const correction = model.correction(correctionAstro, fundamentals);
	params.push({
	A: constituent.amplitude * correction.f,
	w: speed,
	phi: V0 + d2r * correction.u - constituent.phase,
	});
	}
	return params;
	};
	/**
	* Create a function that returns constituent params with node corrections
	* recomputed at CORRECTION_INTERVAL_HOURS. Returns a new array reference
	* when corrections are recomputed, so callers can detect changes via `!==`.
	*/
	const correctedParams = (): ((hour: number) => ConstituentParam[]) => {
	const firstChunkEnd = Math.min(CORRECTION_INTERVAL_HOURS, endHour);
	let params = prepareParams(new Date(startMs + (firstChunkEnd / 2) * 3600000));
	let nextCorrectionAt = CORRECTION_INTERVAL_HOURS;
	return (hour: number): ConstituentParam[] => {
	if (hour >= nextCorrectionAt) {
	const chunkEnd = Math.min(nextCorrectionAt + CORRECTION_INTERVAL_HOURS, endHour);
	params = prepareParams(new Date(startMs + ((nextCorrectionAt + chunkEnd) / 2) * 3600000));
	nextCorrectionAt += CORRECTION_INTERVAL_HOURS;
	}
	return params;
	};
	};

One fix (I'm sure there are others, this is just an example) would be to allow the prediction machinery to use a set of precomputed corrections, passed in via one of the various options interfaces. Then the caller could use some other function to get those corrections. They wouldn't be already combined with a station's base amplitudes or phases for the constituents.

[bkeepers]

I was thinking about this during the refactor in #213, and then made myself stop thinking about it so I could get that optimization done before worring about the next one. 😆

A couple other ideas…

Internal LRU cache

Keep the most recent n corrections per constituent., where n could be a relatively significant timeframe. Each constituent would be 16 bytes/entry (one f + one u), so an LRU(90) would be ~1.4 KB per constituent x 37 common constituents would be ~53 KB total. LRU(365) would be ~216KB.

The corrections could also be switched from daily to weekly with minimal loss, so that would allow caching even more.

Pros: no interface changes, "just works" for common use cases
Cons: never gets garbage collected, no user control

Explicit Cache Option

Similar to your suggestion, just pass an explicit object that is the cache.

import { createCorrectionsCache } from "neaps";

const cache = createCorrectionsCache(n);

[/* list of stations */].map((station) => {
  station.getExtremesPrediction({ start, end, cache })
});

Pros: explicit, constructor could be configurable
Cons: Can't think of any

---

Eithe way, it'd be worth benchmarking the change to see the impact. I'm sure it will be noticeable for large number of stations.

[joeberkovitz]

I'm sure it was smart to punt on this for the first cut :-)

The LRU cache is something that could work. But I think I see in the timeline prediction code that there are currently two levels of caching that can come into play: time-based corrections that are astro-based and only depend on timestamps, and then a second level of station-based caching which bakes these time-based corrections into the station constituents (what prepareParams() does) for efficiency across a station's prediction timeline.

I think the full impact of such a change would allow both...

• time-based astro corrections to be precomputed for timeline of interest and reused across all stations
• station-based parameter corrections based on the above to be reused for each station of interest, across a timeline of interest

I should be clearer about the scenario. I am trying to make the following kind of benchmark as fast as possible:

   for times T in a 24-hour period subdivided by an interval:
      for station S in stations in some arbitrary set of interest:
          predict height or current at S for time T