Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-549

Use nanojansky for calibrated fluxes in DM code and intermediate data products

    Details

    • Type: RFC
    • Status: Implemented
    • Resolution: Done
    • Component/s: DM
    • Labels:
      None

      Description

      Since the acceptance of RFC-356 and RFC-289 (and maybe another I haven't found?) selected maggies as DM's calibrated flux unit, the Project Science Team has landed firmly on janskies (Jy) as the unit for calibrated fluxes in public LSST data products, with a further note that nano-janskies (nJy) put many relevant quantities for LSST in a nice range for humans to reason about and remember.  For more information, see https://pstn-001.lsst.io/.

      I can't think of a good reason for DM's internal calibrated flux unit to be something different, and I can certainly imagine ways in which being different could cause problems (probably minor ones, but then there's the Mars Climate Orbiter...).

      So I hereby propose that all DM code and intermediate data products use nJy for calibrated fluxes, and that we drop usage of maggies entirely.

      This does not mean that we should convert instrumental fluxes in images or catalogs to calibrated fluxes as soon as a calibration is available; on the contrary, we should work in instrumental fluxes and maintain the calibration (the mapping from counts to nJy) in a separate, more lightweight form (i.e. Calib and PhotoCalib) as long as possible.  This avoids frequent re-calibration of images and catalogs as the mapping from instrumental to calibrated fluxes improves over the course of pipeline execution.  We currently continue to use instrumental fluxes even through coaddition and coadd processing, and while I think I'm open to switching to calibrated fluxes earlier, that should be discussed on a different RFC (possibly RFC-545).

        Attachments

          Issue Links

            Activity

            Hide
            erykoff Eli Rykoff added a comment -

            I am not in principle opposed to this. Originally for the maggie vs jansky question I leaned more against the jansky because that carries the implication that we actually know our absolute flux scale (which will get revised, and revised again, and revised yet again over time). However, that battle is past so I think it will reduce confusion to have one fewer unit change along the way.
            Meanwhile, I wholeheartededly endorse the nanoJansky over the Jansky (or the nanoMaggie or picoMaggie vs the maggie for that matter).
            As for the names of the routines, I actually would prefer the instFluxToNanoJansky if that's the standard that we're adopting, because it explicitly makes obvious in the code what units you are getting out. And it's fewer characters.
            If we decide to change our units in the future (oh dear no) then it'll be more obvious in the code where things have to change, rather than fail silently by returning an unexpected unit for "calibratedFlux".

            Show
            erykoff Eli Rykoff added a comment - I am not in principle opposed to this. Originally for the maggie vs jansky question I leaned more against the jansky because that carries the implication that we actually know our absolute flux scale (which will get revised, and revised again, and revised yet again over time). However, that battle is past so I think it will reduce confusion to have one fewer unit change along the way. Meanwhile, I wholeheartededly endorse the nanoJansky over the Jansky (or the nanoMaggie or picoMaggie vs the maggie for that matter). As for the names of the routines, I actually would prefer the instFluxToNanoJansky if that's the standard that we're adopting, because it explicitly makes obvious in the code what units you are getting out. And it's fewer characters. If we decide to change our units in the future (oh dear no) then it'll be more obvious in the code where things have to change, rather than fail silently by returning an unexpected unit for "calibratedFlux".
            Hide
            tjenness Tim Jenness added a comment -

            Jim Bosch what's the status of this RFC?

            (also "nanojansky" not "nanoJansky" since we don't say "kiloMeter" or "nanoVolts"...)

            Show
            tjenness Tim Jenness added a comment - Jim Bosch what's the status of this RFC? (also "nanojansky" not "nanoJansky" since we don't say "kiloMeter" or "nanoVolts"...)
            Hide
            jbosch Jim Bosch added a comment -

            Adopting this.

            I've created one triggering ticket for updating PhotoCalib.  I'd appreciate help pointing out other places in the codebase and (especially) existing tickets for new work (e.g. reference catalogs) that are affected by this RFC.

            On the question of what to name the methods in PhotoCalib, I think Eli Rykoff has made a good rebuttal of my previous argument, and I'm happy to follow his recommendation.

            I would be even happier personally stay out of the debate on capitalization and "ys" vs "ies", given that:

            • our coding standards definitely advocate a capital N for nano, while SI nomenclature definitely does not;
            • the standard nomenclature includes a mix of capitalization for J: the official abbreviation of nanojansky seems to be nJy.
            Show
            jbosch Jim Bosch added a comment - Adopting this. I've created one triggering ticket for updating PhotoCalib.  I'd appreciate help pointing out other places in the codebase and (especially) existing tickets for new work (e.g. reference catalogs) that are affected by this RFC. On the question of what to name the methods in PhotoCalib, I think Eli Rykoff has made a good rebuttal of my previous argument, and I'm happy to follow his recommendation. I would be even happier personally stay out of the debate on capitalization and "ys" vs "ies", given that: our coding standards definitely advocate a capital N for nano, while SI nomenclature definitely does not; the standard nomenclature includes a mix of capitalization for J: the official abbreviation of nanojansky seems to be nJy.
            Hide
            Parejkoj John Parejko added a comment -

            We will need at least one more implementation ticket to update LoadReferenceObjectsTask so that the flux fields it returns are in nanojansky. Simon Krughoff might know how best to implement that, and I had some notes about what parts would be affected in RFC-356.

            Show
            Parejkoj John Parejko added a comment - We will need at least one more implementation ticket to update LoadReferenceObjectsTask so that the flux fields it returns are in nanojansky. Simon Krughoff might know how best to implement that, and I had some notes about what parts would be affected in RFC-356 .
            Hide
            krughoff Simon Krughoff added a comment -

            I'm happy to consult on that implementation, but I haven't looked at that code in some time. Feel free to make an implementation ticket and I'll see what I can do with it.

            Show
            krughoff Simon Krughoff added a comment - I'm happy to consult on that implementation, but I haven't looked at that code in some time. Feel free to make an implementation ticket and I'll see what I can do with it.

              People

              • Assignee:
                jbosch Jim Bosch
                Reporter:
                jbosch Jim Bosch
                Watchers:
                Eli Rykoff, Jim Bosch, John Parejko, John Swinbank, Leanne Guy, Simon Krughoff, Tim Jenness
              • Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Planned End:

                  Summary Panel