|Item||Who||Pre-Meeting Notes||Notes and Action Items|
No PST meeting last week
|Follow up on Catchup/retry processing and database structure|
Previous discussion at 2022-12-05 DM-SST Agenda and Meeting Notes
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
Next meeting is:
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?