What is the model for managing calibration products during the operational era?
For example, are calibration products versioned through git repositories (as they are during construction)? Are they exclusively managed through the Butler? At what points can data be “ingested” to a data repository?
My understanding is that the middleware and calibration products teams have built an impressive toolbox of technologies that can be used to implement whatever data management policy we want, but that nobody has yet written down what that policy should be... and many people have different, incompatible, implicit policies in their heads.
Raw calibration data is not included here; all raw data is kept together in Butler repos in the Data Backbone regardless of purpose. Not; all raw data together no matter purpose
The logic to choose which master calibration products to use when processing data is currently undefined.
We need to define the available technical solutions, but more so we need to define processes and procedures, not just the technical design.
Would a more active product owner or an assistant help with pushing this definition, without needing a working group?
The next Ops Rehearsal has dealing with master calibrations as an explicit part.
Middleware has been defining one strategy via RFC on obs_lsst_data for pipeline-generated products that are converted to human-readable forms for acceptance and curation in a git repo. Simon and Tim are working on a DMTN describing this.
Tim Jenness — Extend the DMTN to solve whole problem or at least describe the future questions to be answered; leverage/delegate to Chris Waters to avoid overload.
Leanne Guy — Consider how to engage with calibration product data management from product owner side.
Alert science in early operations would be enhanced by incremental template generation prior to DR1.
How much effort would be required of the construction project?
Do we have estimates of the operations effort to run it during LOY1?
Incremental: what does it mean?
We make a template once in year one, and then we don't modify it after it has been made. We don't keep adding to existing templates.
We are aware of coverage & overlap issues here.
How many images are needed per filter to make a template?
3 is the number Eric likes, but there is some ongoing discussion.
3 is consistent with requirements on image noise.
Do not expect any form of DCR correction in year 1.
No disagreement with Eric's estimate of pipeline & workflow development.
Ops plans are not yet clear enough to speak directly to Eric's plans for Execution and QA, but they sound plausible.
Absent templates, what happens when images arrive at the LDF (assuming no alert production).
Enough single frame processing to return telemetry to the scheduler.
Template generation would be run at end-of-night.
Eric says prompt-processed-style PVIs would be sufficient for incremental template generation; don't need the more elaborate DRP system.
How do we manage the impacts of some data being available to users before project-provided data products? How do we prevent our own users from scooping us? What products are we producing? How do we prevent everybody trying to use the LSP to access the data and do their own reductions?
Some of this can be controlled with throttling.
Agreed to return to this topic at a future meeting.
We will LCR expanding the construction scope as proposed by Eric.
Then it will be Bob's call as to how the Operations team reacts.
Wil O'Mullane — schedule a discussion about rolling out data products and capabilities to users without having them scoop the project or swamp our resources.
Eric Bellm — submit an LCR describing changes to the construction plan to enable incremental template generation.
There are many DPDD update tickets; need to prioritise getting them done.
Speed of development for Pipelines vs. DPDD changes is very different; impedance mismatch.
It is not necessary that the DPDD list everything described in the SDM; it's also possible to queue up DPDD updates on master rather than baselining them as they arrive.
What is the “missing link” between the SQL schema and consumers (Qserv, etc)? Is it Felis?
Who is maintaining Felis since BVan left DAX?
Suggestion that a testing framework is necessary.
Hsing-Fang may have the best sense of what is the next most useful utility to be added to the Felix toolkit, and she would be in the best place to make this happen – consensus that Hsin-Fang will be the Felis maintainer.
Changes to BaselineSchema.yaml should be change controlled.
Need to write a technote on what the schema is, where it's used, where it's going, etc. Some tension between providing enough visibility into what's happening without overly constraining or overloading the people who are doing the work. Agreed that Wil would do this as a compromise.
Leanne Guy — produce a plan for interaction between the DPDD and the concrete SDM schema.
Fritz Mueller — find somebody to update the online schema browser.
Kian-Tat Lim — arrange for the schema browser to be removed, until & unless the action to update it comes true.
Colin Slater — ensure change control policy for BaselineSchema.yaml is documented.
Wil O'Mullane — write a technote descibing his understanding of schema management
Full-bandwidth testing is pending availability of the forwarders; these are not currently being procured due to uncertainty over the post-crosstalk-descope data acquisition design.
Do not regard this lack of testing as a major risk.
LSST Security Summit is coming up in April. Agenda unknown (until then, talk of encryption is just speculation).
Query whether there should be a full VNOC at the summit, given that it is likely to be staffed during the night.
Query as to whether international partners need VNOCs.
VNOC is a small set of servers, directly measuring aspects of network performance (dropped packets, etc), and providing a facility to document network events, together with a transmission of that information to a central collecting point, which then publishes to web portals.
Brief discussion of the plan for Ops Rehearsal #2, which is coming up soon.
Longer term discussion. What are our future operations rehearsals? Are they being scheduled to reflect particular hardware deliveries or other capabilities, or based on the calendar? Are we really treating them as “operations rehearsals”, or are we misusing this word to mean “integration exercise”?
We should be clear that making data available “through the LSP” means more than just having it accessible on a filesystem through a Butler.
Expectation is the rehearsal terminates after running pipelines and simple QA; no data being made available for community inspection.
Note that “prompt processing” in these slides are in scare quotes for a reason — they are not LDM-148 Prompt Processing Service processing, but just data processing that takes place soon after data has been acquired.
Kubernetes cluster at the base is about a week away.
Keen to run what verification we can during the ops rehearsals.
Some consensus on moving operations rehearsals away from hardware delivery dates, not least because hardware become available will almost certainly be immediately pressed into use.
Only hard part in terms of Gen3 middleware is making data incrementally available.
Ie, incremental visits arriving, contrasted with a complete data release.
John Swinbank would be a good point of contact for information on and coordination of pipelines activities.
Wil O'Mullane (with Bob Blum) — coordinate schedule for Ops Rehearsal #2 with the LATISS team to make sure that we aren't disrupting LATISS engineering work.
Tests have been performed on satellite trail rejection.
The uncertainty on Tony Tyson's claim that we may lose 30% of images is that it's not clear how different future satellite constellations will look from precursor data, and we have some technical concerns with some of the analysis which has been performed to date.
HSC has a narrow field of view, and a relatively small survey time allocation; just been lucky it's not seen any so far.