I suspect that this comes from modelling the sky in normalised units (not raw counts) so that the sky estimates from different fibres can be combined, but not correctly transforming these normalised units back to per-fibre counts.

I retrieved the normalisation values from the fiberProfiles, and found that the line intensity (bright, isolated line at 843.2491: 6-2 P1(3.5) close doublet) plotted against the normalisation has a large scatter. If the normalisation had been applied to the measured line intensities, this should be a horizontal line. If the normalisation had not been applied, this should be a sloped line. The normalisation comes from the flux in the extracted quartz flat, and it's strange that this should not be tightly correlated with the sky line flux. I wonder if this is related to engineering activities of some sort?

Looking at the images (quartz.jpg and sky.jpg), the fibers appear to have different intensity patterns. Below is a horizontal cut at the position of a sky line for a quartz and sky. The variation seen here seems qualitatively consistent with what's seen in the plots. I conclude that problem is intrinsic to the data.

I don't think any further work is possible without knowing exactly what the differences between the quartz (68345) and sky (68879) are.

I made one commit in drp_stella, to select sky fibers when none are provided.

The sky (68879) is much more like a quartz taken after (69006).

Paul's analysis looks right.

We can merge the all-sky hack, but I think in general that it's better to write a modified `pfsConfig` file to a rerun that defines a set of sky fibres. Because the sky fibre assignment isn't part of the design it doesn't modify the pfsConfigId so the book-keeping all works.

Merged the all-sky hack, as it gives us options for future cases.