Teeport

Teeport is a real-time communication platform for optimization. An optimizer and the problem it is solving connect to a WebSocket server as separate clients, and the server relays candidate points one way and measured objectives the other. Neither side has to run in the other's language or building: a Matlab evaluator inside the SPEAR3 control room can be driven from a laptop, and a Matlab algorithm can borrow a Python library mid-loop. I built it at SLAC in 2019–2021 and published it as first author in Frontiers in Big Data (2021).

26message types in the WebSocket protocol
27plugins: optimizers, evaluators, processors
SLAC + ANLtested and deployed

Why

In online accelerator tuning the evaluation script that sets magnets and reads back the objective lives on a control-room computer, often in Matlab; the algorithm lives on a physicist's laptop, often in Python. The usual fix is to copy the algorithm into the control room and adapt it by hand, and to redo that for every new algorithm or problem; sometimes an external runtime is not allowed there at all. Teeport leaves both sides where they are and moves only data.

How

Everything is a function with a fixed signature: an evaluator is Y = evaluate(X, configs), an optimizer is optimize(evaluate, configs), and a processor is results = process(data, configs), a stateless helper. Adapters for Python and Matlab normalize X and Y to 2-D arrays in JSON; the API is six verbs, run_ and use_ for each role. use_evaluator(id) returns an ordinary local function, so an existing algorithm optimizes a remote machine with a two-line change while the measurement happens wherever the evaluator runs.

Diagram: an optimizer sends X through an adapter to the Teeport server, which forwards it through another adapter to an evaluator; Y = evaluate(X) flows back the same way — Figure 1. The optimization loop with Teeport in the middle. Figure from the Teeport documentation, 2020.

The Node.js backend groups clients into tasks, one per run, and only forwards messages and records history over one 26-type JSON protocol shared by seven client roles. Because every batch passes through the server, pause, resume and stop come free: pausing holds the pending batch, resuming replays it, and the algorithm never notices. The server never sees algorithm or evaluation code, and whoever runs the evaluator keeps the right to stop it. The React dashboard adds live plots, comparison of runs, a benchmark mode that reruns an optimizer N times with mean, spread and Pareto-front views, and JSON export/import. It deploys as a local package or a cloud service, which is what a cross-lab run needs.

What I did. Came up with the idea; designed and implemented the whole base framework: backend, frontend, plugins, the Python adapter and most of the Matlab adapter (Minghao Song tested the prototype and contributed to the Matlab adapter). All 447 commits in the four repositories are mine. Ran the SPEAR3 tests with Xiaobiao Huang and Minghao Song; first-authored the paper.

Results

Teeport dashboard showing the evaluation history of PSO, RCDS and a GP optimizer against the SPEAR3 beam-loss-rate evaluator — Figure 2. Live comparison of three optimizers against the SPEAR3 beam-loss-rate evaluator. Figure adapted from Zhang, Huang & Song, Frontiers in Big Data, 2021.

Diagram: Matlab MG-GPO sends X0, Y0 and X1 through Teeport to a GPy processor in Python, which returns the prediction Y1 — Figure 3. A Matlab algorithm calling Python's GPy through a processor. Figure adapted from Zhang, Huang & Song, 2021.

Remote online optimization. The SPEAR3 beam-loss-rate evaluator was published from a Matlab session in the control room and optimized from a laptop; the tuning numbers are on the MG-GPO & RCDS-S page.
Cross-language development. MG-GPO is written in Matlab; its Gaussian-process modelling ran in Python's GPy as a Teeport processor during the SPEAR3 experiments.
Extending other tools. Wired into the Ocelot optimizer as a plugin, so new machine interfaces and algorithms could be added without further Ocelot changes.
Footprint. About 9k lines across the Node.js backend, React frontend, Python client and plugins; the public instance at teeport.info is still up.

Counts: SPEAR3-ML repositories, August 2026, and the paper. The open-source server keeps task state in memory; export/import is how runs are kept. Teeport was the first pass at a problem that Badger later solved for day-to-day operators.