2023-01-30 DM-SST Agenda and Meeting Notes

Leanne Guy

Eric Bellm 

Context: How do we handle / withdraw sources that result from bad processing, e.g ISR was bad or a large amount of junk DIASources and DIAObject in a visit. 

Original proposal was to use the DIAObejct validity start/end ranges. DIAObjects will have a change in validity as they are expected to be replaced - this is not the same as saying that they are bad. New proposal is to add 2 new columns 

GPDF: Bad DIASources can lead both to “purely bad" DIAObjects as well as to contamination of nearby existing "real” DIAObjects.

GPDF: What is the DIASource record unique key in this model? The model assumes a DIAObject has an immutable unique set of backlinks to DIASources - are these just deleted and replaced with new unique identifiers when reprocessed?

EB: Should get new identifiers

CTS: Will need to design a way to have unique sourceIds for reprocessing in any case - no way to make new sourceIds match old sourceIds

CTS: DIASource tells you what the DIAObject is - so one knows the processed time anyway but it is also good to have the "time_processed" 

GPDF: Does not handle the case where a DIAObject is contaminated by bad processing

EB: If we reprocess we have to withdraw bad sources and the linkages will be removed in that process.

RHL: Subset of the general provenance problem. How do we manage the processings that contribute to a DRP? Does this solve this problem? 

EB: Probably not because we are sending alerts and a user facing aspect not present in DRP.

GPDF: DRP does not have an identity preserving update in place.

CTS: Propose a discussion of the actual DRP use cases but is tangential here.

CTS: If we send a CCD back through processing, everything that the CCD touched has to be updated and we need that provenance in place.

GPDF: SSObject lack of validity ranges was an oversight in the original model 

CTS: What are the images that went in and when was the orbit fitting run? Take off line and think through - are there 2 different timescales here. Assume that at time of orbit fitting that all images exist. 

CTS: Adding time_processing is a win 

• Eric Bellm to wrap this proposal into an upcoming large RFC for  APDB changes (see also DM-37693) 28 Feb 2023 

Leanne Guy

Next meeting is: 13 Feb 2023 

RHL: How do we use the info from the AuxTel for calibrations - how much do we have to commission early. Current plan is when when LSSTCam comes on sky? 

LPG: What does 'commission early' mean - aren't we commissioning now?

ER: I think the real issue here is "does the spectroscopy and atmosphere coming from AuxTel need to be part of DR1?" Not mission critical to have the AuxTel atmosphere for  DR1 - nice to have but also not necessary to have  100% uptime

LPG: So it's a question of prioritizing items for commissioning. 

KB: Analogous issue with the CBP for DR1 

ER: Will we get all the CBP stuff together. Need the monochromatic laser on the flatscreen and that would get us filter scans

KB: Getting to the phase where we need a very clear definition of the steps from construction to operations. Staged process with multiple verification events proposed at the schedule workshop and we need a clear definition of what needs to be done, e.g AT data being fed into DRP processing  - is this a requirements to begin the 10-yr survey

ER: AuxTel spectro-photometry - will be useful but not mission critical 

RHL: Will we get a spectro-photometry system that is good enough - do we need to look at in-kind contributions?

• Eli Rykoff , Leanne Guy  Develop a proposal for what calibration processing, hardware, data we actually need and what will be needed for DR1. This has implications for the ORR and for prioritisation of work in commissioning 28 Feb 2023