Observed
USC0G1, night of 2026-07-24: the post-moon, pre-twilight usable window (~07:40–09:50 UTC) was mostly above the clear-sky ratio threshold, with one short cloud dip at ~08:45 — yet the night produced 0.00 h of flux observing time.
Cause
computeClearSkyTimeIntervals (Utils/Flux.py) applies two different minimum-duration rules:
- An interval terminated by a sub-threshold dip or a data gap is kept only if > 60 min (hardcoded).
- The night's final interval — terminated by simply running out of frames (dawn) — must be >
clearing_threshold = 90 min.
G1's dip split the ~2.1 h window into ~60 min and ~55 min clear chunks. The first sits at the 60-min boundary (and fragments further on threshold-kissing bins); the second is the night's tail, so it faces the 90-min rule and is discarded at 55 min. Both die → 0.00 h on a mostly-clear window.
Questions
- Is there a reason the last interval of the night must be 50% longer than an interior one? Dawn ending an interval carries no information about clouds — the asymmetry looks accidental. The
clearing_threshold docstring describes it as a general minimum, but it is only applied to the final interval.
- Is the 60-min floor itself still the right trade-off? Short windows give noisy flux points, but on moon-shortened summer nights these rules can zero out a whole camera-night of genuinely clear sky (~1.9 h lost here).
A minimal change would be making the trailing rule consistent with the interior rule (90 → 60). Happy to PR that if the asymmetry is indeed unintended — flagging as an issue first since the constants affect fleet-wide flux behavior and may encode a deliberate statistical choice.
🤖 Generated with Claude Code
Observed
USC0G1, night of 2026-07-24: the post-moon, pre-twilight usable window (~07:40–09:50 UTC) was mostly above the clear-sky ratio threshold, with one short cloud dip at ~08:45 — yet the night produced 0.00 h of flux observing time.
Cause
computeClearSkyTimeIntervals(Utils/Flux.py) applies two different minimum-duration rules:clearing_threshold= 90 min.G1's dip split the ~2.1 h window into ~60 min and ~55 min clear chunks. The first sits at the 60-min boundary (and fragments further on threshold-kissing bins); the second is the night's tail, so it faces the 90-min rule and is discarded at 55 min. Both die → 0.00 h on a mostly-clear window.
Questions
clearing_thresholddocstring describes it as a general minimum, but it is only applied to the final interval.A minimal change would be making the trailing rule consistent with the interior rule (90 → 60). Happy to PR that if the asymmetry is indeed unintended — flagging as an issue first since the constants affect fleet-wide flux behavior and may encode a deliberate statistical choice.
🤖 Generated with Claude Code