SoftwareHints » History » Revision 11

« Previous | Revision 11/17 (diff) | Next »
Dobbs, Adam, 12 November 2013 14:48

Software Hints and Tips

Running a tracker simulation

There is a dedicated directory holding top level scripts for producing tracker data within MAUS at:


For example to run a MAUS simulation of the tracker in the presence of a magnetic field (helical tracks) do the following from the MAUS root directory:

cd bin/user/scifi
./ --configuration_file datacard_mc_helical

The equivalent command for no magnetic field (straight tracks) is:

./ --configuration_file datacard_mc_straight

Datacard variables

Datacard variables control the various parameters passed to MAUS. The variables assume the default values set in src/common_py/ unless overridden in a datacard or elsewhere. Here are a few common variables:

  • Number of spills. The number of spills to simulate can be set by editing the relevant datacard file and changing the variable 'spill_generator_number_of_spills'.
  • The number of particles per spill is controlled by the beam variable. This has a number of sub-variables, two of which can be set to alter the number of particles per spill:
    • 'binomial_n' is the number of attempts at generating a track
    • 'binomial_p' is the probability an attempt succeeds
  • Helical pattern recognition can be turned on or off by setting 'SciFiHelicalPROn' to 1 or 0 respectively
  • Straight pattern recognition can be turned on or off by setting 'SciFiStraightPROn' to 1 or 0 respectively

Accessing the output data

Data is output by MAUS either as ROOT or JSON documents. An example ROOT script for accessing the data is available here

In order for ROOT to understand the classes we have written, a ROOT dictionary, built automatically by MAUS, must first be loaded. In an interactive ROOT session this done with following command:

.L $MAUS_ROOT_DIR/build/

The equivalent command if using PyROOT is

import libMausCpp

An example ROOT session to open a data file would be:

> .L $MAUS_ROOT_DIR/build/
> TFile f1("maus_output.root")
> TBrowser b

The equivalent PyROOT session would be:

>>> from ROOT import *
>>> import libMausCpp
>>> f1 = TFile("maus_output.root")
>>> b = TBrowser()

The tracker MC data can then be found by browsing to:


The reconstructed data is stored under:


An example PyROOT session to access some data:

>>> from ROOT import *
>>> import libMausCpp
>>> f1 = TFile("maus_output.root")
>>> t1 = f1.Get("Spill")
>>> t1
<ROOT.TTree object ("Spill") at 0x8bfa970>
>>> data = MAUS.Data()
>>> t1.SetBranchAddress("data", data)
>>> t1.GetEntry(1)
>>> spill = data.GetSpill()
>>> spill
<ROOT.MAUS::Spill object at 0x92f4a40>
>>> spill.GetReconEvents().size()
>>> revt = spill.GetReconEvents()[0]
>>> sfevt = revt.GetSciFiEvent()
>>> htrks = sfevt.helicalprtracks()
>>> htrks.size()
>>> seeds = htrks[0].get_spacepoints()
>>> seeds.size()
>>> sp = seeds[0]
>>> sp.get_position().x()

Running the tests

All branches should pass the testing framework before being pushed up to launchpad. The full set of tests can be run with:


This can take quite a while to run however. Running smaller sections of the tests first will generally save you time. Two common places where test errors creep in are in cpp style and python style checks. The cpp style test can be run on its own with:

python tests/style/

The python style test can be run with:

python tests/style/

The unit tests (which include the cpp style check but not the python style check) can be run with:


An individual cpp unit test module can also be run. For example, to run just the Pattern Recognition unit tests:

build/test_cpp_unit --gtest_filter=PatternRecogntionTest.*

Once these all pass, make sure you run full test suite before pushing to launchpad if you have made any significant code changes.

The MAUS documentation for unit tests can be found on the MAUS wiki.

Updated by Dobbs, Adam over 10 years ago · 11 revisions