Fix inverted angular velocity correction in the flux effective collection area

[Cybis320]

Summary

The per-block angular-velocity correction in the flux effective collection area is inverted:

ang_vel_correction = ang_vel/ang_vel_mid

Meteors in blocks where they move slower than at the FOV middle are detectable to a deeper limiting magnitude, so those blocks see more of the population and their effective area must be boosted — the same convention as the range correction directly above it, where the disadvantaged (farther) block gets a correction < 1 (c_range = (100/r)², eq. 41 of Vida et al. 2022). Deriving the angular-velocity term under that same convention from the population scaling N(>L) ∝ L^(1−s) gives c_θ = θ₀/θ_block — the reciprocal of both the code and eq. 43 as printed in the paper.

The one-line proof

No external physics is needed to see the inconsistency — it is internal to computeFluxCorrectionsOnBins. About 55 lines above the block loop, the bin-level meteor limiting magnitude treats angular velocity strictly as a detection loss:

d_m_ang_vel_loss = -2.5*np.log10(... * ang_vel_mid ...)
...
# Limit the magnitude only to brightness loss and don't allow increase
if d_m_ang_vel_loss > 0:
    d_m_ang_vel_loss = 0

The clamp explicitly asserts that higher angular velocity can only ever hurt detectability. Yet the per-block weight ang_vel/ang_vel_mid rewarded blocks with higher angular velocity with more effective collection area. The same function penalizes angular velocity in the reference LM and rewarded it in the area weighting; one of the two must be wrong, and the clamp's direction is the physically undisputed one.

Two further pieces of internal evidence in the paper indicate the printed equation (which transcribes the code) is the error:

• The stated reason for excluding blocks within 15° of the radiant is "unphysically large corrections as the apparent meteor angular velocity is zero at the radiant" — the printed form gives a correction of ~0 there, not a large one; only the reciprocal blows up at the radiant.
• "These limits were chosen such that no corrections exceed a factor of 10" — again only meaningful for the reciprocal form.

Provenance: the direction dates to 70c10361 (Jan 2021, first implementation); 22962d91 (Mar 2022, "fixed angular velocity correction") changed only the reference point; the paper documented the code as built.

Measured impact (archived GMN data, US005E)

Rerunning archived nights with only the ratio flipped, the per-bin effective area ratio (corrected/current) tracks the radiant distance from the FOV center:

Bin geometry	A_e corrected/current	Current flux bias
radiant 59–74° from FOV center (CAP, SDA)	×1.29–1.33	overestimated ~30%
radiant ~35° (PER early)	×1.06	≈ neutral
radiant 15–24° (PER late)	×0.48–0.78	underestimated up to ~2×

So beyond the net bias, the inversion makes cameras disagree systematically by up to ~2.5× depending on where each points relative to the radiant — inflating network scatter.

Changes (Utils/Flux.py)

1. Flip the correction to ang_vel_mid/ang_vel, with the factor-of-10 cap described in the paper applied inline (min(max(·, 0.1), 10)), which also guards the θ→0 singularity.
2. Restore the range-correction cap (max(·, 0.1)) that the paper describes but was commented out.
3. Numerator/denominator consistency: meteors with an observed angular velocity below ang_vel_min are now excluded from the count, mirroring the exclusion of slow blocks from the effective collection area (blocks below 20° elevation already have a matching meteor cut; the angular-velocity cut did not). This is a no-op on the tested nights but activates for low-pointing/long-range geometries and slow showers.
4. Radiant exclusion symmetry: the existing near-radiant meteor filter checked only the meteor's end point, so a meteor beginning inside the 15° zone (where blocks contribute zero area) and ending outside was still counted. The filter now checks both endpoints — the same count-vs-area asymmetry class as (3), smaller in effect.
5. The stale "relative to the nightly mean" comment on the correction (left over from the pre-2022 reference point) is replaced by the derivation.

Validation

• A pristine-baseline rerun reproduces the archived server flux tables to ≤0.04% before the fix.
• With the fix, per-bin flux ratios match the deterministic A_e predictions exactly; the caps do not bind on the tested nights (the ang_vel_min block exclusion already limits the boost to θ₀/θ_min).
• Combined with the FWHM convention fix (submitted separately), the two corrections compose multiplicatively, bin-for-bin, to 3 decimal places.

Note for the maintainers

If this derivation is confirmed, eq. 43 of the flux methodology paper (MNRAS 515, 2322) carries the same inversion, which may warrant an erratum. Because this and the FWHM fix shift fluxes in opposite directions for typical far-radiant pointing (partially canceling), they should be evaluated together.

🤖 Generated with Claude Code

https://claude.ai/code/session_01B6s6Z27vWeL1Ume1t9AAfz

[Cybis320]

The FWHM convention fix referenced above is #977. For typical far-radiant pointing the two errors partially cancel, so the flux impact should be evaluated with both PRs together.