I have obtained some deep HSC data for a target that turns out to be partly outside of the footprint of the
ps1_pv3_3pi_20170110 ref_cat (Sgr dwarf), and this is obviously leading to problems in single visit processing and presumably further down the line in e.g. jointcal,etc. I am wondering what (if any) the best option is for dealing with something like this.
astroCal is easily done with gaia_dr2_20200414, but it is the photCal that is the problem. I have an older, shallower catalog that would be plenty good, but that is obviously not in the ref_cat format. Is there any up-to-date info on how to turn your own catalog into a ref_cat?
Alternatively, once I get lsst_stack to spit out a (forcedSrc) catalog, I can calibrate that externally. In that sense, I do not care how bad the photCal is, as long as it homogeneously bad, if that makes sense. If all the images in my stacks can be calibrated to the same bad ref, than lsst_stack can continue and I can fix the calibration externally later. That made me wonder, despite its unusual filters, can we force the usage of gaia_dr2_20200414 for photCal? As long as I can get stacked catalogs out, I can fix any calibration externally, afterwards.
You could try using the ATLAS refcat for an initial photometric calibration, but it won’t be great, and it doesn’t go very deep (r~19). It’s available at NCSA in /datasets/refcats/htm/v1. I don’t know where the similar path at the new USDF is.
You certainly could try to use the gaia phot_g_mean band for very crude photometry, but you might be better off trying the phot_bp_mean_flux and phot_rp_mean_fluxfields instead. Use bp for u and g bands, and rp for redder bands: turn off anyFilterMapsToThis and create a filterMap for PhotoCalTask. They’ll be noisier than phot_g and may have no information for some sources; I’m not aware of any use or testing of them, so no guarantees it’ll work at all.