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

DPDD states DRP DIASource history is included in alerts

    XMLWordPrintable

    Details

    • Team:
      DM Science

      Description

      DPDD Section 3.5.1 states that alerts include "Matching Object IDs from the latest Data Release, if they exist, and 12 months of their DIASource records". This reference to DRP DIASource records is likely an error arising from an earlier plan when the PPDB was periodically refreshed by DRP. This should be deleted. The reference to "matching Object IDs" is also somewhat redundant since these are included in the DIAObject.

       

      Additionally, Section 3.2.1 bullet 8 states that the alert contains the DIAObject ID, but does not specifically say that the DIAObject itself is included. This paragraph could be refreshed for clarity.

        Attachments

          Activity

          Hide
          ctslater Colin Slater added a comment -

          Another issue in the section 3.5.1, the bulleted list says that the alert will contain a "Level 1 database ID", but I don't think such a thing exists. There will be an AlertId, a DiaSourceId, and a DiaObjectId, but nothing that is generically an L1 DB aka PPDB ID.

          Show
          ctslater Colin Slater added a comment - Another issue in the section 3.5.1, the bulleted list says that the alert will contain a "Level 1 database ID", but I don't think such a thing exists. There will be an AlertId, a DiaSourceId, and a DiaObjectId, but nothing that is generically an L1 DB aka PPDB ID.
          Hide
          ctslater Colin Slater added a comment -

          I checked with Mario and Zeljko Ivezic, and we could not remember or find record of a use case that necessitated having this data in the alert packet. Users may want the light curves of neighboring sources as a diagnostic against instrumental effects, but that can be obtained by querying the PPDB.

          Show
          ctslater Colin Slater added a comment - I checked with Mario and Zeljko Ivezic , and we could not remember or find record of a use case that necessitated having this data in the alert packet. Users may want the light curves of neighboring sources as a diagnostic against instrumental effects, but that can be obtained by querying the PPDB.
          Hide
          ebellm Eric Bellm added a comment - - edited

          Per Colin's first comment, I propose to strike the "Level 1 database ID" entirely--the DiaSourceId and DiaObjectIds are included in their records (and hence are in the alert packet), and AlertId appears to me to capture all remaining semantic content.

          Show
          ebellm Eric Bellm added a comment - - edited Per Colin's first comment, I propose to strike the "Level 1 database ID" entirely--the DiaSourceId and DiaObjectIds are included in their records (and hence are in the alert packet), and AlertId appears to me to capture all remaining semantic content.
          Hide
          ebellm Eric Bellm added a comment -

          Leanne Guy, can you take a look at these small DPDD clarifications?

          Show
          ebellm Eric Bellm added a comment - Leanne Guy , can you take a look at these small DPDD clarifications?
          Hide
          ctslater Colin Slater added a comment -

          In reading the diff, I noticed that "DR5L1" was a commented-out example of the "DB ID". So I think I misunderstood what this was referring to; it's an identifier of the database, not the identifier of a record in the database. Regardless, since we're not doing Level 1 database swaps anymore, that field can be eliminated. I also noticed that bullet 9 in the Section 3.2.1 mentions including "the name of the Level 1 database", which can also be removed in this update.

          Show
          ctslater Colin Slater added a comment - In reading the diff, I noticed that "DR5L1" was a commented-out example of the "DB ID". So I think I misunderstood what this was referring to; it's an identifier of the database, not the identifier of a record in the database. Regardless, since we're not doing Level 1 database swaps anymore, that field can be eliminated. I also noticed that bullet 9 in the Section 3.2.1 mentions including "the name of the Level 1 database", which can also be removed in this update.
          Hide
          ebellm Eric Bellm added a comment -

          Colin Slater I removed the mention of the name of the database in Section 3.2.1, and per our in-person discussion I spawned a new ticket (https://jira.lsstcorp.org/browse/DM-18654) to address the timestamp issue.

          Show
          ebellm Eric Bellm added a comment - Colin Slater I removed the mention of the name of the database in Section 3.2.1, and per our in-person discussion I spawned a new ticket ( https://jira.lsstcorp.org/browse/DM-18654 ) to address the timestamp issue.
          Hide
          lguy Leanne Guy added a comment -

          Detailed review in PR

          Show
          lguy Leanne Guy added a comment - Detailed review in PR
          Hide
          ebellm Eric Bellm added a comment -

          Leanne Guy I made the requested changes--can you take a look?

          Show
          ebellm Eric Bellm added a comment - Leanne Guy I made the requested changes--can you take a look?
          Hide
          lguy Leanne Guy added a comment -

          All approved!

          Show
          lguy Leanne Guy added a comment - All approved!

            People

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

              Dates

              Created:
              Updated:
              Resolved:

                Jenkins Builds

                No builds found.