batchmode defaults --interpolate-time to 'nearest', which its own help text says is never competitive — and the jax driver defaults to 'sinc'

[oshaughnessy-junior]

Reporting rather than fixing, per RO'S's standing rule on core defaults. Found while building a cross-implementation likelihood comparison for the RIFT_O4d paper set, where it would have silently invalidated the measurement.

The default is a stencil the option's own help text disqualifies

bin/integrate_likelihood_extrinsic_batchmode:334:

integration_params.add_option("--interpolate-time", default=False, help="... NEAREST is never
  competitive (200-443 nats) and reaches 1 nat of error by SNR 2-6. ... Error grows as SNR^2.
  ... (Default=false, i.e. nearest)")

So the shipped default is nearest, and the same help string says nearest reaches 1 nat of error by SNR 2-6 and grows as SNR^2. There is no amplitude at which a detection is interesting and this default is defensible. The help text is not wrong — it is documenting a default that should not be one.

Nothing is unavailable: the same help says "All three stencils have CPU and GPU implementations." The accurate option exists on every backend and is simply not selected.

The two drivers ship OPPOSITE defaults for the same physical choice

driver	option	default
integrate_likelihood_extrinsic_batchmode	--interpolate-time	nearest (:334)
integrate_likelihood_extrinsic_jax	--interp	sinc (JAX_INTERP_DEFAULT, RIFT/likelihood/jax_ile/core.py:389)

This is the part that does real damage beyond accuracy. Any comparison between the two implementations run at defaults differs in its time discretization, and the difference grows as SNR^2 — so it presents as an amplitude-dependent disagreement between two codes rather than as a flag mismatch. That is the most misleading possible failure for cross-validation work: it looks exactly like a real bug in one of the implementations.

Measured on a 35+30 Msun SEOBNRv4 H1L1V1 zero-noise injection, boxed AV, everything else held: sinc minus nearest is +0.386 +/- 0.046 nats at rho 40.8, an 8.4 sigma effect at the bottom of an amplitude ladder, growing as SNR^2 above it.

Note the jax driver already refuses an internally inconsistent request — bin/integrate_likelihood_extrinsic_jax:1190 errors when --interp and --interpolate-time disagree — so the inconsistency that is caught is the one within a command line, while the one between drivers is shipped as the default.

Why it survives

--interpolate-time is off by default and a command line inherited from an earlier campaign never mentions it, so an analysis silently runs the disqualified stencil and the log gives no reason to look. A prior fix in this area (:480-485) made a typo in the stencil name loud, precisely because an unrecognised value used to fall through to nearest silently. The default itself has the same silence and was not covered.

Suggested direction, not implemented here

1. Make sinc the batchmode default, matching the jax driver. It is result-changing, so it wants the same treatment PR jax: add the 'sinc' stencil and make it the default (result-changing) #193 gave the jax-side default change.
2. Failing that, at minimum make the two drivers agree, in either direction — a cross-implementation comparison at defaults should not be measuring a flag.
3. Either way, worth a startup log line naming the resolved stencil on both drivers, so a configuration audit can read it off the log rather than off the absence of a flag.

Cost is real and should be stated with the proposal: the help gives sinc vs cubic at ~4.2-4.5x on CPU and ~1.6-3.0x on GPU, and we measured nearest -> sinc as ~16x wall on one AV configuration (33.4 s -> 547.2 s at rho 40.8). That is a cost to budget, not a reason to default to a stencil that is wrong by a nat at SNR 6.

Verified against oshaughnessy-junior/research-projects-RIT at ff8134dc.

🤖 Generated with Claude Code

[oshaughnessy-junior]

RO'S has directed that this be scoped for a fix on the O4d line, which changes this from a report into a live proposal:

"I think in O4d we can switch the default stencil from 'nearest' to something more accurate (eg 'bandlimited' or 'sinc'), if we don't incur too much cost — nearest is FAST and usually good enough ... make sure we don't break time export or extrinsic export generally too"

Scoping work is under way and a draft PR into rift_O4d will follow. Three things being pinned down first, recorded here so the issue reflects the actual decision rather than just the defect:

1. cubic is the option nobody has named, and is likely the pragmatic answer — far better than nearest, far cheaper than sinc. Note the choice is not binary: the help records that cubic's accuracy depends on the masses and on fmin while sinc stays flat, and a default has to be safe across the whole parameter space, not just at one configuration. That mass/fmin dependence, not the mean cost, is what decides whether cubic can be a default.

2. Cost is being measured across configurations rather than inferred from the single 16× above. That figure is one AV configuration and may be unrepresentative; RO'S's bar is explicitly "if we don't incur too much cost", which a cost table can answer and an anecdote cannot.

3. The breakage risk is larger than the accuracy or cost question, and it is specific. The help says --interpolate-time "Requires the maintained NoLoop likelihood: this is REFUSED, not ignored, if the configuration cannot honour it." A refusing option that becomes the default turns previously-working configurations into hard failures. So the scope explicitly covers time export (including the continuous-draw path added in Export continuous draws from bandlimited time posterior #217), extrinsic export and the fair-draw paths, the legacy-truthy normalisation, whatever helper_LDG_Events.py already writes onto command lines, and CPU/GPU parity for all three stencils.

Also worth stating plainly, since it bears on the default's direction: nearest being fast and usually good enough is a real argument at low amplitude and is presumably why it is the default. What the measurements above establish is that "usually" stops applying well below any interesting detection, and that the two drivers disagreeing at defaults makes cross-implementation comparison a measurement of the flag. Both can be true, and the fix should be chosen on the cost table rather than on the rhetoric.

If the honest answer turns out to be "keep nearest for configuration X", that will be reported as such rather than forced.