Question about FLUXMAG0 header value in older versions

Support
#1

We processed a number of VR DECam instcal images a while ago with LSST version 16 or 17. Using other software (KBMOD), we’ve detected around 100 very faint KBOs in these data. We would like to estimate approximate magnitudes of these KBOs. In an individual calexp, these objects tend to have an SNR of 2-3. When we processed these data, we set config_target.calibrate.doPhotoCal=False. In the header, we see a value for FLUXMAG0. I think this processing was done before PhotoCalib took over from Calib (PhotoCalib has replaced Calib: welcoming our nanojansky overlords).

Can we reasonably trust FLUXMAG0, especially with doPhotoCal=False?
Is there a good way to see the version of the stack used to process the data? The repo has been copied over from a compute cluster, so it is difficult to access the data in the conventional way with the butler.

The value for FLUXMAG0 is not the default of 63095734448.0194.

#2

If you ran with doPhotoCal=False, then I wouldn’t trust it at all. Otherwise, it’s a single value for the entire CCD, may not account for color terms, and may be derived from a small number of reference stars. I would recommend validating the values before trusting them.

#3

I was a little surprised to see that there was a value for FLUXMAG0 at all, given that we ran with doPhotoCal=False. My best guess is that it was measured differently from what PhotoCalib does because it was part of Calib? Do you know how it was set?

If we were to reprocess with doPhotoCal=True, do you know how to find the names of the LSST stack-recognized bands in refcats? i.e. In our config we would put something like config_target.calibrate.photoRefObjLoader.filterMap={"VR":"G"}. Is there a list of what LSST allows in place of G? We are using Gaia dr1 and panstaars. DECam VR maps pretty well to gaia G band, which might help avoid problems with not accounting for color terms.

#4

ISR has a fluxMag0T1 config field that is used as a photometric calibration guess, which is probably where your value is coming from. It looks like DECam doesn’t have an override for that, so it should be equal to the default of 10^(0.4*28.0). That pre-calibration value is nominally used in our CModel code, which runs before PhotoCalTask which needs aperture corrections.

The filterMap is just a mapping between the band you are processing and the band name in the reference catalog. I don’t know what your Gaia dr1 catalogs look like, though I would strongly suggest using the newer Gaia DR2 reference catalog in LSST format.

#5

Hm. The values for FLUXMAG0 don’t seem to be equal to 10^(0.4*28). It also appears to vary between images. E.g. it’s 1094460267815.08 in one image and 1062673865402.47 in another. These were processed from INSTCAL images, as well, so maybe the ISR config is different in this case?

Is Gaia DR2 available on the UW Epyc system in LSST refcats format?

#6

Sorry, that’s actually the value for a 1-second exposure, so it should be that number multiplied by the exposure time.

I believe there is no ISR on instcals, since they are post-flat images. There may be a flux calibration coming from the DECam processing? In fact, I’m pretty sure there must be, since we use the instcal WCS too. Check the input instcal files to see what they have?

I believe we’re dropping support for instcals, and I don’t know of anyone with specific expertise in that side of things, so it’ll probably be hard to get anything more.

I’d ask on the DIRAC slack about that: I think it is, but I don’t know where.

#7

In the unprocessed-by-LSST instcal files, I do not see a value for FLUXMAG0, which led to my initial confusion. Upon further inspection, I do see values for MAGZERO and MAGZPT in the instcals. Is it possible that the lsst stack took those values and used them to compute FLUXMAG0?

It seems like the consensus is that I should not trust FLUXMAG0 from LSST when running with doPhotoCal=False, so maybe it is better to just use the DECam community pipeline values as listed by MAGZERO.

EDIT: When I compare the two values, it appears that MAGZERO = 2.5 log10(FLUXMAG0), so I think the stack was setting FLUXMAG0 based on the DECam-reported value for MAGZERO. Mystery tentatively solved?

#8

Ah, yes, you finding MAGZERO lead me to it: see decamMapper:bypass_instcal(), which sets the PhotoCalib based on that MAGZERO header.