[rongpu]

This PR adds the MW_TRANSMISSION_{G,R,Z,W1,W2} columns back to the v2 zcatalogs, specifically the -imaging.fits file.

The original MW_TRANSMISSION columns from LS DR9 were not kept by in fibermap, so they have to be recomputed using the EBV value.

Some objects (all sky fibers) have zero-filled EBV values, and their MW_TRANSMISSION values are set to zero instead of 1. To select these objects, I also require their grz fluxes to be zero so as to avoid including any real object with EBV=0.

[coveralls]

coverage: 47.064% (-0.006%) from 47.07% — add_mw_trans_cols into main

[sbailey]

How does this compare to using desiutil.dust.mwdust_transmission(ebv, band, ...)?

https://github.com/desihub/desiutil/blob/main/py/desiutil/dust.py#L92

[rongpu]

@sbailey they are identical. I have updated the code to use desiutil function instead.

[sbailey]

IIRC years ago we decided to not propagate the MW_TRANSMISSION values under the argument that 1) they are derivable from EBV and PHOTSYS, and 2) they are model-dependent quantities rather than core observed measurements. For those with desiutil in their environment, it seems easy to use desiutil.dust.mwdust_transmission. For those outside of a desi environment, I could see that re-adding MW_TRANSMISSION columns could be a convenience, at the expense of even larger files. What is the core use-case motivating this PR?

[rongpu]

For the coadd/redrock files which are intended for power users, it makes sense to only keep EBV. But most users (including our DESI collaborators) do not know how to derive MW_TRANSMISSION from EBV. In fact I realized that the MW_TRANSMISSION columns are missing when someone in DESI complained about it on Slack. For something as simple (and necessary) as obtaining extinction-corrected fluxes, I don't think we should force them to install and use desiutil.dust.mwdust_transmission.