...
| Item | Who | Pre-Meeting Notes | Notes and Action Items |
|---|---|---|---|
| Project/Science Updates | 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
| |
| AOB | 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?
|
...