Requests:
FAFF document
| Item | Source | Summarization | Contact | Needed in Pipelines | Notes |
|---|---|---|---|---|---|
| Mount azimuth jitter | EFD TMA telemetry | Average over visit timeframe | Needs low latency; computed by Rapid Analysis (needs to process snaps), output via Sasquatch | ||
| Observations that were taken plus FITS headers | Header Service | None | |||
| Estimated depth | Alert Production, later DRP | None | Sasquatch output from AP + replication to PPDB | ||
| Processing error flag(s) | Alert Production, maybe RA? | None |
Providers:
| Item | Source | Summarization | Contact | Notes |
|---|---|---|---|---|
| Camera header data | FITS file headers or extended JSON | None needed | TonyJ | |
| Camera visit database | Drives recent image web view and visualization; extending to tracking whether images have been archived; should merge |
Primary keys need to be identified
Pre-joined convenience views
Questions
Parquet and DR snapshots
What form
- DRP
- day_obs as dimension
- Granularity is visit
- CPP
What data
When needed
- Dump at the beginning of a production, possible update at the end
- Communication between sites and steps are via Butler datasets and not ConsDB
LFA
Anything needed
- Shutter motion profiles in separate files, not in image FITS headers (also ingest as a Butler dataset)
PPDB
Needs to join? Yes
Anything calculated that needs to go to science users should be published via Sasquatch and go into ConsDB
Other
Pipeline outputs
- Rapid Analysis
- Prompt Processing
- Not DRP; that should only have Qserv Visit table (SDM for DR is only generated by DRP)
- "10 AM" processing can produce outputs that go into ConsDB
- But EFD summary information not needed by Pipelines would then need to go through Pipelines untouched?
- Using pipeline outputs from ad hoc processing/analysis as selection criteria — ad hoc outputs are out of scope and part of Campaign Management
- Worried about outputs from processing being used to help select for future processing; setting criteria is OK, but selection lists are not
- Sasquatch can hold system performance metrics
- Prompt Products
- Bitemporality?
- Or multiple columns
- Can have convenience view that selects "best available"
- Update in place:
- Number of CCDs processed — could it be a count of CcdVisit rows?
- Archived flag
- Put in separate tables
- User input/tagging?
- Yes
- Like Exposure Log but added after the fact — enumerations defined by schema
- Could be "good for this, not for that" which might be more CM
- Exposure Log will be part of the ConsDB
- Visit will be defined as including all snaps before this database and DRP processing