Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-16903

Deprecate/remove abMagFromFlux/fluxFromABMag in Calib

    Details

    • Type: Story
    • Status: Won't Fix
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: afw
    • Labels:
      None

      Description

      Calib.h has a handful of free functions for converting between physical flux and magnitude (abMagFromFlux, fluxFromABMag) and their errors (abMagErrFromFluxErr and fluxErrFromABMagErr). The former two are used 10 times total outside of Calib and its tests, the latter two are used 8 times (error uses are in PhotoCalTask and fgcmcal). The flux/mag conversions can be trivially replaced by astropy (e.g. (flux*units.Jy).to_value(units.ABmag)), but it's less clear what to do with the error calculations. Unfortunately astropy doesn't support that error propagation directly (though I'm sure they'd be happy to take a PR from us) to do so.

      lsst.afw.image doesn't seem like the right place for them to live. Possibly lsst.utils? They'll get more useful names (e.g. nanojanskyErrToABMagErr, abMagErrToNanojanskyErr?) too.

      Replacing the flux/mag functions with astropy.units blocks DM-10156.

        Attachments

          Issue Links

            Activity

            Hide
            erykoff Eli Rykoff added a comment -

            I'm not sure why these can't live in lsst.afw.image, because that's where PhotoCalib lives, and these routines are clearly related to that. Certainly it's where I would think to look for these sorts of routines.
            And (at the risk of repeating myself) I think that if we need/have convenience functions for the errors, we would want convenience functions for the transformations as well, even if they are trivial wrappers around astropy.units.

            Show
            erykoff Eli Rykoff added a comment - I'm not sure why these can't live in  lsst.afw.image , because that's where PhotoCalib lives, and these routines are clearly related to that. Certainly it's where I would think to look for these sorts of routines. And (at the risk of repeating myself) I think that if we need/have convenience functions for the errors, we would want convenience functions for the transformations as well, even if they are trivial wrappers around astropy.units .
            Hide
            Parejkoj John Parejko added a comment -

            After asking around, astropy does have an uncertainty framework which might be able to handle the other case, too: http://docs.astropy.org/en/stable/uncertainty/index.html

            Show
            Parejkoj John Parejko added a comment - After asking around, astropy does have an uncertainty framework which might be able to handle the other case, too: http://docs.astropy.org/en/stable/uncertainty/index.html
            Hide
            erykoff Eli Rykoff added a comment - - edited

            Looks like it's only in astropy 3.1 (the stack is on 3.0.3), and is "experimental". It also looks like it wants to do full distributions and estimate uncertainty which is overkill and less stable than when we have analytical unit changes (as in this case):

            "Astropy provides a Distribution object to represent statistical distributions in a form that acts as a drop-in replacement for Quantity or a regular numpy.ndarray. Used in this manner, Distribution provides uncertainty propagation at the cost of additional computation. It can also more generally represent sampled distributions for e.g., Monte Carlo calculation techniques."

            Show
            erykoff Eli Rykoff added a comment - - edited Looks like it's only in astropy 3.1 (the stack is on 3.0.3), and is "experimental". It also looks like it wants to do full distributions and estimate uncertainty which is overkill and less stable than when we have analytical unit changes (as in this case): "Astropy provides a Distribution object to represent statistical distributions in a form that acts as a drop-in replacement for Quantity or a regular numpy.ndarray. Used in this manner, Distribution provides uncertainty propagation at the cost of additional computation. It can also more generally represent sampled distributions for e.g., Monte Carlo calculation techniques."
            Hide
            swinbank John Swinbank added a comment -

            Replacing the flux/mag functions with astropy.units blocks DM-10156.

            Clearly, it didn't.

            While removing the vestigial Calib functions would be nice, it's hard to justify it as something worth spending time on. Closing this as Won't Fix until we have a real requirement for it.

            Show
            swinbank John Swinbank added a comment - Replacing the flux/mag functions with astropy.units blocks DM-10156 . Clearly, it didn't. While removing the vestigial Calib functions would be nice, it's hard to justify it as something worth spending time on. Closing this as Won't Fix until we have a real requirement for it.
            Hide
            swinbank John Swinbank added a comment -

            Replacing the flux/mag functions with astropy.units blocks DM-10156.

            Clearly, it didn't.

            Show
            swinbank John Swinbank added a comment - Replacing the flux/mag functions with astropy.units blocks DM-10156 . Clearly, it didn't.

              People

              • Assignee:
                Unassigned
                Reporter:
                Parejkoj John Parejko
                Watchers:
                Eli Rykoff, Jim Bosch, John Parejko, John Swinbank, Tim Jenness
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Summary Panel