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

Investigate excess DIASource detections due to diffim background modeling

    Details

    • Story Points:
      6
    • Epic Link:
    • Sprint:
      AP S19-6, AP F19-1, AP F19-2
    • Team:
      Alert Production

      Description

      Viewing smoothed diffims from https://jira.lsstcorp.org/browse/DM-17281 reveals background gradients near the corners of some chips which are not present in the calexps or the templates.  These areas show an excess of DIASource detections.

      This ticket is to investigate this failure and potentially identify changes in configurations that provide better performance.

        Attachments

          Issue Links

            Activity

            Hide
            mrawls Meredith Rawls added a comment -

            After thorough investigation, we concluded that most of the spurious DIASources originate from a single night (visit). A handful are from a 1-2 nights within a few days of the most problematic night, when there was extremely high sky brightness. The HiTS survey was during dark time so we can't blame the moon.

            We tried a few different things to alleviate the problem:

            • Is the background being overfit, and would the problem still appear with a constant background level? (no substantive difference when this was tried)
            • Is the problem due to proximity to bright sources, and do we just need to do a better job of masking them? (no, it is a function of time - visit - and location on the CCD and is independent of where other sources are, as it appears happens on the same CCD in multiple fields)
            • Can we fix the problem by adding illumination correction to the ISR steps? (see DM-19874) ... tl;dr it changes things but doesn't fix them

            I suspect we should just throw out the most problematic visit, but we need a way to quantitatively determine a "bad visit for difference imaging" a priori, and we need to ensure this problem isn't somehow caused only in the presence of decam-community-pipeline-enabled ISR.

            Would you review this Yusra AlSayyad? It is directly relevant to the work we'll be diving into next week, and looking at the notebook should give you a feeling for the kind of analysis I have been doing and one type of false positive we are encountering.

            There is essentially no code review (save a small bug fix for a custom plotting script). In the end we haven't fully solved the problem, but we have characterized it somewhat.

            Show
            mrawls Meredith Rawls added a comment - After thorough investigation, we concluded that most of the spurious DIASources originate from a single night (visit). A handful are from a 1-2 nights within a few days of the most problematic night, when there was extremely high sky brightness. The HiTS survey was during dark time so we can't blame the moon. We tried a few different things to alleviate the problem: Is the background being overfit, and would the problem still appear with a constant background level? (no substantive difference when this was tried) Is the problem due to proximity to bright sources, and do we just need to do a better job of masking them? (no, it is a function of time - visit - and location on the CCD and is independent of where other sources are, as it appears happens on the same CCD in multiple fields) Can we fix the problem by adding illumination correction to the ISR steps? (see DM-19874 ) ... tl;dr it changes things but doesn't fix them I suspect we should just throw out the most problematic visit, but we need a way to quantitatively determine a "bad visit for difference imaging" a priori, and we need to ensure this problem isn't somehow caused only in the presence of decam-community-pipeline-enabled ISR. Would you review this Yusra AlSayyad ? It is directly relevant to the work we'll be diving into next week, and looking at the notebook should give you a feeling for the kind of analysis I have been doing and one type of false positive we are encountering. There is essentially no code review (save a small bug fix for a custom plotting script). In the end we haven't fully solved the problem, but we have characterized it somewhat.
            Hide
            mrawls Meredith Rawls added a comment -

            Are you still open to reviewing this, Yusra AlSayyad?

            With a bit of False Positive Sprint hindsight and DM-20555 now essentially done, I can safely say that most of the spurious background sources this ticket was originally created to investigate go away with doAddCalexpBackground=False. The rest are caught by the Shape flag.

            Show
            mrawls Meredith Rawls added a comment - Are you still open to reviewing this, Yusra AlSayyad ? With a bit of False Positive Sprint hindsight and DM-20555 now essentially done, I can safely say that most of the spurious background sources this ticket was originally created to investigate go away with doAddCalexpBackground=False . The rest are caught by the Shape flag.
            Hide
            mrawls Meredith Rawls added a comment -

            Ian Sullivan, would you give this a quick look, please, per our discussion?

            I updated the notebook to show how work since this investigation ticket has made the background modeling problems go away. I also bundled a couple small plotLightcurve.py script tweaks into the PR.

            Show
            mrawls Meredith Rawls added a comment - Ian Sullivan , would you give this a quick look, please, per our discussion? I updated the notebook to show how work since this investigation ticket has made the background modeling problems go away. I also bundled a couple small plotLightcurve.py script tweaks into the PR.
            Hide
            sullivan Ian Sullivan added a comment -

            Thanks for adding the summary of your more recent work at the end, that wraps it up nicely.

             

            Show
            sullivan Ian Sullivan added a comment - Thanks for adding the summary of your more recent work at the end, that wraps it up nicely.  

              People

              • Assignee:
                mrawls Meredith Rawls
                Reporter:
                ebellm Eric Bellm
                Reviewers:
                Ian Sullivan
                Watchers:
                Eric Bellm, Ian Sullivan, John Swinbank, Meredith Rawls, Yusra AlSayyad
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Summary Panel