# Flat beam plasma wakefield accelerator
††thanks: This work was performed with support of the US Dept. of Energy,
Division of High Energy Physics, under contract no. DE-SC0017648 and
DESC0009914.

Pratik Manwani  Department of Physics and Astronomy
University of California, Los Angeles
Los Angeles, USA
<EMAIL_ADDRESS>Nathan Majernik  Department of Physics and Astronomy
University of California, Los Angeles
Los Angeles, USA
<EMAIL_ADDRESS>Joshua Mann  Department of Physics and Astronomy
University of California, Los Angeles
Los Angeles, USA
<EMAIL_ADDRESS>Havyn Ancelin  Department of Physics and Astronomy
University of California, Los Angeles
Los Angeles, USA
<EMAIL_ADDRESS>Yunbo Kang  Department of Physics and Astronomy
University of California, Los Angeles
Los Angeles, USA
<EMAIL_ADDRESS>Derek Chow  Department of Physics and Astronomy
University of California, Los Angeles
Los Angeles, USA
<EMAIL_ADDRESS>Gerard Andonian  Department of Physics and Astronomy
University of California, Los Angeles
Los Angeles, USA
<EMAIL_ADDRESS>James Rosenzweig  Department of Physics and Astronomy
University of California, Los Angeles
Los Angeles, USA
<EMAIL_ADDRESS>
###### Abstract

Particle beams with highly asymmetric emittance ratios are expected at the
interaction point of high energy colliders. These asymmetric beams can be used
to drive high gradient wakefields in dielectrics and plasma. In the case of
plasma, the high aspect ratio of the drive beam creates a transversely
elliptical blowout cavity and the asymmetry in the ion column creates
asymmetric focusing in the two transverse planes. The ellipticity of the
blowout depends on the ellipticity and normalized charge density of the beam.
In this paper, simulations are performed to investigate the ellipticity of the
wakefield based on the initial driver beam parameters. The matching conditions
for this elliptical cavity are discussed. Example cases for employment using
the attainable parameter space at the AWA and FACET facilities are also
presented.

###### Index Terms:

plasma acceleration, elliptical beams, asymmetric wake, beam matching, plasma
lens

##  I Introduction

Plasma wakefield acceleration (PWFA) using elliptical beams with highly
asymmetric emittances, or ’flat beams’ requires investigation for future
collider applications. Flat beams are employed at accelerator facilities like
AWA [1] and are also foreseen at FACET-II [2]. Flat drive beams yield a
blowout cavity that is elliptical in cross section, which leads to asymmetric
transverse focusing, and have been proposed for numerous applications. For
example, asymmetric beams that drive wakefields in hollow channel plasmas are
considered for positron acceleration [3]. For colliders, beams with highly
asymmetric emittance are expected to mitigate beam-beam effects
(beamstrahlung) at the interaction point [4]. These applications require
accurate accounting of the matching conditions and beam loading effects of
these asymmetric beams. Both the axisymmetric and approximated elliptical
wakefield have linear focusing fields which allow us to match these beams. It
is also important to understand how flat beams behave in plasma afterburner
scenarios [5, 6], and compatibility with corresponding betatron diagnostics
[7]. Practical considerations for the development of a flat beam PWFA
experiment at the AWA facility, and its potential development at FACET-II,
will be presented here.

##  II Linear regime

We first consider a beam with general form, $n_{b}=n_{b,0}X(x)Y(y)Z(ct-z)$. If
the beam density is small compared to the background plasma density,
$n_{b,0}/n_{0}\ll 1$ we can use the linearized wake equation, with $\xi=ct-z$,
to get the perturbed plasma electron density ($n_{1}$):

$\displaystyle\left(\frac{\partial^{2}}{\partial{\xi}^{2}}+k_{p}^{2}\right)n_{1}(x,y,\xi)=-k_{p}^{2}n_{b,0}X(x)Y(y)Z(\xi)$
(1)

where $k_{p}=\omega_{p}/c$ is the plasma wavenumber. For a Gaussian beam, this
gives

$\begin{split}n_{1}(x,y,\xi)=-k_{p}n_{b,0}\exp{\frac{-x^{2}}{2\sigma_{x}^{2}}}\exp{\frac{-y^{2}}{2\sigma_{y}^{2}}}\\\
\int_{\epsilon}^{\infty}\exp{\frac{-\xi^{\prime
2}}{2\sigma_{z}^{2}}}\sin{\left(k_{p}(\xi-\xi^{\prime})\right)}d\xi^{\prime}\end{split}$
(2)

where $\sigma_{x,y,z}$ are the spot sizes of the beam. We can simulate the
beam plasma interaction in this linear-fluid limit, by using particle in cell
(PIC) simulations with the three dimensional fully relativistic PIC code,
OSIRIS [8]. The simulation results of the interaction in this regime with the
corresponding analytical results are shown in Figure 1. The full response of
the fields can be found from the density response given in equation 2 and the
electromagnetic wave equations which are given as:

$\displaystyle(\nabla_{\perp}^{2}-\frac{\omega_{p}^{2}}{c^{2}})\vec{E}=-e\nabla(\frac{n_{1}+n_{b}}{\epsilon_{0}})-\frac{e}{\epsilon_{0}c}\frac{\partial
n_{b}}{\partial t}\hat{z}$ (3)
$\displaystyle(\nabla_{\perp}^{2}-\frac{\omega_{p}^{2}}{c^{2}})\vec{B}=4\pi
e(\nabla\times n_{b}\hat{z})$ (4)

Figure 1: PIC simulations showing the asymmetric wakefield created by an
asymmetric driver when the beam density is low ($n_{b}/n_{0}\ll 1$)

##  III Elliptical blowout

For high beam densities, the plasma electron trajectories cross and there is a
formation of an elliptical blowout sheath. We simulate this by using particle
in cell (PIC) simulations with the three dimensional quasi-static PIC code,
QuickPIC [9]. The simulation parameters are listed in table I. The transverse
asymmetry of the wakefield produced by the asymmetric beam can be seen in
Figure 2. The single density spike that is observed in the axisymmetric case
is replaced with a cluster of electrons that can be seen as a line of high
density behind the blowout region due to the ellipsoidal shape of the wake.
This elliptical cavity created by the evacuated plasma electrons and its radii
($a_{p}$ and $b_{p}$) are shown in Figure 3. Inside this ion column
($\frac{x^{2}}{a_{p}^{2}}+\frac{y^{2}}{b_{p}^{2}}<1$), the wake equations can
be written as:

$\displaystyle\phi(\xi,\alpha_{b},\alpha_{p})=\phi_{0}(\xi)+\phi_{p}(\xi,\alpha_{p})+\phi_{b}(\xi,\alpha_{b})$
(5) $\displaystyle
A_{z}(\xi,\alpha_{b})=A_{z0}(\xi)+c\Phi_{b}(\xi,\alpha_{b})$ (6)
$\displaystyle
F_{x}=\partial_{x}\phi_{p}+(1-v_{z})\partial_{x}\phi_{b}+(1-v_{z})\partial_{\xi}A_{x}-v_{y}B_{z}$
(7) $\displaystyle
F_{y}=\partial_{y}\phi_{p}+(1-v_{z})\partial_{y}\phi_{b}+(1-v_{z})\partial_{\xi}A_{y}+v_{x}B_{z}$
(8)

Here, the parameter $\alpha_{b}$ is defined as the beam ellipticity of a beam
with spatial extent of $a$ and $b$ in the $x$ and $y$ direction respectively,
and $\alpha_{p}$ is defined as the ellipticity of the transverse cross section
of the elliptical cavity. In addition, $\phi$ denotes the scalar potential,
$\vec{A}$ denotes the vector potential, and $F_{x}$ and $F_{y}$ denote the
transverse forces inside the blowout cavity.

TABLE I: Simulation parameters Parameter | Value | Unit
---|---|---
Beam density, $n_{b}$ | 15 | $n_{0}$
Energy, $E_{b}$ | 50 | MeV
$\sigma_{z}$ | 10 | $k_{p}^{-1}$
$\sigma_{x}$, $\sigma_{y}$ | 0.25,0.025 | $k_{p}^{-1}$
$\epsilon_{x}$, $\epsilon_{y}$ | 200, 2 |  $\mu$m-rad
Plasma density, $n_{0}$ | 7 $\times$ $10^{13}$ | cm-3

Figure 2: The longitudinal profile of the elliptical blowout cavity formed by
an asymmetric (flat) beam ($\sigma_{x}/\sigma_{y}=10$)

As a starting point, we can get the ellipticity at the center of the blowout
cavity using the long beam ($r\ll\gamma\sigma_{z}$) approximation where we
neglect the longitudinal variation of the fields and also neglect the effects
of the plasma electron velocity. Under this approximation:

$\displaystyle\partial_{x,y}\phi_{p}=-\partial_{x,y}\phi_{b}$ (9)

The potential inside an ellipsoid is quadratic with respect to the coordinate,
which leads to linear fields. The transverse fields in the elliptical blowout
structure can be calculated analytically by approximating it as an infinite
long cylinder of ions, similar to the axisymmetric case but with an elliptical
cross section and are given by:

$\displaystyle
E_{x,p}=\frac{en_{0}b_{p}x}{\epsilon_{0}(a_{p}+b_{p})}=\frac{en_{0}x}{\epsilon_{0}(1+\alpha_{p})}$
(10) $\displaystyle
E_{y,p}=\frac{en_{0}a_{p}y}{\epsilon_{0}(a_{p}+b_{p})}=\frac{en_{0}\alpha_{p}y}{\epsilon_{0}(1+\alpha_{p})}$
(11)

where $a_{p}$ and $b_{p}$ are the elliptical cross section’s semimajor and
semiminor axes respectively, and the ellipticity $\alpha_{p}$ is defined as
the ratio $a_{p}/b_{p}$.

Figure 3: The transverse profile of the center of the elliptical blowout
cavity formed by an asymmetric (flat) beam ($\sigma_{x}/\sigma_{y}=10$) The
radii of the ellipse are shown as $a_{p}$ and $b_{p}$

Outside the beam (assuming a uniform density beam with no longitudinal
variation), the fields are given as [10]:

$\displaystyle E_{x,b}$
$\displaystyle=\frac{en_{b}ab}{\epsilon_{0}(x+(x^{2}+b^{2}-a^{2})^{1/2})}$
(12) $\displaystyle E_{y,b}$
$\displaystyle=\frac{en_{b}ab}{\epsilon_{0}(y+(y^{2}+a^{2}-b^{2})^{1/2})}$
(13)

Equating these fields on the boundaries, we get:

$\displaystyle
a_{p}=a\sqrt{\frac{\alpha_{b}^{2}-1}{2\alpha_{b}^{2}}}\sqrt{1+\sqrt{1+\frac{4\alpha_{b}^{2}n_{b}^{2}}{(\alpha_{b}^{2}-1)^{2}}}}$
(14) $\displaystyle
b_{p}=a\sqrt{\frac{\alpha_{b}^{2}-1}{2\alpha_{b}^{2}}}\sqrt{-1+\sqrt{1+\frac{4\alpha_{b}^{2}n_{b}^{2}}{(\alpha_{b}^{2}-1)^{2}}}}$
(15)

The ellipticity is then given by:

$\displaystyle\alpha_{p}=\frac{a_{p}}{b_{p}}=\left(\frac{\sqrt{\frac{4\alpha_{b}^{2}n_{b}^{2}}{\left(\alpha_{b}^{2}-1\right)^{2}}+1}+1}{\sqrt{\frac{4\alpha_{b}^{2}n_{b}^{2}}{\left(\alpha_{b}^{2}-1\right)^{2}}+1}-1}\right)^{\frac{1}{2}}$
(16)

The non-linearity of the wake along with the ellipticity reduces with an
increase in beam density. Simulations using long Gaussian beams agree with
this equation at initialization (To make the linear charge density constant,
we scale the beam density by a factor of 2). Specifically, the asymmetric
ellipse fits were obtained from a least squares fit performed on the curve
defined by the border between the blowout and the surrounding neutral plasma.
This border is defined where the normalized plasma density falls below 1/e.
This method of fitting works well when the blowout is stronger as the sheath
is more distinct at higher beam densities. There is good agreement between the
predicted ellipticity and the simulated ellipticity at the center of the
blowout cavity and the results are shown in Figure 4. The approximation of
neglecting the plasma electron velocity does not hold for high beam densities,
and will need to be taken into account to get more accurate results.

##  IV Matching conditions

The focusing forces can be directly derived from the ellipticity of the
blowout cavity by modeling it as an infinite elliptical cylinder as is done
for the axisymmetric case. These linear forces can be used to match the beam
into the blowout cavity by countering the divergence of the beam. A mismatch
will lead to characteristic beating of the beam envelope, causing an increase
in the transverse emittance due to phase space dilution [11, 6] .The matched
beta functions for the beam envelope are:

$\displaystyle k_{\beta,x}=\sqrt{\frac{1}{\gamma
m_{e}c^{2}}\frac{eE_{x}}{x}}=\sqrt{\frac{n_{0}e^{2}}{\gamma\epsilon_{0}m_{e}c^{2}(1+\alpha_{p})}}$
(17) $\displaystyle k_{\beta,y}=\sqrt{\frac{1}{\gamma
m_{e}c^{2}}\frac{eE_{y}}{y}}=\sqrt{\frac{n_{0}\alpha_{p}e^{2}}{\gamma\epsilon_{0}m_{e}c^{2}(1+\alpha_{p})}}$
(18)

The spot size of the beam is then given by $\sigma_{x,m}$ =
$\sqrt{\beta_{x}\epsilon_{x}}$ and $\sigma_{y,m}$ =
$\sqrt{\beta_{y}\epsilon_{y}}$. The ellipticity of the matched beam,
$\alpha_{b,m}$, is then given by:

$\displaystyle\alpha_{b,m}=\frac{\sigma_{x,m}}{\sigma_{y,m}}=\sqrt{\frac{\epsilon_{x}}{\epsilon_{y}}\frac{\beta_{x}}{\beta_{y}}}=\sqrt{\frac{\epsilon_{x}}{\epsilon_{y}}\frac{k_{\beta,y}}{k_{\beta,x}}}=\sqrt{\frac{\epsilon_{x}}{\epsilon_{y}}\sqrt{\alpha_{p,m}}}$
(19)

The emittance ratio is

$\displaystyle\frac{\epsilon_{x}}{\epsilon_{y}}=\alpha_{b}^{2}\left(\frac{\sqrt{\frac{4\alpha_{b}^{2}n_{b}^{2}}{\left(\alpha_{b}^{2}-1\right)^{2}}+1}-1}{\sqrt{\frac{4\alpha_{b}^{2}n_{b}^{2}}{\left(\alpha_{b}^{2}-1\right)^{2}}+1}+1}\right)^{\frac{1}{4}}$
(20)

This result shows that the emittance needed to match the beam envelope to the
focusing forces needs to account for the ellipticity of the plasma column. The
blowout ellipticity and concomitantly, the emittance ratio required to match
the beam will vary along the length of the blowout cavity and this will be
discussed in a subsequent paper.

Figure 4: Comparison of analytical and simulated blowout ellipticities at
$\xi=0$ created by long Gaussian beams ($k_{p}\sigma_{z}$=10). The dotted
curves represents the analytical solution for the blowout ellipticity for a
given beam ellipticity ($\alpha_{b}$), while the markers correspond to the
simulation points obtained at initialization of the plasma wakefields

##  V Experimental considerations

The AWA facility is an ideal location to experimentally investigate key
features of the flat-beam driven PWFA. The experiment at AWA [5] involves
using the asymmetric beam to drive a weak blowout in a plasma created by a
capillary discharge. The capillary discharge plasma source, commissioned at
UCLA, has a multi-decade range of densities, which will allow exploration of
the varying regimes described in this paper. The condition of weak blowout
creates head erosion in the drive beam which decreases the beam density and
leads to the increase in blowout ellipticity. This dynamicity is also
reflected in the beam matching condition and an optimal solution to this
problem require consideration of many factors. In the other scenario of strong
blowout, beams that will be available at FACET-II would have significantly
higher beam densities at the interaction point. At these high densities, an
asymmetric beam will create an axisymmetric blowout. Preliminary simulations
with the asymmetric FACET-II beam show the bifurcation of the beam after long
propagation distances, in which the beam splits into two equal halves. This
could be a potential violation of the quasi-static condition implied in
QuickPIC and this extreme beam density case would need to be benchmarked with
a full 3D PIC code but the asymmetric nature of the bunches makes it
computationally intensive.

##  VI Conclusion

The structure of the plasma columns formed by elliptical beams determines the
focusing forces of the wakefield which governs the dynamics of the beam. This
makes it integral to understand the formation and ellipticity of the plasma
column for plasma wakefield experiments and plasma afterburner scenarios which
employ asymmetric beams. The results shown here provide information on the
ellipticity and emittance requirements for matching the beam inside the
elliptical blowout cavity. The limiting case for the flat beam has been
investigated theoretically [12] and work is ongoing to understand and
generalize the properties of this asymmetric beam plasma interaction. The
inequality in the focusing forces in the two transverse planes offers novel
opportunities, one of which is the creation of an asymmetric plasma lens which
is a subject of further study.

## Acknowledgment

This work was performed with the support of the US Department of Energy under
Contract No. DE-SC0017648 and DESC0009914. This work used resources of the
National Energy Research Scientific Computing Center (NERSC), a U.S.
Department of Energy Office of Science User Facility located at Lawrence
Berkeley National Laboratory, operated under Contract No. DE-AC02-05CH11231.

## References

  * [1] Xu, Tianzhe, Conde, Manoel, Ha, Gwanghui, Kuriki, Masao, Piot, Philippe, Power, John, and Wisniewski, Eric. Generation High-Charge of Flat Beams at the Argonne Wakefield Accelerator. United States: N. p., 2019. Web. doi:10.18429/JACoW-IPAC2019-WEPTS094.
  * [2] Camacho, O., Halavanau, A., and Robles, R. (2022). Generation of High Emittance Ratios in High Charge Electron Beams at FACET-II. JACoW, IPAC2022, MOPOTK045. doi:10.18429/JACoW-IPAC2022-MOPOTK045
  * [3] Zhou, Shiyu, et al. “High Efficiency Uniform Wakefield Acceleration of a Positron Beam Using Stable Asymmetric Mode in a Hollow Channel Plasma.” Phys. Rev. Lett. 127, 174801 (2021) - High Efficiency Uniform Wakefield Acceleration of a Positron Beam Using Stable Asymmetric Mode in a Hollow Channel Plasma, 22 Oct. 2021, journals.aps.org/prl/abstract/10.1103/PhysRevLett.127.174801.
  * [4] Pisin Chen, ”Differential luminosity under multiphoton beamstrahlung”, Phys. Rev. D, vol. 46, pp. 1186-1191, Aug. 1992. doi:10.1103/PhysRevD.46.1186
  * [5] P. Manwani et al., “Beam Matching in an Elliptical Plasma Blowout Driven by Highly Asymmetric Flat Beams”, in Proc. IPAC’22, Bangkok, Thailand, Jun. 2022, pp. 1802-1805. doi:10.18429/JACoW-IPAC2022-WEPOST046
  * [6] P. Manwani et al., “Asymmetric Beam Driven Plasma Wakefields at the AWA”, in Proc. IPAC’21, Campinas, Brazil, May 2021, pp. 1732-1735. doi:10.18429/JACoW-IPAC2021-TUPAB147
  * [7] M. Yadav et al., “Radiation Diagnostics for AWA and FACET-II Flat Beams in Plasma”, in Proc. IPAC’22, Bangkok, Thailand, Jun. 2022, pp. 1791-1794. doi:10.18429/JACoW-IPAC2022-WEPOST042
  * [8] Ricardo Fonseca et al., ”Osiris: A three-dimensional, fully relativistic particle in cell code for modeling plasma based accelerators”, in ICCS’02, Amsterdam, Netherlands, Apr 2002, pp. 342-351. doi:10.1007/3-540-47789-636.
  * [9] C. Huang, V.K. Decyk, C. Ren, M. Zhou, et al., ”Quickpic: a highly efficient particle-in-cell code for modeling wakefield acceleration in plasmas”, J. Comput. Phys., vol. 217, no. 2, pp.658-679, Sep. 2006. doi:10.1016/j.jcp.2006.01.039
  * [10] Parzen, G. Electric Fields of a Uniformly Charged Elliptical Beam. United States: N. p., 2001. Web. doi:10.2172/1157275.
  * [11] San Miguel Claveria, P., et al. “Betatron Radiation and Emittance Growth in Plasma Wakefield Accelerators.” Philosophical Transactions of the Royal Society A: Mathematical, Physical and Engineering Sciences, vol. 377, no. 2151, The Royal Society, June 2019, p. 20180173. Crossref, https://doi.org/10.1098/rsta.2018.0173.
  * [12] Baturin, S. S. “Flat Bubble Regime and Laminar Plasma Flow in a Plasma Wakefield Accelerator.” Phys. Rev. Accel. Beams 25, 081301 (2022) - Flat Bubble Regime and Laminar Plasma Flow in a Plasma Wakefield Accelerator, 16 Aug. 2022, journals.aps.org/prab/abstract/10.1103/PhysRevAccelBeams.25.081301.

.


#  _Mamba_ : a systematic software solution for beamline experiments at HEPS

Yu Liu1,*, Yan-Da Geng2, Xiao-Xue Bi1, Xiang Li1,3,
Ye Tao1,3, Jian-She Cao1,3, Yu-Hui Dong1,3, Yi Zhang1,3,*

11footnotetext:  Correspondence e-mail<EMAIL_ADDRESS><EMAIL_ADDRESS> Institute of High Energy Physics,
Chinese Academy of Sciences, Beijing 100049, People’s Republic of
China.22footnotetext:  Kuang Yaming Honors School, Nanjing University, Nanjing
210093, People’s Republic of China.33footnotetext:  University of Chinese
Academy of Sciences, Beijing 100049, People’s Republic of China.

## Synopsis

Keywords: Bluesky; experiment control; fly scan; high-throughput experiment;
software architecture.

_Mamba_ is a _Bluesky_ -based experiment control framework being developed for
HEPS; its frontend and backend collaborate through a RPC service, and most
importantly command injection. Improvement of _Bluesky_ ’s support for high-
frequency and high-throughput applications is in progress, with _Mamba Data
Worker_ as a key component. Other plans, including an experiment parameter
generator and _Mamba GUI Studio_ , are also discussed.

## Abstract

To cater for the diverse experiment requirements at the High Energy Photon
Source (HEPS) with often limited human resources, _Bluesky_ is chosen as the
basis for our software framework, _Mamba_. In our attempt to address _Bluesky_
’s lack of integrated GUIs, command injection with feedback is chosen as the
main way for the GUIs to cooperate with the CLI; a RPC service is provided,
which also covers functionalities unsuitable for command injection, as well as
pushing of status updates. In order to fully support high-frequency
applications like fly scans, _Bluesky_ ’s support for asynchronous control is
being improved; to support high-throughput experiments, _Mamba Data Worker_
(_MDW_) is being developed to cover the complexity in asynchronous online data
processing for these experiments. To systematically simplify the specification
of metadata, scan parameters and data-processing graphs for each type of
experiments, an experiment parameter generator (EPG) will be developed;
experiment-specific modules to automate preparation steps will also be made.
The integration of off-the-shelf code in _Mamba_ for domain-specific needs is
under investigation, and _Mamba GUI Studio_ (_MGS_) is being developed to
simplify the implementation and integration of GUIs.

##  1 Introduction

With the upgrade of synchrontron radiation facilities across the world, great
progress is being continously made in providing X-ray beams with better
emittance and coherence, as well as employing optical components and detectors
with higher performance. Experiments with high communication frequencies or
high data throughputs, as well as experiments involving multiple modes,
complex _in situ_ environments or automated changing of samples, are becoming
increasingly prevalent. While allowing for the multi-scale, multi-feature and
_in situ_ characterisation of samples, this also poses fundamental challenges
to experiment control and data acquisition/processing, both in experiments
themselves and the preparation steps before them. The large number of
beamlines at many facilities, especially new facilities under construction,
also result in the hard demand to implement diverse experiment requirements
with a manageable codebase. At the High Energy Photon Source (HEPS) (Jiao et
al., 2018), a 4th-generation synchrotron radiation facility, where 14
beamlines will be provided in 2025 in its Phase I and up to 90 beamlines in
total can be served in further phases, all issues above are to be expected. In
order to address these issues while keeping our codebase maintainable with
often limited human resources, proper architecture design must be carried out
for the software components involved.

The foundation of _Mamba_ , our software framework, is the Python-based
_Bluesky_ (Allan et al., 2019); before making the choice, we had researched
multiple well-known alternatives for similar applications, like _GDA_
(Gibbons, Heron and Rees, 2011), _Sardana_ (Coutinho et al., 2011), _Karabo_
(Hauf et al., 2019) and _py4syn_ (Slepicka et al., 2015). Here we avoid
discussing the details of our choice, and instead note that the choice is not
based on the availability of readily usable features, but based on the total
efforts needed to adapt the publicly available codebase to our applications.
When saying “total efforts”, we not only include the efforts in development
and maintenance of our own codebase, but also include those in understanding,
fixing and customising the provided codebase. After our research, we concluded
that because of the quite well-designed device interfaces (classes from
_ophyd_) in conjunction with the simple yet relatively powerful mechanism to
combine them in interlocked actions (`RunEngine` from _bluesky_) and represent
extracted data in a friendly format (the “documents”) in real time, _Bluesky_
is likely to fulfill a satisfactory fraction of the requirements at HEPS with
the best cost-to-effect ratio. A first issue with _Bluesky_ is the lack of
integrated graphical user interfaces (GUIs); we discuss our approach to this
issue in Section 2. For other challenges we note in the above, we give our
plan of ongoing development in Section 3.

##  2 _Mamba_ ’s backend and frontend

The first issue we observe with _Bluesky_ , in comparison with its easily
composable programming interfaces, is the lack of integrated GUIs. For some
experiment tasks this is more like just an obstacle to users with a relatively
weak background in programming, but there are also tasks that are
fundamentally easier with GUIs than only with keyboards. One good example is a
requirement from the hard X-ray high-resolution spectroscopy beamline (B5) at
HEPS (_cf._ also Huotari et al., 2017), where many regions of interest (ROIs)
need to be specified that properly cover individual light spots in sample
images taken from area detectors (and light spots in images that will follow);
another example is the manipulation of data-pipe graphs for _Mamba Data
Worker_ (_cf._ Section 3). Since _Bluesky_ recommends the _IPython_
interactive command line interface (CLI) of Python for its regular use on
beamlines, we have designed _Mamba_ with cooperation between the CLI (_Mamba_
backend) and our GUIs (_Mamba_ frontend) in mind; inspired by _AutoCAD_ -like
software (called _parametric modeling software_ in its industry), we
extensively use what we call _command injection_ (Figure 1) to implement this
cooperation. Before discussing the communication architecture of _Mamba_ in
detail, we note that its frontend is still very immature in terms of internal
structure and robustness; however, the architecture between the backend and
frontend, which is the subject of this section, has been tested successfully
in a real tomography experiment on a testbed for HEPS.

Figure 1: Command injection in _Mamba_ , showing an error caused by attempting
to log out twice after a successful experiment session; we explicitly note
that appearance of the GUIs may vary in the future due to ongoing frontend
refactoring

With command injection, we basically treat GUIs as _code generators_ : most
user operations with GUIs are translated into equivalent commands that get
injected into the CLI, where they are actually executed. This design is
beneficial in many ways, in terms of both user friendliness and architectural
soundness. Users can naturally learn to use the CLI from using GUIs, and those
more proficient in programming may abstract repeated tasks into succinct yet
reusable CLI snippets. Sometimes in order to perform some tasks that are not
yet implemented or simply inflexible with GUIs, developers may even ask users
to execute a few lines of code in the CLI; this is particularly meaningful
when considering that developing the GUI for an application is typically much
more complex than developing its CLI counterpart. The emphasis of GUIs as code
generators also helps developers to naturally design optimal interfaces when
implementing requirements, which increases modularity and consequently
facilitates maintenance (especially automated testing). To summarise the above
up, command injection allows the CLI and GUIs to complement each other
constructively, reducing workload for both users and developers.

The actual communication architecture between the backend and frontend of
_Mamba_ is shown in Figure 2. The backend is run as a subprocess of a wrapping
program, which is based on the _pexpect_ library and forwards input from the
user and output from the subprocess; the forwarding program also listens on a
socket (_ZeroMQ_ `REP`) that _command injection clients_ can connect to, which
send the actual injection requests (Figure 3(d)). This way, commands are
injected as if they were from the user’s keyboard. A problem with _pexpect_
-based command injection is the lack of feedback: because the wrapping program
does not understand the input semantics of the program (_eg._  _IPython_) it
wraps, it only knows whether some command has been successfully injected,
instead of the final result (return value or exception in Python, _cf._ Figure
1) of its execution. For this reason, we encapsulate command injection with a
remote procedure call (RPC) service started by the `server_start` function in
the _Mamba_ -specific startup script for _IPython_ (Figure 4); the RPC service
is a native Python thread with access to relevant _IPython_ interfaces, so it
can capture the results of injected commands and return them to its clients.

Figure 2: _Mamba_ ’s communication architecture Figure 3: Example _Mamba_
communication: (a) normal request/reply, (b) replies upon errors, (c)
notification, (d) raw communication to _pexpect_ ; except for (d) which uses
raw byte strings, all other (RPC) communication uses a JSON-based format
Figure 4: Example _IPython_ startup script for _Mamba_

So the _Mamba_ backend provides a RPC service that supports command injection
with feedback; however, there are also communication requirements between the
backend and frontend that are unsuitable for command injection. A first
example is passwords which should not appear in clear text on the CLI because
of the command line history mechanism; additionally, many status queries
(_eg._ listing known motors and detectors) are only required by GUIs, and are
inessential for CLI-only use of _Mamba_ , so the appearance of relevant
commands on the CLI would be mostly useless to users. Therefore we also
provide _special RPCs_ for these requirements (Figure 3(a)); however because
RPCs need dedicated encapsulation code (RPC-specific syntax checks _etc_), we
have formed the policy that _special RPCs should usually not be added for
communication essential for CLI-only use_. Noticing the need for the frontend
to get status updates (Figure 3(c)) and the intrinsic weakness of polling
(polling too often wastes system resources, while polling too scarcely risks
loss of updates), in addition to a _request/reply socket_ (_ZeroMQ_ `REP`) for
regular RPCs, a _notification socket_ (_ZeroMQ_ `PUB`) is also provided by the
RPC service to proactively push updates to clients.

To further simplify our codebase, the finer details in _Mamba_ have also
undergone careful design, for which we give two examples. One is the
introduction of `ZError`, a subclass of Python’s `Exception`, that can be
raised by handlers in the RPC service to give fine-grained reports for errors
that have been anticipated by developers (_cf._ Figure 1 and 3(b)). The RPC
service will return information extracted from `ZError` to clients, instead of
the more generic information it will return upon other types of exceptions;
this way, RPC clients can set up exception handlers accordingly, and only use
a generic handler as a last resort. Another example is the use of variables
`M` and `D` to group motors and detectors respectively in the global scope of
_IPython_ (_cf._ Figure 1, 4 and 3(a)), just like how `RE` is recommended by
_Bluesky_ developers for the `RunEngine` instance in the same scope. We find
this much more natural as a way to mark the “movability” of devices than
alternatives, like passing two _ad hoc_ dictionaries as arguments to
`server_start` which has the disadvantage that the device lists cannot be
modified dynamically. We have even gone one step further and modified core
_ophyd_ code to allow device object names like `M.m1` that contain dots, so
that we can enforce a policy that _the name of a device object must be a
Python expression referencing exactly the same object_ , which has proven to
again save quite a lot of code.

##  3 Further plans on _Mamba_

After a quite extensive research on the eligibility of _Bluesky_ for the
applications at HEPS, we concluded that apart from the lack of GUI
integration, _Bluesky_ is able to cover most low-frequency low-throughput
(typically with $<10$ Hz communication between the computer and devices
involved, and data rates $<100$ MB/s) needs at HEPS, in both regular step-scan
experiments and certain preparation steps (_eg._ the automated arming of
samples, including the fine tuning of their positions; _cf._ also the
requirement from the B5 beamline at HEPS mentioned in Section 2).
Nevertheless, because HEPS is a 4th-generation synchrotron radiation facility,
its small X-ray spots and high brightness not only facilitates high-resolution
imaging, but also necessitates continuous scans (_fly scans_) to handle the
significantly larger number of data points and the much more serious radiation
damage of samples. So both high-frequency and high-throughput applications –
exactly where we find _Bluesky_ to be currently not very good at – are
essential to HEPS; if these weaknesses are somehow addressed, _Bluesky_ will
be able to provide a solid unified basis for beamline experiments at HEPS.

We begin with high-frequency applications, represented by fly scans; a typical
high-frequency (but low-throughput) application is sound recording, which we
compare fly scans to. When performing fly scans (sound recording), because
regular computers cannot handle the influx of data points at too high
frequencies, we instead use dedicated controllers (sound recorders) to do the
handling; the computer reads data from the controllers in a block-by-block
(instead of point-by-point) fashion, and other than that just sends control
messages like “start”, “stop” or “pause”. From the above we can see that _the
key to high-frequency applications is asynchronous control_ (indirectly with
dedicated controllers), which currently does not seem quite easy to do with
_Bluesky_ ’s `RunEngine`. In fact the latter already has primitive support for
simple fly scans which only need “start” (the `kickoff` operation in
`RunEngine`) and “stop” (the `complete` operation), where the data readout is
mainly done offline (the `collect` operation run after `complete`). At HEPS,
we are currently exploring an implementation of fly scans that allows _real-
time tuning of the scanning behaviours_ (adaptive speed/step-size tuning,
automatic pausing/resuming _etc_) based on online processing of the data read
from controllers. This might be of particular interest in requirements like
obtaining the optimal X-ray spot size and wavefront for focus alignment, as
well as enabling ultra-high stability of the sample and X-ray probe during
multi-dimensional scanning measurements at the hard X-ray nanoprobe beamline
(B2) at HEPS.

_Bluesky_ supports online data processing using Python packages from the
_SciPy_ ecosystem, but this is currently done through synchronous point-by-
point callbacks; similar to how point-by-point processing of sound data cannot
be done synchronously with regular computers, synchronous processing is
unsuitable for high-throughput applications. The solution is also similar –
use asynchronous processing instead; noticing the discussion in the previous
paragraph, we can see that the same asynchronous mechanism we envision also
covers the data-processing needs for high-frequency experiments naturally. To
address the complexity in both the asynchronous collaboration of worker
processes (buffering, polling/pushing, error handling _etc_ , plus the
resource management for processing of big data) and the diverse domain-
specific logics we need to support, we are developing what we call the _Mamba
Data Worker_ (_MDW_) framework, which will be to an extent like _HiDRA_
(Fischer et al., 2017) and _Odin_ (Yendell et al., 2017). However, instead of
focusing more on data producers, _MDW_ will treat producers and consumers
equally, also handling the diverse formating requirements of raw data from
beamline experiments at HEPS (Hu et al., 2021a). The same requirements are to
our knowledge not something actively pursued by _Bluesky_ ’s _databroker_ ,
aside from the problem we notice that _databroker_ is not performant enough
when there is heavy disk I/O on the same machine. Moreover, instead of mainly
supporting linear processing pipelines, _MDW_ will support _full-fledged
graphs of data pipes_ (Figure 5), perhaps implemented in cooperation with the
_Daisy_ project (Hu et al., 2021b); this is crucial for the real-time tuning
of fly scans, and will also be very helpful in complex multimodal experiments.

Figure 5: Partial data-pipe graph for a simple high-throughput tomography
experiment

As has also been discussed by Hu et al. (2021a), aside from the diverse needs
for processing of “real” data from experiments, the challenges posed by the
many types of experiments possible at HEPS also include the complexity in
management of the scientific metadata for these experiments, which will
directly affect the formatting of raw data by _MDW_. From the data producers’
side, for each type of experiment at a certain beamline, the number of
parameters intended to be tuned by users (especially typical users) are
usually much smaller than the total number of parameters for devices
accessible on the beamline. Therefore it is also necessary to extend _Bluesky_
’s `RunEngine` for each type of beamline experiments, so that users’ need to
care about irrelevant parameters are systematically minimised. Noticing the
strong correlation between the specification of scientific metadata, device
parameters and data-pipe graphs, we are designing an _experiment parameter
generator_ (EPG) mechanism. Given an _experiment schema_ , the EPG should
accept a minimised group of inputs; while the inputs are selected for typical
needs, the output should be in a form both customisable by advanced users and
friendly to automation mechanisms. In the same spirit of simplifying user
operations, we will also develop _Mamba_ modules to automate experiment-
specific preparation steps as are mentioned in the beginning of this section;
considering the small X-ray spots allowed at HEPS, this will help greatly in
reducing time costed by tasks like the the fine tuning of beams. We find that
“intelligent” techniques, _eg._ those based on statistical learning, are often
useful in these steps, and we believe the architecture of _Mamba_ will help to
incorporate these techniques into our workflow.

For both the backend and frontend of _Mamba_ , we fully realise the necessity
to reuse off-the-shelf code from open-source projects to avoid unnecessary
duplication of efforts in providing domain-specific abstractions. Integration
of code from projects, _eg._  _xrayutilities_ and _diffcalc_ (for _SPEC_ -like
access to crystallographic coordinates) on the backend side, as well as
_TomoPy_ and _PyFAI_ (for requirements in tomography) on the frontend side,
are already under investigation. We also realise the dominant status of
certain projects in specific fields, _eg._  _MXCuBE_ (Oscarsson et al., 2019)
in macromolecular crystallography, and will consider ways to provide a smooth
experience at HEPS to users familiar with these projects. We may reuse _Mamba_
components just enough to integrate the upstream project into the workflow at
HEPS, or conversely integrate upstream components into _Mamba_ , or even (if
preferable) reimplement functionalities in _Mamba_ and just emulate the GUIs
for them; the actual way will be chosen depending on the specific project, in
friendly cooperation with upstream developers, with the goal of minimising the
efforts on both sides in mind. We also note the necessity to support control
systems other than EPICS, which is certainly doable with _Bluesky_ but just
not a focus to its developers. This is imperative for high-throughput area
detectors which are non-trivial to support cleanly with the _areaDetector_
framework in EPICS, and we are working on direct _ophyd_ support for them with
_MDW_ integration. There may also be systematic demand for other devices
unsupported by EPICS that cannot be replaced with supported workalikes, which
has fortunately not yet been encountered by us.

To reduce the efforts necessary for implementation and integration of GUIs, we
are making what we call _Mamba GUI Studio_ (_MGS_) to provide reusable utility
widgets and allow drag-and-drop composition of high-level GUI components,
similar to what is done by Sobhani and Vescovo (2020). A feature commonly
requested for _Mamba_ is cross-platform use of its frontend, but we find it
really complex to expose its RPC service (especially the command injection
mechanism) to the network without harming security. For this reason, we only
allow the backend and frontend of _Mamba_ to run on the same host, but
meanwhile we plan to use the _xpra_ utility (Figure 6), with communication
secured with SSH, to provide access on remote computers with operating systems
supported by _xpra_. Since _xpra_ supports multiple coexisting “virtual
screens” and simultaneous access to one virtual screen by multiple clients,
users can additionally collaborate either using self-chosen groups of GUIs or
using GUI groups shared by others; proper coordination is obviously needed
between users, perhaps using walkie-talkies or some chat software, to avoid
conflicts between their operations.

Figure 6: _xpra_ provides “virtual screens”, each of which can be accessed by
multiple clients simultaneously

##  4 Conclusion

We are developing the _Bluesky_ -based _Mamba_ software framework for the
diverse experiment requirements at HEPS. We use command injection with
feedback to allow the CLI and GUIs of _Mamba_ to complement each other
constructively; considering certain functionalities unsuitable for command
injection, _Mamba_ provides a RPC service which also supports proactive
pushing of status updates. We take multiple measures to further simplify the
codebase of _Mamba_ , like the use of `ZError` to simplify error handling, and
the use of `M` and `D` to respectively group motors and detectors. We find
_Bluesky_ ’s weaknesses in high-frequency and high-throughput experiments to
be exactly where it lacks in requirements at HEPS, and plan to address the
former by improving _Bluesky_ ’s support for asynchronous control. To fully
address the complexity in data processing for high-throughput experiments, we
are developing _Mamba Data Worker_ , which will cover the entire process from
producers to consumers, as well as support full-fledged graphs of data pipes.
To simplify the specification of scientific metadata, device parameters and
data-pipe graphs, we will develop an experiment parameter generator; the
generation will be tailored systematically according to the experiment type,
and its output will be customisable yet machine-friendly. Experiment-specific
modules to automate preparation steps will be developed similarly. We are
investigating the integration of off-the-shelf code into _Mamba_ to provide
domain-specific functionalities, and are also developing _Mamba GUI Studio_ to
simplify the implementation and integration of GUIs. We plan to use a _xpra_
-based mechanism to allow cross-platform access to _Mamba_ , which will also
enable easy collaboration between users.

### Acknowledgements

This work was supported by the National Basic Research Program of China
(2017YFA0504900), the One-Hundred Talents Program of Chinese Academy of
Sciences (Y851552), the Strategic Priority Research Program of Chinese Academy
of Sciences (XDB37000000), the Specialised Program for Informatisation of
Chinese Academy of Sciences (CAS-WX2021PY-0106) and the National Science
Foundation for Young Scientists of China (Grant No. 12005253).

## References

  * Allan et al. (2019) Allan, D., Caswell, T., Campbell, S. and Rakitin, M., 2019\.  Bluesky’s ahead: A multi-facility collaboration for an a la carte software project for data acquisition and management.  _Synchrotron radiat. news_ , 32(3), pp.19–22.
  * Coutinho et al. (2011) Coutinho, T., Cuní, G., Fernández-Carreiras, D., Klora, J., Pascual-Izarra, C., Reszela, Z. and Suñé, R., 2011.  Sardana: The software for building scadas in scientific environments.  _Proceedings of the 13th international conference on accelerators and large experimental physics control systems (icalepcs2011)_. Grenoble, France, WEAAUST01, pp.607–609.
  * Fischer et al. (2017) Fischer, M., Gasthuber, M., Giesler, A., Hardt, M., Meyer, J., Prabhune, A., Rigoll, F., Schwarz, K. and Streit, A., 2017.  Advancing data management and analysis in different scientific disciplines.  _J. phys.: Conf. ser._ , 898, p.082026.
  * Gibbons, Heron and Rees (2011) Gibbons, E.P., Heron, M.T. and Rees, N.P., 2011.  Gda and epics: Working in unison for science driven data acquisition and control at diamond light source.  _Proceedings of the 13th international conference on accelerators and large experimental physics control systems (icalepcs2011)_. Grenoble, France, TUAAUST01, pp.529–532.
  * Hauf et al. (2019) Hauf, S., Heisen, B., Aplin, S., Beg, M., Bergemann, M., Bondar, V., Boukhelef, D., Danilevsky, C., Ehsan, W., Essenov, S., Fabbri, R., Flucke, G., Marsa, D.F., Göries, D., Giovanetti, G., Hickin, D., Jarosiewicz, T., Kamil, E., Khakhulin, D., Klimovskaia, A., Kluyver, T., Kirienko, Y., Kuhn, M., Maia, L., Mamchyk, D., Mariani, V., Mekinda, L., Michelat, T., Münnich, A., Padee, A., Parenti, A., Santos, H., Silenzi, A., Teichmann, M., Weger, K., Wiggins, J., Wrona, K., Xu, C., Youngman, C., Zhu, J., Fangohr, H. and Brockhauser, S., 2019\.  The karabo distributed control system.  _J. synchrotron rad._ , 26(5), pp.1448–1461.
  * Hu et al. (2021a) Hu, H., Qi, F.Z., Zhang, H.M., Tian, H.L. and Luo, Q., 2021a.  The design of a data management system at heps.  _J. synchrotron rad._ , 28(1), pp.169–171.
  * Hu et al. (2021b) Hu, Y., Li, L., Tian, H.L., Liu, Z.B., Huang, Q.L., Zhang, Y., Hu, H. and Qi, F.Z., 2021b.  Daisy: Data analysis integrated software system for x-ray experiments.  _Epj web conf._ , 251, p.04020.
  * Huotari et al. (2017) Huotari, S., Sahle, C.J., Henriquet, C., Al-Zein, A., Martel, K., Simonelli, L., Verbeni, R., Gonzalez, H., Lagier, M.C., Ponchut, C., Sala, M.M., Krisch, M. and Monaco, G., 2017.  A large-solid-angle x-ray raman scattering spectrometer at id20 of the european synchrotron radiation facility.  _J. synchrotron rad._ , 24(2), pp.521–530.
  * Jiao et al. (2018) Jiao, Y., Xu, G., Cui, X.H., Duan, Z., Guo, Y.Y., He, P., Ji, D.H., Li, J.Y., Li, X.Y., Meng, C., Peng, Y.M., Tian, S.K., Wang, J.Q., Wang, N., Wei, Y.Y., Xu, H.S., Yan, F., Yu, C.H., Zhao, Y.L. and Qin, Q., 2018.  The heps project.  _J. synchrotron rad._ , 25(6), pp.1611–1618.
  * Oscarsson et al. (2019) Oscarsson, M., Beteva, A., Flot, D., Gordon, E., Guijarro, M., Leonard, G., McSweeney, S., Monaco, S., Mueller-Dieckmann, C., Nanao, M., Nurizzo, D., Popov, A., Stetten, D. von, Svensson, O., Rey-Bakaikoa, V., Chado, I., Chavas, L., Gadea, L., Gourhant, P., Isabet, T., Legrand, P., Savko, M., Sirigu, S., Shepard, W., Thompson, A., Mueller, U., Nan, J., Eguiraun, M., Bolmsten, F., Nardella, A., Milàn-Otero, A., Thunnissen, M., Hellmig, M., Kastner, A., Schmuckermaier, L., Gerlach, M., Feiler, C., Weiss, M.S., Bowler, M.W., Gobbo, A., Papp, G., Sinoir, J., McCarthy, A., Karpics, I., Nikolova, M., Bourenkov, G., Schneider, T., Andreu, J., Cuní, G., Juanhuix, J., Boer, R., Fogh, R., Keller, P., Flensburg, C., Paciorek, W., Vonrhein, C., Bricogne, G. and Sanctis, D. de, 2019\.  Mxcube2: the dawn of mxcube collaboration.  _J. synchrotron rad._ , 26(2), pp.393–405.
  * Slepicka et al. (2015) Slepicka, H.H., Canova, H.F., Beniz, D.B. and Piton, J.R., 2015\.  Py4syn: Python for synchrotrons.  _J. synchrotron rad._ , 22(5), pp.1182–1189.
  * Sobhani and Vescovo (2020) Sobhani, B.A. and Vescovo, E., 2020\.  Drag and drop creation of bluesky guis.  _Fall 2020 epics collaboration meeting_. Online.  Available from: https://indico.fhi-berlin.mpg.de/event/52/contributions/579/.
  * Yendell et al. (2017) Yendell, G., Pedersen, U., Tartoni, N., Williams, S., Nicholls, T. and Greer, A., 2017\.  Odin – a control and data acquisition framework for excalibur 1m and 3m detectors.  _Proceedings of the 16th international conference on accelerators and large experimental physics control systems (icalepcs2017)_. Barcelona, Spain, TUPHA212, pp.966–969.