SWAN for machine studies

R. De Maria, Michi Hostettler, Guido Sterbini



pytimber wraps the accellent CALS (Cern Accelerator Logging Service) Java API to extract any machine measurements available in the Logging database.

  • uses jpype to instantiate a JVM and execute Java Code
  • uses cmmnbuild-dep-manager (T. Levens et al.) to resolve the Java dependencies of CALS (and other CO libraries) and instantiate Jpype
  • several examples are in the swan gallery: https://swan.web.cern.ch/content/accelerator-complex
  • can be also used outside SWAN (pip install pytimber) but needs to be used within the CERN network

pytimber: simple use

In [1]:
import pytimber
data=db.get([atlas],'2018-09-10 4:00:00','2018-09-10 18:00:00')
In [2]:
%matplotlib notebook
import matplotlib.pyplot as plt

plt.ylabel("Collision per second")

pytimber: status and plans

  • pytimber is maintained by the users community
  • since pytimber is now part of many software stacks, implementing a simplified access to NXCALS is a possible options for users that need same pytimber API.
  • planned to migrate to jpype-0.7

...not all useful information for machine studies are stored in CALS...


pjsla is a wrapper of the LSA LHC Software Architecure library and it is used controls the LHC and other machine. Nornally operates in the technical network, but a read-only proxy is available in the from the GPN and therefore Swan.

  • It can be used to extract LHC high level settings
  • It use the same cmmnbuild-dep-manager as pytimber for Java dependencies management
  • can be also used outside SWAN (pip install pjlsa) but needs to be used within the CERN network

pjlsa: simple use

In [3]:
import pjlsa
WARNING:cmmnbuild_dep_manager:JVM is already started
In [4]:
print("Timestamp                   segment       values")
for tts, dd in zip(ts,data):
    print(pytimber.dumpdate(tts),dd[0], dd[1])
Timestamp                   segment       values
2018-03-11 18:57:47.717 [  0. 120.] [150. 150.]
2018-03-18 21:06:40.438 [  0. 120.] [160. 160.]

pjlsa: status

  • pjlsa is a still in early developlemnt stage, but already useful
  • API is far from being stable
  • a major rewrite is in the process to provide a more consistent handling of the (many) internal Java objects
  • the user API will be updated to fit also the needs of the LHC injectors

...we have seen a value of the crossing angle, how can we plot beam trajectories...


cpymad(https://github.com/hibtc/cpymad) is a wrapper of the MAD-X(https://cern.ch/mad) software which allow to perform beam dynamics simulation. MAD-X is written in C and it has a rich (but still limited) scripting abilities. Integration in Python fills the gap for more complex interaction.

  • cpymad use cython to access the internal data structure and function in MAD-X
  • python visible mehotds are exposed in the module libmadx
  • a high class Madx spawns a sub process instantiating libmadx and comunicate with libmadx through an ad-hoc RPC class
  • can be also used outside SWAN (pip install cpymad) and outside CERN
  • MAD-X files for LHC data can be found in /eos/project/a/abpdata/lhc/optics, but soon a new repository /eos/project/a/acc-model/ will contain all information

cpymad: basic uses

In [3]:
from cpymad.madx import Madx
madx = Madx(stdout=False) # start MAD-X
#Load models
madx.options.echo=False; madx.options.warn=False

# Set energy in GeV
# Set crossing angle
on_x1=150 # same as LHCBEAM/IP5-XING-H-MURAD

In [4]:
plt.plot(s1,x1,label="Beam 1")
plt.plot(s2,x2,label="Beam 1")
plt.xlabel('s [m]')
plt.ylabel('x [m]');

cpymad: status

cpymad is actively maintained by T. Glassle and a new community at CERN is assembling at CERN

  • many MAD-X wrappers exists, but cpymad is most consistent and comprhensive python API
  • still not ufficial supported by CERN but well seen by MAD-X developers


  • SWAN has served remarkably well in serving software for machine studies
  • It contributed to sharing knownledge and forming strong users communities


  • The container lifetime is sometimes too short. It would be great if the container state could be saved and resumed.
  • We would happy to see a better integration with LXBATCH and acrontab service
  • We need to use sshfs to access some data sources in technical network (under NFS(. Transfering data to EOS is not a pratical option.
  • Integration with EOS is great, using EOS as storage is immensely useful, at the same time:
    • Using EOS as home directory is a strong limitation, since libraries interacting with filesystems do not run reliably:
      • last bug leading to data corruption, discovered and fixed last month,
      • interacting with git repositories stll problematic.
    • /scratch/<user> is a mitigation, but it is volatile and cannot be used to install additional software.
    • I wish to have a non volatile home directory based on a reliable filesystem for configuration, simulation I/O, compilation and use EOS to get and store results
  • We also have useful data in AFS...