You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 76 Next »


Overview


This page summarizes the design & implementation of the interface between the live FACET-II controls system and the FACET2E Bmad model. The infrastructure consists of two layers:

  • BmadLiveModel: a python class responsible for watching the accelerator and updating a live instance of PyTao based on extant machine settings
  • The live model PVA service: a process that runs it's own BmadLiveModel and publishes data to table PVs

BmadLiveModel

The goal of this class is to provide access to an instance of Tao that can view/manipulate the FACET2 Bmad model with settings that match those of the actual production accelerator.

Device Monitoring

Connection to the production controls system is handled mainly via EPICS Channel Access PVs (as well as limited use of AIDA-PVA for klystron timing statuses). During real-time streaming, callback functions are used when a change in each live quantity of interest is broadcast over the network. When live quantities change, these callbacks will either (a) submit update instructions to a shared queue or (b) request a recalculation of the live momentum profile by the LEM-watcher thread. Additionally, a second daemon thread (model-update) will periodically empty the queue and execute all the scheduled update commands and then update the BmadLiveModel.live and .LEM data structures.

Real-time controls-system monitoring is accomplished using PV callback functions.

  • RF-related PVs (i.e. klystron ENLDS, phases etc) will request a LEM update, which will trigger the LEM-watcher to recalculate the live momentum profile
  • Other PVs (magnet BACTs etc) will directly directly submit the update of a given parameter to a shared queue. To do so, each function must:
    • convert the new value into Bmad units (i.e. from kGm → T, GeV → eV etc)
    • submit a tuple of (element name, attribute, value) to the command queue

PyTao updates

The BmadLiveModel python class loads the FACET2E lattice and runs a local copy of pytao.Tao. This instance of tao is both the engine used by the class to update the live lattice, as well as a part of the public interface of the code. BmadLiveModel.tao is a publicly accessible attribute of the class itself

model-update

This thread is responsible for executing all the submitted update requests using Tao, and to updating derived quantities (BLEM) and python data structures.

  1. empty the command queue of (approximately*) all submitted updates
  2. run all the set ele commands, then re-calculate lattice parameters
  3. update the live.p0c, live.e_tot, live.twiss, live.quads, live.bends, live.rf, live.LEM data structures

LEM

LEM (LINAC energy management) is a set of algorithms responsible for estimating the beam momentum profile and calculating the corresponding lattice quad settings. This code only calculates the momentum profile, errors and magnet settings. Actually setting magnets in the accelerator will be handled by a LEM server GUI (coming soon...).

  • BmadLiveModel will monitors the klystron complement and bend magnet settings to calculate the live momentum profile of the beam
  • Periodically, the server will use the live momentum profile to calculate energy errors and magnet settings, which are published to a table PV

Detailed overview of LEM implementation: LEM_notes-3.pdf

LEM-watcher

This is the second daemon thread spawned by BmadLiveModel and is responsible for calculating the live beam momentum profile as described below, and for submitting update requests for cavity voltages and phases to the command queue.

PVA model server

The principal use case for the BmadLiveModel is running a real-time live model server. This server runs its own BmadLiveModel, and then publishes live model data to scalar and table PVs accessible on the controls system via EPICS PVAccess. The code for the live model itself is relatively simple, and is derived from the lcls_live_model server.

Access to the live Bmad model server (for twiss/rmat data), is mediated by the python meme service

Implementation: F2_live_model code

The code for all the infrastructure described in this document lives together. Source code can be viewed on GitHub, and API documentation is available online.

  • SLAC network master repository: /afs/slac/g/cd/swe/git/repos/slac/FACET/F2_live_model.git
  • Production deployment: /usr/local/tools/python/F2_live_model
  • GitHub mirror: F2_live_model.git

BmadLiveModel Usage

The public interface to the code is documented here: f2-live-model.readthedocs.io/

BmadLiveModel operates in three distinct modes, depending on the input flags at construction:

Modekw argCode snippetNotes
design model onlydesign_only
f2m = BmadLiveModel(design_only=True)

Static design data only.

BmadLiveModel.live is not defined

live data with manual updatesinstanced
f2m = BmadLiveModel(instanced=True)
f2m.refresh_all()
# --> your code here

This mode is designed for making lattice tweaks in Tao relative to extant machine settings.

The refresh_all() function is used to update model data.

live data with real-time streaming
f2m = BmadLiveModel()
f2m.start()
# --> your code here
f2m.stop

or:

with BmadLiveModel() as f2m:
    # --> your code here

This is the default mode. Provides live data at the minimum latency, but has a higher background processing cost.

Use of the context manager (i.e. the with keyword) is the most pythonic practice, but manual start() and stop() functions are also defined. 

Warning: Interacting with tao while live updates are happening in the background makes it possible to get yourself into trouble)

Model server data description

PV nametable columnsnotes
BMAD:SYS0:1:FACET2E:LIVE:TWISSelement, device_name, s, z, length, p0c, alpha_x, beta_x, eta_x, etap_x, psi_x,  alpha_y, ..., psi_y
BMAD:SYS0:1:FACET2E:LIVE:RMATelement, device_name, s, z, length, r11, r12, r13, r14, r15, r16, r21, r22, ..., r65, r66linear maps from the beginning of the linac to the downstream face of each element
BMAD:SYS0:1:FACET2E:LIVE:URMATelement, device_name, s, z, length, r11, r12, r13, r14, r15, r16, r21, r22, ..., r65, r66single-element linear maps (i.e. from the upstream to downstream face of each)
BMAD:SYS0:1:FACET2E:DESIGN:TWISSelement, device_name, s, z, length, p0c, alpha_x, beta_x, eta_x, etap_x, psi_x,  alpha_y, ..., psi_y
BMAD:SYS0:1:FACET2E:DESIGN:RMATelement, device_name, s, z, length, r11, r12, r13, r14, r15, r16, r21, r22, ..., r65, r66
BMAD:SYS0:1:FACET2E:DESIGN:URMATelement, device_name, s, z, length, r11, r12, r13, r14, r15, r16, r21, r22, ..., r65, r66
BMAD:SYS0:1:FACET2E:LEM:DATAelement, device_name, s, z, length, E_ref, E_act, E_err, BLEM, BDES, BDES_SAVEfinal data TBD (but single NTTable seems simpler than lcls-style per-device PVs)

Additionally, the service will publish scalar PVs of the estimated linac amplitudes/chirps/fudges by calculated by LEM. Their names are as follows:

  • BMAD:SYS0:1:FACET2E:LEM:<XX>_FUDGE
  • BMAD:SYS0:1:FACET2E:LEM:<XX>_AMPL
  • BMAD:SYS0:1:FACET2E:LEM:<XX>_CHIRP

where <XX> is a "LEM region", either L0, L1, L2 or L3, for a total of an additional 12 PVs. (ex: BMAD:SYS0:1:FACET2E:LEM:L2_FUDGE)

Dependencies

Source file descriptions

Source: F2_live_model/Details
~/docs/config files for sphinx
~/.readthedocs.yamlconfig for readthedocs.io doc generation
~/structs.pyauxiliary data structures for holding beamline data
~/bmad.pyimplements the BmadLiveModel class

~/server.py

live model PVA service

~/demo.ipynb

Jupyter notebook with simple examples of how to use BmadLiveModel
  • No labels