Based on a conversation in the #datamodel Slack channel, 2021-10-15,19:

price:

I believe the covariance in PfsArm should be the covariance between fibers (because there isn't much covariance between pixels within a fiber, as we haven't resampled), and that's what I've implemented (it's a product of the simultaneous extraction of all fibers). But I'm not sure what the covariance in PfsObject is supposed to be; since there aren't multiple fibers, I've been expecting that it's the covariance between pixels within a fiber, but maybe that's what covar2 was intended for?

rhl:

I agree that the off-diagonal part of the pfsArm covariances should be very small (I can think of non-zero contributions such as uncorrected brighter-fatter and the effects of non-uniformities in the pixel sizes if we correct for them — but I suspect that both are negligible). However, these data will compress very well.
For the pfsObject file the resampling indeed generates covariances, and those are the terms that most concern me. I suspect that only the +- band (i.e. neighbouring pixels) is significant, but specifying a wider band seemed conservative; again the data will compress well. The COVAR2 are intended to give an idea of the errors coming from the spectrophotometry, where there are uncertainties in e.g. the fibre corrections as a function of wavelength.

Tasks:
1. Make the covariances calculated by the pipeline and stored in the spectral products match the original intent as specified by rhl, above.
2. Ensure this original intent is documented in datamodel.txt.
3. Implement FITS compression for the covariances in the spectral products.
4. Make the width of the covariance band configurable (currently hard-wired to 3 everywhere; we might consider 1 for pfsArm and 5 for pfsObject).
5. We will continue to neglect covar2 for now.