Page History

•  Bmad live model
  •  BmadLiveModel 
  •  python PVA service
  •  GUI conversion

Lattice files for Bmad already exist. Current high-level goals are:

• Establish agreement with Lucretia (S2E et al)
• Implement interface to live machine parameters (Buschmann)
• Add Bmad model to python PVA server
• (TBD) Convert GUIs
  • Depends on tao→matlab compatibility
  • alternative: PyTao would let us rejoin the LCLS shared application ecosystem in some areas (emittance GUI, wires)
• Update 08/06/24:  development of BmadLiveModel and server infrastructure is underway. 
  • long term plan is to migrate apps to python, in-line with AD LFD diagnostics group
  • python model interface makes sharing apps with LCLS easier
• Update 08/22/2024: first real-time test successful, live model cold-start is ~3-15s, single-device update response is O(10ms)
• Update 08/26/24: v0.1 non-stable released to production. Added "official" API documentation: https://f2-live-model.readthedocs.io/en/latest/
• Update 08/29/24: PVA server tested successfully
• Update 09/06/24: alpha BmadLiveModel & PVA server deployed to production, server running 24/7 for the time being to stress test
• Update 09/29/24: Added LEM, split server into two processes
• Update 10/9/24: heartbeats are setup, server is deployed 24/7

design page: Bmad live modeling

Github: https://github.com/slaclab/F2_live_model

•  LEM server + watcher conversion
  •  server
  •  GUI

Waiting on model server deployment

• 3/13/24: current plan is to deploy a second PVA server that writes LEM EREF/EACT/BDES etc to an NTTTable, then the ModelReceiver can be updated in-kind to provide those quantities
  • python PVA will make it straightforward to build a LEM CUD
• Update 08/06/24: LEM will run using the Bmad model
• Update 09/10/24: prototyping, will run as a component of the BmadLiveModel
• Update 09/29/24: server part is done, trim code WIP
• Update 10/9/24: ready to test GUI with-beam

Full design notes on Bmad live model page

Github: https://github.com/slaclab/F2_LEM_GUI

•  New longitudinal feedbacks
  •  DL10 energy
  •  BC11 energy
  •  BC11 bunch length
  •  BC14 energy
  •  BC14 bunch length
  •  BC20 energy

• Current feedbacks regulate poorly and are not easily tuned/maintained
  • overall goal: improve overall beam stability, reduce feedback convergence times
• LCLS-SC energy feedbacks are designed with off-the-shelf PID libraries, and written in python, plan is to implement the same
• (from a controls perspective) this is straightforward since through BC11 everything is in EPICS
• SLC device control can be accomplished through python PVA libraries, though this will take some research on RPC usage
• deployment plan:
  • replace feedbacks one-by-one, i.e. run a new DL10 energy feedback, then use preexisting feedbacks downstream

•  RTBSA for FACET-II
  •  python class for streaming BSA data
  •  python class for real-time BSA time series & correlation plots
  •  GUI

• 07/05/2024: Developed proof-of-concept GUI using lcls BSA PVs - works for us as well since our BSA encodes pulse IDs the same way. Corr plot with fitting, time series and FFT are all working.
  • still need to optimize syncing for network performance
  • likely can replace the current RTBSA GUI for lcls as well
• Update 10/9/24: some sync errors to debug, but basic functionality is OK

•  live dispersion GUI

• LCLS dispersion live is, in principle, adaptable to this task. However the complication of needing to read both SLC buffer data and EPICS BSA buffers might make a new implementation simpler
• Update 10/9/24: SLC buffacq is disruptive, need to strategize... EPICs-only live dispersion can be done simply w/ RTBSA tools

•  New Phase scan GUI
  •  L0 phase scan automation

rudimentary functionality, needs with-beam test

update 05/06/24: tested with beam L0, L1 and L2-3 are working, deployment soon...

•  Add quad scan emittance measurement function (for L0)

last step needed to migrate off of the LCLS-side emittance application. seems to be already partially implemented, so the challenge here is partially archeological in nature

Update 09/29/24: should put this on hiatus pending migration back to LCLS app

•  Lucretia model server conversion
  •  python PVA service
  •  matlab interface class
  •  GUI conversion

UPDATE: 08/06/24: Lucretia is being deprecated. The lack of Lucretia resources, both (written and in-person know how), and the poor maintainability of F2_LiveModelApp makes this a suboptimal time investment, especially since the desire was simply for apps to be more performant.

• The F2_ModelReceiver is still usable as a matlab interface to the model server
• Existing matlabTNG apps and the Lucretia model will remain in use, but with life-support only
• physics apps will be ported to python over time (help wanted)
• improved matlab app performance (from the control room) can be achieved with Glen's matlab server

• 1/12/24: demo PVA server works, writing live/design Rs and twiss params, but matlab pvaGet not working yet. next step: document lucretia dependencies across matlabTNG to determine what the matlab interface needs to do
• 1/23/24: matlab PVA access works with a python workaround (good enough for now, likely need a better long-term solution) Cesar prepped draft interface design document. reviewed high-priority GUI model uses. 
• 2/8/24: PVA server is running but not deployed to prod yet. Drafting implementation of matlab class F2_ModelReceiver - once the lucretia functions GetRmats, RmatAtoB and GetTwiss are replicated we can proceed to test GUIs. Need to check w/ controls deputes to get some watcher PVs set up
• 3/12/24: draft version of receiver on GitHub, testing for correctness and use by GUI controllers
• 4/9/24: F2_ModelReceiver 0.1 version is ready for deployment, unfortunately the python models service has some errors in it, but the mechanics of the interface are mostly stable
• 4/18/24: live model is currently starting from the gun, which produces very unrealistic twiss parameters. Need to start sim downstream at some treaty point
  • live model GUI gets marginally more realistic outputs starting from L0BFBEG, one option...
  • more realistic: take the latest PR10571 emittance measurement, back propagate to initial twiss at L0AFBEG – there are some kind of hooks in place for this already. but I'm not 100% on if they ever worked...