Thank you. Actually, this NaN error only happened at visits 21xxxx (year 2013).
It is set up as of a week or two ago 
if there’s a straightforward answer for what should be done to AIRMASS-less DECam headers, please tell me, and I can file a ticket to add a fix to DECam’s relatively new fix_headers method I linked above.
I guess you could put something in the fix_headers method, but it would involve making an airmass calculation that has to get run every time we read those headers, so I think the best approach is doing the calculation once and placing the result in the correction file that @ktl and I mentioned earlier.
Other translators (eg imsim) have a fallback where if they don’t see an airmass header they calculate it from the azel value (which itself could be estimated from the tracking ra dec if necessary).
So if there are cases where airmass can be missing in DECam it would be best to fix the to_boresight_airmass method to handle it.
1 Like
It really depends on how common this is. If there are months of obsevations with airmass missing then it’s better to do it in the to_boresight_airmass method. If it’s a handful then a correction file is better.
So far, we’ve only found ~1-2 weeks. For us, it’s a few hundred (<1000) exposures. But we don’t sample all of the DECam datastream…
Thanks for identifying the problem, @price. I wouldn’t have thought to check the headers.
The fact that we keep having to chase down potential NaN/invalid values when loading data in jointcal (hour angle is another one–with the check added for DECam data!–as are non-finite object shapes–see DM-7101) has made me often wonder why we aren’t catching those things earlier. Something like visitInfo.isValid() or visitInfo.allFieldsValid() that can go into our “raw data quick check pipeline” or whatever, which doesn’t yet exist and is related to the “bad data reject list” that we also don’t have, to keep this stuff from contaminating downstream processing. jointcal should be getting good data, not data with invalid things in it.