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

Duration of AP force photometry after discovery is unspecified

    XMLWordPrintable

    Details

    • Team:
      DM Science
    • Urgent?:
      No

      Description

      The DPDD specifies that during Alert Production, the positions of previously-identified DIAObjects will be force photometered and the results added to DIAForcedSource, similar to how images taken before discovery of a DIAObject are force photometered in precovery. 

      There does not appear to be a document stating how long this photometry must continue. Clearly we don't want to photometer a point of sky for the duration of the survey if it was a false positive that never reappeared. Eric Bellm and I both remember 12 months as the duration after the last appearance of a DIASource that force photometry continues, but can't find any documents supporting this. LSE-81 and the sizing model assumes that force photometry continues for 1 month. The DMSR specifies that the precoveryWindow is 30 days, though no mention is made of this "post" discovery photometry.

       

       

        Attachments

          Issue Links

            Activity

            Hide
            ebellm Eric Bellm added a comment -

            In the interest of making a concrete proposal, I suggest that we forced photometer DIAObjects for 30 days after their last DIASource detection. I think that's long enough that most transients will have faded completely into the noise. So every time a new DIASource detection arrives the counter resets.

            Show
            ebellm Eric Bellm added a comment - In the interest of making a concrete proposal, I suggest that we forced photometer DIAObjects for 30 days after their last DIASource detection. I think that's long enough that most transients will have faded completely into the noise. So every time a new DIASource detection arrives the counter resets.
            Hide
            ctslater Colin Slater added a comment -

            If 30 days is sufficient, then I believe this just requires updating DMS-REQ-0317 with a caveat on which DIAObjects get photometered and a parameter set to 30 days. The sizing model already assumes this duration, and we can't find anything that says 12 months that would require changing.

            Show
            ctslater Colin Slater added a comment - If 30 days is sufficient, then I believe this just requires updating DMS-REQ-0317  with a caveat on which DIAObjects get photometered and a parameter set to 30 days. The sizing model already assumes this duration, and we can't find anything that says 12 months that would require changing.
            Hide
            ctslater Colin Slater added a comment -

            Some of the notes attached to bottom of the DPDD include:

            • SAC: do we need more than 30 days of precovery fluxes for new DIASources? ZI: yes, 30 days is only about two data points in a given band and we don't know colors for transients

            We should double check that we are satisfied with the 30 day precovery window along with deciding on the post-discovery window length.

            Show
            ctslater Colin Slater added a comment - Some of the notes attached to bottom of the DPDD include: SAC: do we need more than 30 days of precovery fluxes for new DIASources? ZI: yes, 30 days is only about two data points in a given band and we don't know colors for transients We should double check that we are satisfied with the 30 day precovery window along with deciding on the post-discovery window length.
            Hide
            ebellm Eric Bellm added a comment - - edited

            My view is that a 30 day precovery window is a decent balance between the technical and scientific concerns.

            Precovery measurements tell us a) if there is flux below threshold and b) when the last non-detection was (flux indistinguishable from noise). Most classes of supernovae and other explosive transients will rise to peak within 30 days, so a 30-day window would be sufficient to capture all the information LSST has if it were discovered at peak brightness. For the tiny minority of sources that exhibit longer initial activity below threshold, users can use the precovery service.

            Zeljko's point about only two data points per band is a limitation of the cadence rather than the precovery window itself. Extending the window further back doesn't help much, either, because the color may be changing on ~week timescales as the transient evolves.

            Show
            ebellm Eric Bellm added a comment - - edited My view is that a 30 day precovery window is a decent balance between the technical and scientific concerns. Precovery measurements tell us a) if there is flux below threshold and b) when the last non-detection was (flux indistinguishable from noise). Most classes of supernovae and other explosive transients will rise to peak within 30 days, so a 30-day window would be sufficient to capture all the information LSST has if it were discovered at peak brightness. For the tiny minority of sources that exhibit longer initial activity below threshold, users can use the precovery service. Zeljko's point about only two data points per band is a limitation of the cadence rather than the precovery window itself. Extending the window further back doesn't help much, either, because the color may be changing on ~week timescales as the transient evolves.
            Hide
            ebellm Eric Bellm added a comment -

            Stephen Smartt provided some useful comments on how long to force photometer sources after their last detection here.

            Show
            ebellm Eric Bellm added a comment - Stephen Smartt provided some useful comments on how long to force photometer sources after their last detection here .

              People

              Assignee:
              ebellm Eric Bellm
              Reporter:
              ctslater Colin Slater
              Watchers:
              Colin Slater, Eric Bellm, Gregory Dubois-Felsmann, Kian-Tat Lim, Leanne Guy
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Due:
                Created:
                Updated:

                  Jenkins

                  No builds found.