The Header Service component of DM will have an initial design review on 2017-10-10 at 11 AM Project Time (PDT/MST), 1 PM Central Time.
Attendees:
Presenter: Felipe Menanteau
DM Systems Engineering: Kian-Tat Lim, Donald Petravick, Tim Jenness, Gregory Dubois-Felsmann
Outside experts: Dave Mills, Robert Gruendl, Russell Owen
BlueJeans:
Connecting directly from a room system?
1) Dial: 199.48.152.152 or bjn.vc
2) Enter Meeting ID: 281757062 -or- use the pairing code
Just want to dial in? (all numbers)
1) Direct-dial with my iPhone or
+1 408 740 7256+1 408 740 7256
+1 888 240 2560+1 888 240 2560 (US Toll Free)
+1 408 317 9253+1 408 317 9253 (Alternate Number)
2) Enter Meeting ID: 281757062
Objectives:
As described in LDM-294 section 9.3, the design review will check that the design:
- meets the requirements and satisfies the use cases, and an implementation can be verified as doing so
- conforms to the LSST DM architecture and has well-defined interfaces
- is expected to be efficient in terms of labor cost, non-labor cost, and schedule
- is expected to be reliable, maintainable, supportable, usable, and secure
- conforms to good engineering practices
The primary document to be reviewed is DMTN-058. This document includes motivation, requirements (with a proposed test plan), and design information, in addition to concerns and questions that still need to be answered.
Notes:
- Need to agree on requirements
- It's a destination, not a source
- To be discussed later, depends on project
- May be on a separate machine but still part of cluster
- No
- Only for NCSA Complete L1 Test Stands, can also work at Tucson for integration
- Code-based released configuration files
- Configuration key/value pairs published on DDS
- Also could be extended to capture "knobbing"
- No, can have cache of published configuration in DDS
Concerns
- GPDF: Meant to serve needs of summit systems and minimal amount for archiving, not long-term consumption
- Agreed, but should be configurable
- Procedure should go through Systems Engineering
- Definition of a metadata item should be in configuration, not code
- This configuration is different from hard-coded items
- DM has a set of metadata defined that AP can use: VisitInfo structure, but also need orientation of sky and spider
- Russell and Felipe should walk through VisitInfo to determine sources in real system
- Related to atomic unit of archiving?
- Don: Captures anything that should be captured
- Approximate WCS would not come from Camera; may not want it
- Need to discuss LFA interface later offline (depends on client)
- Gives uniformity
- Russell: Concern is that computation is incorrect or inadequate; harder to change in Header Service than DM Stack — e.g. many equations for airmass
- GPDF: Header Service should not be accountable for long-term correctness of anything
- RobertG: Major issue is 1 or 189 or 189*16 pieces
- GPDF: Courtesy metadata is useful for people looking at raw archived files with non-LSST tooling; files should be minimally useful with common tools (not an operational requirement but a debuggability consideration); WCS is most important
- Russell: Can ignore some headers and rewrite in DM code
Requirements:
- Felipe prefers whatever JimP wants
- Internally they are dictionaries
- Russell: Why not a database?
- File is simpler; an alternative could be the whole string as a message
- GPDF: JimP's system is not the only source of materialization of files; wavefront sensing does not get files from JimP; but they may also use FITS
Failure modes
- Failures upstream that prevent getting data
- System crashes (but rest of EFD is running), then stop taking images
- RHL/Russell: must keep taking images
- GPDF: Could drop Alert Production for a few visits, but could have problems if Active Optics depends on these and if the downtime is long
- Can do engineering activities even if EFD is down
- Other critical systems cannot operate in degraded mode; Header Service could perhaps be part of a degraded mode
- Whether we should have a header regenerator in the case of failure is unclear
- AP xtalk — Russell (walk through VisitInfo)
- Archiving raw — Jim Parsons
- Wavefront sensing — Sandrine/Te-Wei
- Summit visualization — ?
- Camera Diagnostic — Tony
- Missing data: missing data is missing period, even from EFD, not just missing from Header Service
- Why reading directly from telemetry vs. the EFD: the EFD gets information from DDS; faster and more immediate to get from DDS; EFD is just another listener
- Why doesn't Header Service ask for items it needs? OCS commands everything in our design
Outcome:
- Design is reasonable, with requested configurability, given uncertainties in requirements, but some aspects may need to change as requirements evolve
Action Items:
- Felipe Menanteau to contact potential clients above to discuss content and use cases
- Felipe Menanteau to transform requirements into spreadsheet for loading into SysML model; requirements to be reviewed as part of incorporation into an LSE requirements document.