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

Stop using filter alias names in DM stack

    XMLWordPrintable

    Details

    • Story Points:
      2
    • Urgent?:
      No

      Description

      RFC-730 proposes a new filter system that will support only standardized names for each filter, but no aliases. To prepare for the new system, ensure that we are no longer introducing aliases into the codebase (in particular, as the primary name of old-style filters).

      Proposed algorithm:

      1. Go through the filter definition file of every obs package, and make a list of names that appear in either the afw_name or alias field of a FilterDefinition, along with their corresponding physical_filter.
      2. Search the entire lsst and lsst-dm for hardcoded references to these names, except for those in FilterDefinition itself and calls to Filter::define, Filter::defineAlias, and image.utils.defineFilter. Calls to the Filter constructor are covered by the search.
      3. Replace each reference to an afw_name or alias with a reference to the corresponding physical_filter.

      It is possible that step 2 will find no matches.

        Attachments

          Issue Links

            Activity

            Hide
            erykoff Eli Rykoff added a comment -

            I don't know anything about how the current filter singleton system works, is that the FilterDefinition that you mean?

            But there's this craziness:
            https://github.com/lsst/obs_subaru/blob/master/python/lsst/obs/hsc/makeTransmissionCurves.py#L40-L54
            And I have something like this in fgcmcal.

            Show
            erykoff Eli Rykoff added a comment - I don't know anything about how the current filter singleton system works, is that the FilterDefinition that you mean? But there's this craziness: https://github.com/lsst/obs_subaru/blob/master/python/lsst/obs/hsc/makeTransmissionCurves.py#L40-L54 And I have something like this in fgcmcal .
            Hide
            krzys Krzysztof Findeisen added a comment -

            FTR, by FilterDefinition I meant things like https://github.com/lsst/obs_subaru/blob/master/python/lsst/obs/hsc/hscFilters.py. Think of it as a patch to wrap the old singleton in something with a little more order.

            Show
            krzys Krzysztof Findeisen added a comment - FTR, by FilterDefinition I meant things like https://github.com/lsst/obs_subaru/blob/master/python/lsst/obs/hsc/hscFilters.py . Think of it as a patch to wrap the old singleton in something with a little more order.
            Hide
            Parejkoj John Parejko added a comment -

            or the authors of FilterDefinition wouldn't have gone to great lengths to keep those names as primary.

            As the author in question: I added afw_name to deal with the fact that we commonly used names ("r2", "i2" and DECam "SOLID") that were neither abstract nor physical and that turned up regularly in dataIds (and thus got passed into afw). That's the only reason they are "primary", as you call it: because they were so commonly used, but didn't fit in anywhere else.

            Show
            Parejkoj John Parejko added a comment - or the authors of FilterDefinition wouldn't have gone to great lengths to keep those names as primary. As the author in question: I added afw_name to deal with the fact that we commonly used names ("r2", "i2" and DECam "SOLID") that were neither abstract nor physical and that turned up regularly in dataIds (and thus got passed into afw). That's the only reason they are "primary", as you call it: because they were so commonly used, but didn't fit in anywhere else.
            Hide
            krzys Krzysztof Findeisen added a comment - - edited

            Following some clarification from John Parejko on Slack, I'm ready to close this ticket as Won't Fix and add special handling of the three afw_name filters to DM-27169 instead.

            Tim Jenness, I'd still like to hear your thoughts on what we do about filter names in old catalogs (both those included in CoaddInputs, and in general). It looks like this is out of scope for afw, at least; the CoaddInputs class imposes no constraint on the contents or even the schema of its ccds catalog.

            Show
            krzys Krzysztof Findeisen added a comment - - edited Following some clarification from John Parejko on Slack, I'm ready to close this ticket as Won't Fix and add special handling of the three afw_name filters to DM-27169 instead. Tim Jenness , I'd still like to hear your thoughts on what we do about filter names in old catalogs (both those included in CoaddInputs , and in general). It looks like this is out of scope for afw , at least; the CoaddInputs class imposes no constraint on the contents or even the schema of its ccds catalog.
            Hide
            tjenness Tim Jenness added a comment -

            Regarding "SOLID" I'd be fine with calling that band="solid" – do people think that's bad?

            Do we have catalogs that have "r2" in them? It would be nice if we could supply a script that changed the catalog to use either r of HSC-R2. It's really hard to take an arbitrary catalog out of context and understand that r2 refers to an HSC filter. I imagine that in theory ExposureReader could try to fix CoaddInputs itself in backwards compatibility mode if it's fixing Filter in the Exposure.

            Show
            tjenness Tim Jenness added a comment - Regarding "SOLID" I'd be fine with calling that band="solid" – do people think that's bad? Do we have catalogs that have "r2" in them? It would be nice if we could supply a script that changed the catalog to use either r of HSC-R2. It's really hard to take an arbitrary catalog out of context and understand that r2 refers to an HSC filter. I imagine that in theory ExposureReader could try to fix CoaddInputs itself in backwards compatibility mode if it's fixing Filter in the Exposure.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              krzys Krzysztof Findeisen
              Watchers:
              Eli Rykoff, John Parejko, Krzysztof Findeisen, Paul Price, Tim Jenness
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Jenkins

                  No builds found.