# Question about FLUXMAG0 header value in older versions **URL:** \ **Category:** Support\ **Created:** [February 24, 2021, 9:00pm UTC](https://www.rubin.community/t/question-about-fluxmag0-header-value-in-older-versions/4751 "2021-02-24T21:00:10Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![smotherh](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/smotherh/32/850_2.png) [@smotherh](https://www.rubin.community/u/smotherh)\ **Post date:** [February 24, 2021, 9:00pm UTC](https://www.rubin.community/t/question-about-fluxmag0-header-value-in-older-versions/4751/1 "2021-02-24T21:00:10Z")
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](http://www.rubin.community/t/photocalib-has-replaced-calib-welcoming-our-nanojansky-overlords/3648)). 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. ---
**Author:** ![price](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/price/32/488_2.png) [@price](https://www.rubin.community/u/price)\ **Post date:** [February 25, 2021, 12:48am UTC](https://www.rubin.community/t/question-about-fluxmag0-header-value-in-older-versions/4751/2 "2021-02-25T00:48:57Z")
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. ---
**Author:** ![smotherh](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/smotherh/32/850_2.png) [@smotherh](https://www.rubin.community/u/smotherh)\ **Post date:** [February 25, 2021, 3:55pm UTC](https://www.rubin.community/t/question-about-fluxmag0-header-value-in-older-versions/4751/3 "2021-02-25T15:55:30Z")
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. ---
**Author:** ![parejkoj](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/parejkoj/32/138_2.png) [@parejkoj](https://www.rubin.community/u/parejkoj)\ **Post date:** [February 25, 2021, 11:49pm UTC](https://www.rubin.community/t/question-about-fluxmag0-header-value-in-older-versions/4751/4 "2021-02-25T23:49:05Z")
> [@smotherh](#): > > 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? 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. > [@smotherh](#): > > If we were to reprocess with doPhotoCal=True, do you know how to find the names of the LSST stack-recognized bands in refcats? 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](http://www.rubin.community/t/gaia-dr2-reference-catalog-in-lsst-format/3901). ---
**Author:** ![smotherh](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/smotherh/32/850_2.png) [@smotherh](https://www.rubin.community/u/smotherh)\ **Post date:** [February 26, 2021, 12:40am UTC](https://www.rubin.community/t/question-about-fluxmag0-header-value-in-older-versions/4751/5 "2021-02-26T00:40:08Z")
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? ---
**Author:** ![parejkoj](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/parejkoj/32/138_2.png) [@parejkoj](https://www.rubin.community/u/parejkoj)\ **Post date:** [February 26, 2021, 8:52pm UTC](https://www.rubin.community/t/question-about-fluxmag0-header-value-in-older-versions/4751/6 "2021-02-26T20:52:43Z")
> [@smotherh](#): > > Hm. The values for `FLUXMAG0` don’t seem to be equal to 10^(0.4\*28). Sorry, that’s actually the value for a 1-second exposure, so it should be that number multiplied by the exposure time. > [@smotherh](#): > > 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? 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. > [@smotherh](#): > > Is Gaia DR2 available on the UW Epyc system in LSST refcats format? I’d ask on the DIRAC slack about that: I think it is, but I don’t know where. ---
**Author:** ![smotherh](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/smotherh/32/850_2.png) [@smotherh](https://www.rubin.community/u/smotherh)\ **Post date:** [February 26, 2021, 11:03pm UTC](https://www.rubin.community/t/question-about-fluxmag0-header-value-in-older-versions/4751/7 "2021-02-26T23:03:26Z")
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? ---
**Author:** ![parejkoj](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/parejkoj/32/138_2.png) [@parejkoj](https://www.rubin.community/u/parejkoj)\ **Post date:** [February 28, 2021, 6:46am UTC](https://www.rubin.community/t/question-about-fluxmag0-header-value-in-older-versions/4751/8 "2021-02-28T06:46:14Z")
> [@smotherh](#): > > 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? Ah, yes, you finding MAGZERO lead me to it: see `decamMapper:bypass_instcal()`, which sets the PhotoCalib based on that MAGZERO header.