John Parejko Thanks for this detail! So I assumed this was the case that jointcal would use the initial WCS (or the coordinates) for the matching, but Lauren MacArthur had said that she's seen jointcal recover valid WCSs from totally wackadoo initial fits, but maybe they weren't so crazy as to be 10 arcseconds off. Or something else is going on.
There are indeed a few of classes of WCS failures that we've seen with DC2 data. One of them is the type of failure that we'd like to be able to recover from (if we were running jointcal!) when the astrometry fitter just misses the mark due to either shallow (u-band) images with few stars; mismatches with the refcat; related issues typically at the edges of the FOV. I expect that these can be improved with knowledge of the camera model, or using full focal plane info in some capacity, etc. (But these are not going to be implemented on the DP0.2 timescale, I imagine). Another class of failure that we don't have in DC2 but happens in real data is that a detector is completely blown out by scattered light, airplanes, Sirius, etc. And these we don't expect jointcal to recover from if there are no sources to match!
In both types of failure, though, our current plan to keep the workflow happy is to have the calibrate task write None for the wcs (and the initial photoCalib as well). And so I think the action item on this ticket is to have jointcal simply check for None for each of these and drop them on the floor. This will prevent jointcal from recovering the first class of recoverable failures, but to recover these would require a working initial wcs anyway which is not the job of jointcal.
I'm happy to take this on (as was the original plan), provided you agree that it can be done entirely at the python layer.