Step 1: Refactor LSR - DMSR direct links

Work in this section was done under  DM-25817 - Getting issue details... STATUS .

Clean up places in the DMSR where there is explicit reference to the LSR (inappropriately skipping a level), determining in each case whether the flowdown:

  • was conceptually correct;
  • can be replaced by a reference to an existing OSS requirement; or
  • needs a new OSS-level requirement.

Enumeration of existing cases

Based on release 8.14 of the DMSR from  (Docushare v40):

DMS-REQ-0004, Nightly Data Accessible Within Specified Time

LSR-REQ-0101 is used as a reference in the explanatory text for the OTR1 parameter in the parameter table for this requirement.  Such references should not skip levels.

DMS-REQ-0338, Targeted Coadds

Specification: It shall be possible to retain small sections of all generated coadds.

Discussion: This supports quality assessment and targeted science.

The flowdown is documented as from:

  • OSS-REQ-0136: Co-added Exposures; and
  • LSR-REQ-0040: Data Quality Monitoring.

Does this mean that there is inadequate coverage in the OSS of data quality monitoring?

The text of this requirement seems too obscure to be verifiable.  Does it mean "retain, for coadds that would otherwise not be persisted as part of the data release", or does it mean "retain online from past data releases"?

DMS-REQ-0339, Tracking Characterization Changes Between Data Releases

Specification: Small, overlapping, samples of data from older releases shall be kept loaded in the database.

Discussion: This enables a comparison of how current data releases relate to previous data releases and to improve data quality monitoring.

The flowdown is documented as from only:

  • LSR-REQ-0040: Data Quality Monitoring

This seems like it might be the catalog equivalent of DMS-REQ-0338, but it's stated a bit more clearly.

DMS-REQ-0392, Alert Delay and Failure Tolerances

As for DMS-REQ-0004 above, LSR-REQ-0101 is used as a reference in the explanatory text for the OTR1 parameter in the parameter table for this requirement.  Such references should not skip levels.

DMS-REQ-0393, Performance Requirements for Transient Alert Distribution

Specification: The system shall be able to identify and distribute an average of at least nAlertVisitAvg alerts per standard visit during a given night, and at least nAlertVisitPeak for a single standard visit.

Specification: Performance shall degrade gracefully beyond nAlertVisitAvg.

The flowdown is documented as from:

  • LSR-REQ-0101: Data Processing for Single Visits and Transients
  • OSS-REQ-0193: Alerts per Visit

Analysis: LSR-REQ-0101 is in the "duplicates quantitative SRD specs" section of the LSR, Section 1 "Survey Design Specifications".  It copies down the value of transN from the SRD.  This value is directly 

DMS-REQ-0342, Alert Filtering Service

Specification: A basic, limited capacity, alert filtering service shall be provided that can be given user defined filters to reduce the alert stream to manageable levels.

The flowdown is documented as from only:

  • LSR-REQ-0025: Transient Filtering

Analysis: due to an editing error in March 2011, the contents of LSR-REQ-0025 were inadvertently overwritten with updated contents intended for LSR-REQ-0028.  Despite its title, which was not changed, LSR-REQ-0025 is currently about alert production reliability.

No OSS requirement is currently available to support this flowdown either.

The editing error in the LSR, despite its very long standing, should be fixed and the missing requirement restored.  A direct copy should be added to the OSS.

DMS-REQ-0348, Pre-defined alert filters

Specification: Users of the LSST Alert Filtering Service shall be able to use a predefined set of simple filters.

Discussion: See LSR-REQ-0026

The flowdown is documented as from only:

  • LSR-REQ-0026: Predefined Transient Filters

Analysis: no OSS requirement is available to support this flowdown.  This was captured long ago as LIT-275 - Getting issue details... STATUS .  LSR-REQ-0026 should be copied down to the OSS in order to fix this.  The Discussion should be copied down from above to the DMSR rather than relying on the indirection, so that the DMSR is more useful stand-alone.  System documentation should be clarified to ensure that the design reflects a) the ability to have pre-defined filters at all, and b) a task for actually defining an initial set (see existing ticket DM-9753 - Getting issue details... STATUS ).

DMS-REQ-0336, Regenerating Data Products from Previous Data Releases

Specification: The DMS shall be able to regenerate data products from previous data releases to within scientifically reasonable tolerances.

Discussion: This is similar to DMS-REQ-0311, but covering prior data releases. The intent is for the software to be runnable in the same environment as was used for the original data release without the software having to be ported to a modern operating system.

The flowdown is documented as from only:

  • LSR-REQ-0049: Data Product Archiving

Analysis: This LSR requirement is not really on point, IMHO.  The point of the DMSR requirement is to require the provision of provenance and recoverable software versions/images and the ability to run them for older data releases.  The relevant part of the point of the LSR requirement is to allow for non-persisted data products even in the current data release.  This flowdown needs to be re-validated in both directions.

A new, unambiguous OSS requirement appears to be needed.

Relevant LSR texts

Based on release 7.1 of the LSR (LSE-29) of  (Docushare v44)

I include "Discussion" text only in some cases.

LSR-REQ-0025: Transient Filtering

Requirement: Given an alert-detection algorithm chosen to meet LSR-REQ-0027, the algorithm shall be applied and the alert transmitted within the specified latency for at least a fraction OTR1 of instances where the image data contains a transient detectable by the algorithm. The remaining transients so detectable must still be identified and recorded at the next processing opportunity.

This requirement defines the parameter OTR1.

Analysis: This requirement is obviously incorrectly titled.  This turns out to be due to an editing error in 2011 which overwrote LSR-REQ-0025 (which had stated "Users shall have the option to request query-like pre-filtering of the transient alert data stream.") with a proposed change to LSR-REQ-0028, "Alert Production Reliability".  In 2013 LCR-144, among other changes, removed the "duplication" between -0025 and -0028.

LSR-REQ-0026: Predefined Transient Filters

Requirement: Pre-defined filters optimized for traditionally popular transients shall be made available. It shall be possible for the project to add new pre-defined filters as the survey progresses.

Discussion: The list of pre-defined filters, by way of example, should include ones for supernovae and microlensed sources.

LSR-REQ-0040: Data Quality Monitoring

Requirement: Level 2 Data Product production shall include the production and publication of sufficient SDQA data to allow the determination of the scientific usability of the data products and the assessment of the large-scale progress of the survey.

Note that a similar requirement, LSR-REQ-0035, applies to Level 1 Data Product generation.

LSR-REQ-0049: Data Product Archiving

Requirement: The LSST system shall archive all generated Level 1, Level 2, and Calibration Data Products, or provide services to reconstruct any given data product on demand. When regenerated on-demand, the Data Products shall be scientifically equivalent – i.e. at a level of precision sufficient to reproduce the primary and derived attributes well within their formal uncertainties.

This is the core requirement behind "virtual data product" re-creation.

LSR-REQ-0101: Data Processing for Single Visits and Transients

Requirement: The LSST shall meet the following specification for reporting of data on optical transients detected in single-visit data: OTT1, transN, and transSNR.

Discussion: It is unclear whether the SRD specification of transN refers to the number of alerts that can be generated for a single visit (i.e. an instantaneous limit), or the number per visit averaged over time.

It's mildly appalling that the "It is unclear" is still in the document this far into construction.  This needs to be resolved unambiguously.

The parameter description text for transN is "The minimum number of optical transients for which data can be reported per visit", with the value 10,000.  The SRD text from which this requirement is derived says "The system should be capable of reporting such data for at least transN candidate transients per field of view and visit."

  • No labels