11:00 Eastern; 08:00 Project/Pacific Time. bluejeans.com/426716450

Attendees

Notes


Merlin Fisher-Levine —

  • Future time allocation for Merlin — 
    • Until the end of the calendar year, we plan to split Merlin's time 50-50 between DM (managed by John Swinbank) and SIT-COM (managed by Chuck Claver).
    • John Swinbank will put this in writing in an e-mail to all the interested parties after this meeting.
    • With the DM time, we will continue working on existing activities (e.g. Spectractor, etc); SIT-COM time is obviously up to Chuck (but we expect it to be focused on AuxTel integration).
    • We will get together as a group late in the year to decide how to allocate Merlin's time in calendar 2020.
  • Code repositories for commissioning / AIT —
    • Following recent discussions in #lsst-ats, Merlin is concerned about rapid QA for data coming from LATISS (and presumably ultimately ComCam and LSSTCam).
    • He has ideas about how to script some simple checks, but is concerned to make sure that these don't get “lost” —
      • They should not live in a personal Git repository, but rather in some commonly agreed location that is visible to everybody and increases the chance of future reuse.
      • On the other hand, they do not want to be bound by the regular rules of DM engineering and camera agnosticism, as it's not clear they are useful here (and, in general, camera agnosticism won't be useful in commissioning: by definition, we are commissioning LSST, not a collection of arbitrary cameras).
    • Ultimately, having some bundle of commissioning-produced code which is versioned and installed along with the Science Pipelines, but which does not need to adhere to the same rules, seems like it would be a useful facility.
    • There is some overlap with thinking being done by Simon Krughoff.
    • Agreed that Merlin should chat with Simon and come up with a concrete proposal.
  • AuxTel rapid QA —
    • At least for now, we think this is a SIT-COM activity, rather than a DM one.
    • It seems like this will run on the diagnostic cluster (which we can't actually find in plans anywhere...) as an ad-hoc series of scripts, rather than as part of the regular DM pipeline system.
    • However, it's worth considering how this might ultimately form part of DM's QA system: certainly, at least the algorithmic steps should be reusable, even if whatever script runs them isn't.
  • There are many AuxTel questions still outstanding. Merlin is doing his best to get an overall understanding, but the learning curve is steep!

Andrés Alejandro Plazas Malagón—

  • Still working on the PTC ticket; DM-20069.
    • Needs to write unit tests.
    • Can be inspired by the tests in cp_pipe.
      • See e.g. test_ptc.py in cp_pipe tickets/DM-20069.
    • Agreed that ad-hoc data processing should go on new tickets.
      • Some already did on DM-18052.
  • Thinking about linearity.