DMLT meeting-2023-09-11

Wil O'Mullane

• NSF arriving in La Serena today
• Victor here in Chile
  • Wants to check on doing mirror work earlier if needed
• AMCR uneventful
  • still would like an end date we can live with
  • by next AMCR - run a couple of scenarios
  • AMCR visit in November
• Strategic planning (9am PT) will be about camera delivery and M1M3 
  • If we do M1M3 in November we can not have Camera on summit before March.
  • baseline charge should be done now - 3552. We know it will potentially change after schedule workshop (OCT4)
  • need to know what prep is needed and which NOIRLab and off project resources can be deployed to help over next nine months.
• No all hands meeting in Wednesday - Oct 6th (but clash with JOG) 10 Pacific (would avoid JOG a bit)
• Crane - Meloni need to authorize local tech to visit and fix. Holding up M@ and ComCam work.
• Dome cable. Cristián Silva needs to send communications to Jeff Barr.
• More contractors for camera arrival - desire to have it done and waiting. Vacuum jacket lines in place .. some have long mead time (2-3 months)

Which team owns UWS or is willing to - it needs work on TTS right now .. who do we have ....

• Universal Worker Service on TTS. This is a DM task.
• FE: UWS is a standard, no one owns it. Are we talking about a particular implementation. K-T: Implementation by NCSA originally. FE: so USDF now. 
• CTS: What is it running? K-T: The OCPS. It allows DM pipelines to be run in the summit environment from the OCS (by scriptqueue) 
• WOM: Indeed its software that no one owns anymore. There's a question on whether we ought to have it or replace it. 
• K-T: If you want script to trigger something. Batch isn't going to do it. Prompt Processing isn't going to do it. The back end can be replaced, the front end is necessary. 
• SRP: What does it do again?
• K-T: The OCPS EDC received a command from scriptqueue over DDS and executes a pipeline using this UWS backend service. 
• WOM: Questions is where it ends up in operations. It needs to be owned by some group. We couuld dump it on T&S, but that doesn't feel quite right since its an opening to run DM pipelines on the control system
• FE: We have to organizationally solve the problem that we have a missing team... that does Python level components between the DM layer. DM doesn't have any free cycles. You can use this as an argument to keep the software teams together. This becomes and easier problem if we keep it together.  But I don't want it. It's too close to observing and the dome, and I didn't have a say in it.
• FE: the question is who takes the OCPS that drives pipelines at the summit.
• K-T: It is currently in use. 
• TJ: Robert had a dream where he'd tweak the CBP and take some data and then tweak the whatever and take some data. 
• KTL: The only data-driven framework we have at the summit now is Rapid Analysis.
• CTS: We don't have anyone who can make the call that we don't need UWS here right now. 
• FE: We can discuss as people who know how to structure software, or we find someone who can answer "Do we need OCPS?" or can we use RapidAnalysis instead. 
• KTL: These are two distinct things with two distinct use cases. While you can make one do the other, it becomes a weird fit. Driving processing via labels is different thatn driving processing via explicit responses. 
• FE: I find it hard to believe that we've come up with all these orthogonal frameworks.
• CTS: If I take 50 biases, and then combine them.  That last one is a command. Putting a command in the label works around not having a commanding system. 
• WOM: Why can't this be a batch command that says "process these 50 biases" 
• KTL: The backend can be batch, but the frontend is needed. The OCPS CSD is 500 lines of Python most of which is CSC boilerplate.
• FE: Do all frameworks that DM come up with belong to one group? If we don't collect them under one umbrella, then we just perpetuate them. If DM owns frameworks that drive processing, then they need to come under one umbrella to make architectural decisions. 
• FE: I do not own processing frameworks, My recommendation is that Wil find a single organizational umbrella. Perhaps middleware. 
• WOM: I would like to replace the backend with batch, but that means installing condor.
• TJ: Allegedly I'm supporting the prompt processing framework (SteveP). I don't think header service is a DM thing anymore. Camera has taken over. There's nothing DM about it. 
• WOM: it's something we built in DM, (KT: because it fed our stuff) but is not really DM anymore. If we don't look after header service, I'm afraid of what we'll get out of it. 

3 things:

(1) Batch Service. Carlos is building htcondor. Can it be deployed on TTS? CS: It could be deployed but could be some porbles the low resources. 

(2) Need to make a case to Bob that between Andy, Tiago they need a new software group.

• Wil O'Mullane writes up a proposal (consulting with Tiago, Andy, and Frossie) about what to do with header service and OCPS. 

(3) Short term we need someone to help with Michael R. KTL: I can help him with the front end, but not the backend. Sounds like I can't help him. Is this an emergency? K-T will talk to Michael R. No one at Princeton knows K8s, Some people at UW do. Frossie can help if its very time boxed. 

See also LSST Verification & Validation Documentation and LDM-692 (VCD).

Test Plans due in the next 45 days

Milestones due in the next 45 days

• Risk dash board

Risk items needing review

Overdue risks (obligation date passed)

Risk mitigations due at the end of this month

Overdue risk mitigations

Frossie Economou