Contamination from satellite(?)

[rongpu]

There are few peculiar spectra in exposure 332110 (a dark-time exposure taken immediately after dusk) that are likely caused by a satellite. See two such spectra below (shown are the cframe spectra; yellow = problematic spectrum, blue = repeat observation in a different exposure).

I found 3 more similar spectra. All 5 (fibers 1055, 1176, 1703, 2806, 3112) are from fibers that are along a straight line on the focal plane, thus my guess of satellite crossing:

I checked @araichoor's spacewatch movie (link below), but I don't see any visible satellite track during the exposure.
https://data.desi.lbl.gov/desi/survey/ops/main-status/spacewatch/spacewatch-20251216.mp4

@araichoor has been tracking possible satellite crossings in this issue but focuses on bright satellites that are visible in the spacewatch images. My guess is that most of the satellite crossings are cases like this –– fainter and not visible in spacewatch but bright enough to wreck the spectra of fainter sources. And the only way to identify them is to compare with repeat observations. It will be a bigger issue in DESI-2 where we will have more repeat observations and fainter sources, and a single satellite crossing can contaminate the coadded spectra.

[sbailey]

Interesting :( I suggest that we use the new $DESI_SPECTRO_CALIB/ccd/flagged_fibers.ecsv to mark these as bad.

@rongpu @akremin please coordinate to add something like this:

20251216 332110 1055,1176,1703,2806,3112 BADFIBER "Likely satellite contamination"

Detail: because this is a space-separated ECSV file, we can flag all 5 fibers in a single line with a comma-separated group as long as they don't have spaces. If that seems too fragile, we could have 5 entries instead (one per fiber).

@akremin is looks like /global/cfs/cdirs/desi/spectro/desi_spectro_calib/trunk/ccd/flagged_fibers.ecsv does not have a COMMENTS column. Let's add that as part of this update.

[akremin]

I can add this @rongpu and also add the comments column Stephen requested.

[araichoor]

for what is worth, in the thread you mentioned, @rongpu, I did try few ways to identify the satellite tracks from the spectra themselves, without relying on spacewatch.
e.g. look at bright sky fibers, or compare the r-band flux of the spectro. to the ls-dr9 one (desihub/desisurveyops#75 (comment)).
don t know if such approaches would be relevant for the cases like this one, but I mention just in case.

[akremin]

I have added the line Stephen proposed above to the flagged_fibers.ecsv file and committed it to SVN, with a new COMMENTS column.

[akremin]

Does getting rid of the fibers on one exposure close this ticket, @rongpu, or was the ticket meant to take a broader look at satellites in the data?

[rongpu]

My original intention for this ticket is to document the issue and hopefully motivate a permanent fix (that automatically identifies and flags such cases). So I would prefer keeping this ticket open until we have such a fix.

@araichoor I missed that you had already looked into ways of identifying satellite crossings without relying on spacewatch. Using external photometric catalogs could be an option (especially downstream of the pipeline, e.g., at the LSS catalog level), but adding a dependence on external catalogs may be a significant downside/limitation of implementing such a fix within the spectroscopic pipeline.

[akremin]

Okay, keeping this open but removing it from the Matterhorn dashboard since a solution is unlikely to converge on that timescale, and we've mitigated this known issue with flagged_fibers.ecsv.

[deisenstein]

Long-term, my worry is that some satellites may be faint enough that we can't notice them easily in the spectra, i.e., just from their integrated light. I suspect that in 10 years every major telescope will have a secondary camera on their top rings, because that's the only way to be sure. I guess the spectra of the satellite reflections will tend to have a lot of solar z=0 features. But that may not be too helpful, e.g., degenerate with imperfect sky subtraction of moonlight. Daniel

…

On Wed, Jan 28, 2026 at 1:04 AM akremin ***@***.***> wrote: *akremin* left a comment (desihub/desispec#2599) <#2599 (comment)> Okay, keeping this open but removing it from the Matterhorn dashboard since a solution is unlikely to converge on that timescale, and we've mitigated this known issue with flagged_fibers.ecsv. — Reply to this email directly, view it on GitHub <#2599 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPQRGQ7TMDLPVH2WWM4SID4I74HTAVCNFSM6AAAAACSY357LGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQMBYGE4TIMZXHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>