desi_healpix_redshifts creation of hpixexp files isn't correctly handling bad petals, leading to unnecessarily scary warning messages that also might hide other real errors.
Worked example
night=20210319 expid=00081059 tile=80873 petal=6 is flagged as bad due to bad positioning on the entire petal, and thus it isn't processed.
preproc/20210319/00081059/tilepix-80873.json still lists which healpix are overlapped by that petal of that tile because it is based upon fiberassign geometry.
But exposures-jura.fits FRAME HDU knows that that petal is missing and doesn't include it, and desispec.pixgroup.get_exp2healpix_map appears to be attempting to use that to know which petals have data (See Lines 90-96).
None-the-less, healpix/sv1/dark/50/5050/hpixexp-sv1-dark-5050.csv still lists 20210319/81059 petal 6 as one of the petals to include, leading to zproc messages like
"fortunately" those are warnings and not fatal errors and it proceeds with the other cframes that it does have, but it generates log clutter that the code appears to have unsuccessfully attempted to avoid in earlier bookkeeping. It also risks hiding other cases where the cframes really should have existed but don't.
Figure out why and fix the bookkeeping so that we don't attempt to use a petal that we already know is bad.
Short Version
desi_healpix_redshiftscreation of hpixexp files isn't correctly handling bad petals, leading to unnecessarily scary warning messages that also might hide other real errors.Worked example
night=20210319 expid=00081059 tile=80873 petal=6 is flagged as bad due to bad positioning on the entire petal, and thus it isn't processed.
preproc/20210319/00081059/tilepix-80873.json still lists which healpix are overlapped by that petal of that tile because it is based upon fiberassign geometry.
But exposures-jura.fits FRAME HDU knows that that petal is missing and doesn't include it, and
desispec.pixgroup.get_exp2healpix_mapappears to be attempting to use that to know which petals have data (See Lines 90-96).None-the-less, healpix/sv1/dark/50/5050/hpixexp-sv1-dark-5050.csv still lists 20210319/81059 petal 6 as one of the petals to include, leading to zproc messages like
"fortunately" those are warnings and not fatal errors and it proceeds with the other cframes that it does have, but it generates log clutter that the code appears to have unsuccessfully attempted to avoid in earlier bookkeeping. It also risks hiding other cases where the cframes really should have existed but don't.
Figure out why and fix the bookkeeping so that we don't attempt to use a petal that we already know is bad.