Overview of MAUS Structure¶

Here the aims and overall structure of the MAUS software are described.

Aims of MAUS software¶

The MAUS software team aims to provide to the MICE collaboration

• Tracking simulation of MICE
  • At arbitrary level of detail
  • Model fields and detectors
  • Implementation of MICE CAD geometry only
• Electronics model of MICE detectors
• Space point reconstruction
• Track reconstruction
  • Track fitting
  • Particle identification
  • Capable of working with any subset of detectors
  • Online and offline
• Physics analysis tools
  • Extraction of accelerator physics parameters of interest from beam data (emittance, Twiss parameters, probably some more stuff)
  • Statistical manipulations (weighting, cuts, particle selection)
  • Transport mapping
  • Online and offline
• Fast simulation of MICE (transport matrices)
  • Envelope pushing
  • Response matrix calculation
  • Online optimisation
  • Online and offline
• Data quality check
  • Histogramming of DAQ output
  • Scalars output
  • Online and offline
• User Documentation for the above
• QA process for the above

Caveats¶

Some caveats apply:

• Calibration application(s) are not the responsibility of MAUS team
• We implement the geometry from CAD, we check that we implement what's meant (i.e. correct materials etc). But not our job to know what the physical MICE geometry is in the hall.

Data Flow¶

Following represents the flow of data through the MAUS software:

Bigger: software_workflow.png

• Items in blue are owned by MAUS team
• Items in orange are MICE software owned elsewhere

Core structure¶

Core

Work packages¶

The software is split into several subpackages

• Simulation: simulation subpackage is where we run Monte Carlo simulations of the accelerator and detectors - pushing particles through electromagnetic fields, depositing energy on detectors, etc.
• Digitization: digitization subpackage is where we model response of the detectors to energy deposition to make digits from Monte Carlo - modelling photon yield from energy deposition, electron production in photomultiplier tubes, etc.
• Data: data subpackage is where we interface with the experimental DAQ system to make digits from real data
• Reconstruction: reconstruction subpackage is where we perform pattern recognition on the detector digits to make space points and tracks
• Online reconstruction: online reconstruction package is responsible for pulling data from the spill and using it to make diagnostic histograms
• Event display: event display is responsible for visualising detector space points and tracks from reconstructed hits.
• Beam optics: optics package is responsible for pushing beam envelopes through MICE electromagnetic fields
• Physics analysis: we provide a package, XBOA, for doing accelerator physics analysis. This is actually completely independent of MAUS, but maintained by MAUS crew. Might be more closely integrated later.

Input - Map - Reduce Framework¶

The fundamental datum in MAUS is the spill. The spill datastructure represents the data produced by a several-millisecond dip of the target into the ISIS beam. MAUS treats each spill as an independent event. There are three APIs for the spill

• input produces new spill data
• map takes a spill datum, modifies it in some way and returns another spill.
• reduce takes a spill datum and adds it to the reduce object

So input produces data (e.g. monte carlo primaries, DAQ data), map modifies it (e.g. producing tracks from space points) and reduce consumes data (e.g. producing histograms). The API is not sufficient for what we want to do - some things, most notably the Event Viewer, want to work in a different way (e.g. interrogating the data tree, picking a spill and visualising it). It's fine for some packages to define their own API if they really need to. But we try to keep things using this API to make the thing manageable.