(This page should ultimately be replaced by a JIRA query against the envisioned future JIRA reimplementation of the change request database, using labels to represent "DM is interested in this". At the moment it is manually maintained.)
This page is manually maintained (primarily by Gregory Dubois-Felsmann and Tim Jenness). It contains change requests originated by DM as well as ones from or affecting other LSST subsystems which the editors believe will be of interest to DM staff. It also omits certain manifestly DM-related change requests that are primarily concerned with PMCS technicalities and will not be subject to full CCB action. These change requests are always available by querying the database for DM-originated requests. The editors welcome comments on this policy!
We are not generally including LCRs concerning matters like budget adjustments and routine milestone changes.
Minor updates to DMSR, mainly to reflect updated terminology. Terminology and schema changes in DPDD. More substantive changes to DM-level documents. Updated to include a need for OSS changes.
LSE-78 is the top-level design document for the Rubin Observatory Long-Haul Networks connecting La Serena - Santiago - US - France. It has been quite some time since it was updated and needed a refresh, as well as being made consistent with the final "as-built" configuration that will be in place at the start of operations. This LCR requests to update the document,
The purpose of this Change Request is to clarify that the Data Management System will be capable of generating templates for image differencing separately from Data Release Production.
Proposal for new name for the LSST Science Platform
Multiple DM-level documents use the old name.
VERA: the Vera Rubin Observatory Environment for Research and Analysis.
It was announced at the project all hands of 2020-04-09 that the name “Rubin Science Platform” has been selected by the directorate before the formal completion of the CCB process.
DMS-REQ-0183 as currently written erroneously implies that we must provide a secondary link between the Base and Archive (LDF) that is capable of twice the provisioned capacity of the primary link. That is an overstatement and is not required for operations or catch up, nor is it feasible from a cost standpoint, nor is the it baseline Base - Archive Network Design.
This LCR corrects the wording of this requirement to reflect the real need, as well as the design baseline.
(More detailed explanation appears in a comment on this LCR.)
Add AuxTel Spectrograph IT Equipment Installation Activity
None
There will be several pieces of IT equipment to install when the AuxTel spectrograph arrives in Chile, e.g. control servers, etc. This activity was previously considered part of IT-514, but that activity is complete and this is on a different and later schedule.
LSE-309 was baselined in August 2017. Since that time, much has occurred, and the design and implementation of ITC in the Summit, Base, and Summit-Base network has gone forward. This LCR provides updated information to better reflect the "as-built" systems.
Commissioning De-Scope LSSTCam Observing and SV Mini-Surveys
Removes 2 months of Science Pipelines testing from the Commissioning Plan. Reduces SV mini-survey from 3 months to 2 months, resulting in smaller survey areas.
OSS-REQ-0033 was removed from the OSS by LCR-899. It has recently been discovered that this broke the flowdown for two existing DM requirements, but also that this requirement applies in some respects to the whole Observatory, not just to the scheduler itself.
OSS-REQ-0387 (Photometric Performance) was belatedly flowed down from the LSR in LCR-924. This change request corrects a transcription error from the implementation of that LCR, as well as fixing a long-standing typo in the transcription of these parameters from the SRD.
Camera would like to descope the requirement to provide crosstalk correction in the DAQ (that had been intended to support Alert Production). Inter-CCD crosstalk within a raft has been measured to be very small; inter-raft crosstalk is expected to be very small as well and will be measured soon. Consequence: if the Camera does not do it, then DM will have to do it in AP. If it's limited to intra-CCD crosstalk, then this is already within the HSC experience base and probably has little impact; if it's inter-CCD, intra-raft, though, it has a significant architectural impact on AP and may also have a real impact on the alert latency budget. (If there is inter-raft crosstalk, there's no existing architecture to handle it and we have a significant risk.)
more clearly describes how forced photometry is handled by adding an additional table schema to the document, and specifies that this data will be included in the alert packets;
clarifies the distinction between "Prompt" data products and "Data Release" data products
"... require the selection of specific security controls for each subsystem's computational resources. Additionally, the master security plan now requires the implementation of a small set of baseline controls for all LSST systems unless sufficient justification has been made and a variance has been granted (or unless prohibited by a site's own security policies). ..."
"The DAQ API delivers pixel data in an in-memory representation different from the ICD. This LCR changes the ICD to match the API, as it is considered infeasible to change the API to match the ICD."
Updating "LSE-319 to better match the current state of the LSP design and nomenclature. The major changes are to more explicitly describe what is meant by 'next-to-data' processing and to confirm the VO-orientation of the LSP interface design."
Remove normative text which refers to the use of snap differencing for cosmic ray rejection, as it is in conflict with the existing requirement to support the Alternate Standard Visit (1x30s).
Adopt LSE-349, "Defining the Transformation Between Camera Engineering Coordinates and Camera Data Visualization Coordinates", as a baseline, and insert reference to it into the OSS (LSE-30).
Update: The problem was found to originate in the flowdown from the SRD to the LSR. The LCR has been modified with new language for both the LSR and OSS that, finally, correctly implements the SRD specification. Outside the scope of the LCR, the DM-SST is researching whether the original SRD requirement still properly supports the needs of weak lensing science.
OSS-REQ-0234 (10-year Ellipticity Residuals) and OSS-REQ-0390 () are almost duplicates and clearly redundant. One should be removed. There is also a parent requirement, OSS-REQ-0389 () that is not very useful.
There are also indications that the flowdown from the SRD to the LSR and OSS was not done correctly; Jim Bosch and Gregory Dubois-Felsmann are investigating.
Update requirement DMS-REQ-0274 to be in sync with the DPDD (LSE-163) to indicate that only 12 months of DIASource history will be included in the alert packets.
This LCR applies LCR-733 to LSE-140 and corrects some other minor issues. It does not attempt to fully define the telemetry items expected from the auxiliary instrumentation; that will be left for a later LCR.
This is the "Deep Detection and Measurement Quality" requirement. It is argued that it is "both unhelpful to scientists and awkward for DM to implement now" and "asking for something DM is not planning to deliver because it's not actually something anyone wants."
The Base Network plan has been delayed relative to the baseline due to the updated schedule for construction and occupancy of the Base Facility. This LCR reflects the updated dates.
The US Network plan has been delayed while we coordinated with ESnet for dedicated 2 x 100 Gbps links between Atlanta and Chicago. The ESnet links provide additional path diversity and guaranteed latency for prompt processing over leased service from internet2. This coordination is documented in a request document and technical requirements document, which when finalized will be posted in docushare. The activities and dates in this LCR reflect the implementation plan and schedule for the ESnet links.
LSE-239 was developed to provide the definition of the Base Data Center (BDC) requirements for the Base construction contracts and the BDC Information Technology and Communications (ITC) infrastructure design. Since that version, much has been learned and the requirements have been migrated into the project SySML requirements model. A new version of LSE-239 has been prepared as a document generated from Magic Draw, and has also been substantially re-organized, to more cleanly separate those sections directly applicable to the Base Facility construction contract (Sections 1 - 3), versus those more targeted at the ITC infrastructure design (Appendices I and II). Finally, as the formerly baseline Tape Library has been recommended to be replaced in the BDC ITC design baseline (LCR-781 and follow-on), requirements related to the Tape Library have been deprecated into Appendix III.
Resolves a long-running formal gap in our requirements flowdown. Makes the contents of the DPDD (LSE-163) authoritative in deriving DM-level requirements (i.e., in the DMSR, LSE-61) by stating in the OSS that the data products generated by DM shall conform to the DPDD.
Notes ~60 day delay in the installation of the Summit-Base and Base-Santiago DWDM equipment, triggered by late delivery from the equipment vendor. New schedule shows installations complete by roughly November 2017.
Adds the new image types introduced by LCR-773 (New Camera Image Types) to the Camera requirements and OCS-Camera ICD. Superficially this doesn't require a response in DM-level documents; however, the exploitation of the new image types is driven by calibration requirements and so most likely they should eventually appear in DM documents.
Note that as of LCR-773 itself is Approved but not Fully Implemented.
This is mostly a cleanup pass on a key OCS middleware definition document. The DM-to-OCS interface depends on its contents, so it's likely that some consequential changes to LSE-72 will be needed.
In 2015, the project shifted from the then-existing DM-to-T&S ICD LSE-77 to a new "Base Data Center Requirements" document, LSE-239, to capture the needs of DM for data center space at the Base. LSE-77 became effectively a dead letter in the process. This change request is intended to just clean that up. Final result: LSE-77 has been withdrawn.
Perform additional early integration activities, notably around the use of the CCOB camera test facility to generate data to be ingested into DM on a regular basis.
LSE-63 has not been updated since 2011. This update includes some minor modernizations based on current best practice and removes mention that we are currently in R&D phase.
Adopt the following requirement: "The LSST project shall maintain user access to the contents of all Data Releases. This facility may be provided with reduced performance and capacity for Data Releases older than the most recent one, but be qualitatively identical otherwise." in place of the current policy of maintaining access only to the two most recent data releases.
Proposes that a common Summit-Base service be created that extracts all observation metadata (from published telemetry or the EFD) intended to be packaged with the image files, storing an artifact containing all this metadata as "headers" for later retrieval.
Q: Does this have anything to do with the reformatted EFD database? -XW
LCR-849 is to make LSE-78 consistent with and refer to the Network Sizing document LDM-142. Requested CCB if this can be voted on via the electronic voting process. I think it is non-controversial and was discussed at some length in the DM TCT when we last updated LDM-142.It would be good to get this done, as there are a number of more significant changes to the same documents coming very soon as a consequence of Tiger Team activities.
Implicitly sharpens requirements on ability to determine the correct pixel geometry upon data ingest from Camera to DM. May have an implication for the generation of difference imaging templates, at the (~annual) template-creation level and/or at the nightly template-warp-instantiation level.
Eliminate Base Network Outage Buffer; Expand Summit Camera Image Buffer
Unclear
Kevin Long is awaiting guidance on what WBS element to use for the additional budget for the enlarged buffer.
The "documents affected" is "Unclear" because it has not been completely decided whether to implement this as a change to requirements or as a specification that exceed the requirement. This is a separate question both at system and at Camera level.
Provide a means for the OCS to launch predefined batch processing actions at the Archive Center. Likely to be used for, e.g., producing synthetic calibration images following the collection of the input flats, bias frames, etc.
Requires that DM be able to handle two types of standard visits: two 15s exposures, or one 30s exposure. Somewhat vague on the question of how closely the two types of visits could be interleaved.
A further round of technical updates to the OCS-to-subsystem device interface. The draft already serves as the basis for the prototype and early integration work that is ongoing.