Room System

Phone Dial-in


  1. Dial: or
  2. Enter Meeting ID: 690803707 -or- use the pairing code

Dial-in numbers:

  • +1 408 740 7256
  • +1 888 240 2560 (US Toll Free)
  • +1 408 317 9253 (Alternate Number)

Meeting ID: 690803707



Metric Tracking Dashboard


Discussion items

ItemWhoPre-meeting notes
News, announcements and task review


  • Task review
  • Jenkin saga continues. DM-31846 Jointcal dependency. Script moved into the data repository (rc2_subset) to put the pipelines in the data repository. We don't want a situation with faro being dependent on everything because we need to run pipelines.  Woud like to get signofff from, KT. 
  • Any yaml pipeline definition files run by jenkins must be outside the faro package, preferably in the data package. (Yaml) pipeline run by hand can in the faro package. 
  • Keith to write down use cases for accessing metric results

Bugs, issues, topics, etc of the week

  • It looks like `multiMatch` assumes all inputs are afw_tables, which makes it difficult (or inefficient) to use it with the `sourceTable` (parquet) inputs (see this Slack thread). Are the `forcedSourceTable`s sufficient for our needs?
  • External calibrations have not already been applied to fluxes from the `sourceTable` parquet tables. You still need to read in the FGCM and jointcal calibrations and apply them. Furthermore, before applying the external calibs, you must "undo" the `LocalPhotoCalib` correction that has already been applied to the fluxes in `sourceTable`s (Slack thread here).
    • Yusra suggested that "somebody" should write an afterburner that applies the external calibs and inserts calibrated fluxes/positions into the tables. Could one of us be that "somebody"?

Multimatch: (current code)

  • Until we have different matching algorithm, we will need to use the FITS tables. We don't have an alternative to the multi match algorithm at the moment. EC is interested in working on this if it will be of use to someone. Feeling is he was looking for a driver to keep working on it.
  • Not certain that the forced source photometry table will always be available. Creating coadds adn deblending on coadds are the longest steps at the moment, so if we are only looking at matched visits, will probably not want to take the time to gegnerate coadds and run forced photometry. This will be important in the commissioning context, e.g if we want to run some metrics on 10 or so visits and don't want to wait for the forced source tables. 

  • Three issues here: 
    1. Timing of the availability of forced photometry
    2. Scientific issue of whether we want forced photometry versus independent detection and centering
    3. Multimatch algorithm - we are planning to move away from this anyway to an n-way matching algorithm that does not assume an afw_table input. 

CS: Proposes to get off afw tables as soon as posible.  All the sky processing doess have coadds. We can avoid the isssue of the forced source Implement using the forcedSourceTables.  We can support the commissioning use case later. 

KB: Can we spend a few hours to remove afw_tables from multi-match. For bright isolated stars, we can use multi-match.  Aggregate function is very slow, can take minutes to compute the average RA. 

KSK: search for multimatch in lsst org - 15 hits - -most are faro, vailidate_drp, a few in notebooks. 

External calibrations: 

  • Parquet Source files do not have these external calibs applies
  • Need to do this if we want to apply external calibrations to source tables. Will allow us to bypass the stage of reading in the external calibrations 
  • These are input to FGCM - needs to run as an afterburner for now. 
  • Not high priority for now but we should do this. Ticket on backlog DM-31855 - Getting issue details... STATUS

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  DM-31762 - Getting issue details... STATUS
    • Probably external calibrations, afterburner, check that faro is picking up the correct inputs. 
  • w_2021_38 RC2
    • In progress. This will be the first reprocessing to include `forcedSourceTable` parquet files.
    • DM-31795 - Getting issue details... STATUS
  • DM-31762 - processing did not include the external calibrations - this explains diff between the G2/3 runs. Also proves that the calibrations work (smile) 
  • w_2021_38 RC2 still processing - will run faro on the outputs when complete. 

Faro for DP0.2

  •  Hsin-Fang reports that the high level workflow will be frozen on . We need to also have the faro pipelines that will be run defined and part of the workflow. Practically it’s adding faro pipelines into those steps in DRP.yaml  so that faro runs integrated with DRP.

  •, 2.1.4 High level workflow of workflows
  • W_2021_40 was planned to be the starting point for DP0.2, including the cleaned up parquet schema that was presented at the DM-SST meeting. See RFC-807
  • There will be single tract test V&V run using weekly 40.  
  • Add clustering in mid October - also any fixes from V&V run - then make candidate for the step1 processing pilot run  (w_42)
  • Jeff has tested this in DRP.yaml in rc2_subset. Separated into SFP and coadd processing and ran 2 groups at the end. 
  • i.e compute SVP metrics at the stage of SVP rather than waiting for everything to finish
  • Wants to do more testing in CI imsim DRP.yaml before going with it. 
Development status 
  • Fall 2021 epic DM-30748 - Getting issue details... STATUS
  • Backlog epic:  DM-29525 - Getting issue details... STATUS
  • Jeff to focus on matched source conversion to parquet tables
    • Switch to using forcedSourceTable instead of doing matching of single-epoch detections?
  • Using Object tables  DM-31459 - Getting issue details... STATUS
  • Astrometry –  wait for Object tables in parquet DM-31673 - Getting issue details... STATUS
  • faro documentation: DM-25839 - Getting issue details... STATUS

Potential co-working session ideas:

  • Ensuring that all analysis contexts are included in regular CI testing
  • Documentation hack time
  • Detailed discussion of verification package and metric naming conventions – maybe there needs to be some more homework
  • Complete tract + patch parquet input
  • Plotting tutorial, potentially with Sophie


  • Example source injection metric
  • Performance as a function of focal plane position 
  • Performance as a function of image metadata

List of tasks (Confluence)

DescriptionDue dateAssigneeTask appears on
  • Leanne Guy to talk to Science Pipelines (Yusra) about when do this transfer  
19 Oct 2021Leanne Guy2021-09-28 Science Metric Development Agenda and Meeting notes
  • Leanne Guy arrange to disucss at a future meeting if there are metrics from PDR3 & this paper that we might want to include in faro.   
26 Oct 2021Leanne Guy2021-08-31 Science Metric Development Agenda and Meeting notes
  • Colin to ask about capturing ideas for improvement to the stellar locus algorithm   
30 Nov 2021 2021-11-09 Science Metric Development Agenda and Meeting notes
  • Colin Slater to make a preliminary draft agenda for a workshop to clarify visualization use cases for science verification and validation
Colin Slater2022-04-19 Science Metric Development Agenda and Meeting notes
  • Jeffrey Carlin to review metric specification package organization and the relationship to formal requirements documents
Jeffrey Carlin2022-04-19 Science Metric Development Agenda and Meeting notes
  • Keith Bechtol Schedule a time to have focused discussion on verification package, potentially next status meeting
Keith Bechtol2021-09-14 Science Metric Development Agenda and Meeting notes
  • 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 Bechtol2021-09-14 Science Metric Development Agenda and Meeting notes