Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


ItemWhoPre-Meeting NotesNotes 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 

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

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?

  •  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