All
- Does Focus Friday apply for SV work, including #rubinobs-science-verification Slack channel?
- Camera team has been developing a similar software package as faro for camera verification purposes. This is being posted to Gen 3 (ongoing work by Eric Charles) as https://github.com/lsst-camera-dh/eotask-gen3/
- There is also a collection of pages organizing the presentation of static plots in a hierarchical fashion: https://srs.slac.stanford.edu/BOT_EO_Reports/
- eotask-gen3 is persisting some of the results as astropy tables in a format that can be used to easily create plots of values for each amp across the focal plane (~3K measurements).
- Focus Friday:
- Commissioning currently does not have Quiet Friday. NOIRLab has second-Friday no meetings. Guidelines for Focus Friday at this link.
- RSV is a mixed channel, DM. Camera, Commissioning folk.
- We are not a support team/channel - support considerations do not apply
- Proposal: No regularly scheduled meeting. One-off meetings can be OK – judgement call. Co-work sessions doing development are welcome. Slack channel is open for business. DM members observing Quiet Friday don't need to feel obligated to respond. "@" – use judiciously and don't chase people down, only "@" people already in the channel. Don't '@' a dm person in a dm channel. Mixed channels are different and the same rules cannot be easily applied.
- Leanne Guy and Keith Bechtol to inquire with SCLT about approach in SIT-Com.
- Leanne Guy to post a message anout the policy in #rubinobs-science-verification
- EOTest
- Goal - to do reverification of the camera on the summit. Also cp_verify package. cp_verify / eotest - what are the req.s dcos they map to. No clear answer. Implications for OSS reqs - characterization of the science pixels. Overlap with eotest_g3/cpp_verify.
- lots of good work in the repo and similar to faro.
- static plots but better organized.
- Not using lsst.verify measurements but astropy tables. e.g to easily present all1 16 amp measurements from all rafts.
- CS: want to answer, is this bias that we made aceptable, or did something go wrong. We have requirements to produce a bias/flat/dark - so we need ot verify them. Not instrument/sensor perf
- KB: should follow up to understand
- Keith Bechtol to make a ticket to better understand mapping of these camera and calibration products characterization efforts to verification documents and the focus of these efforts. Discuss with the SCLT
- Keith Bechtol to make a ticket to better understand mapping of these camera and calibration products characterization efforts to verification documents and the focus of these efforts. Discuss with the SCLT
Bugs, issues, topics, etc of the week
- New dataset status
- Changes to dispatch_verify,
- Handling of NaN
- Jeff and Sophie Reed have started discussing the relationship between faro and analysis_drp visualization tools (see
). Should we (a) broaden the scope of the discussion, and (b) invite Sophie to present about her plotting tools (and configurable actions) at an upcoming SV meeting?
- rc2_subset: Jenkins changes made, KT approved. Merge this afternoon and will run tonight.
- ... but ... cannot yet dispatch with NaN. This is the real blocker now.
- Time to run nightly is exepceted to be long - we will do some first runs and time it. If it takes to long, look at getting more h/w
- PF found a bug in the call signature for analysis contexts using parquet table inputs related to changed in our base class. Will updates to yaml files in repo be automatically propagated to nightly CI? KSK thinks yes.
- Jeff will give us a demo at the first co-work session.
- JC: analysis_drp uses configurable actions for the new plotting package. Wanted to make sure we are on the same page about persisting measurements, metadata, etc.
- Jeffrey Carlin to coordinate with Sophie about a time to have technical discussion about plotting tools and potential integration with faro, potentially a co-working session
- Jeffrey Carlin to coordinate with Sophie about a time to have technical discussion about plotting tools and potential integration with faro, potentially a co-working session
Reprocessing status and metrics review
- Nightly CI with new rc2_subset
- w_2021_34 RC2
- w_2021_36 DC2
- From DRP QA meeting - bad astrometry and photometry metrics for gen2to3 as compared with native gen3 processing – see
- Probably external calibrations, afterburner, check that faro is picking up the correct inputs.
- From DRP QA meeting - bad astrometry and photometry metrics for gen2to3 as compared with native gen3 processing – see
- Do we want a dedicated dashboard nightly CI metrics for faro? Yes
- Fall 2021 epic
- Backlog epic:
- Jeff to focus on matched source conversion to parquet tables
- Using Object tables
- Astrometry – wait for Object tables in parquet
- faro documentation:
- Substantial comment is providing guidance on the naming of the metrics and association with verification package – for now, this should no block development and release of faro documentation. We will need to return to the topic of the verification packages as this is
- Keith Bechtol Schedule a time to have focused discussion on verification package, potentially next status meeting
- Keith Bechtol Schedule a time to have focused discussion on verification package, potentially next status meeting
- Substantial comment is providing guidance on the naming of the metrics and association with verification package – for now, this should no block development and release of faro documentation. We will need to return to the topic of the verification packages as this is
Link to poll: http://whenisgood.net/faroCowoking
Co-work session is scheduled for ..... 11:00 PDT Wednesday
- Leanne Guy get Aime to set up a calendar invitation
