PC 180112 MAUSRun etc¶

Globals handling:

Full specification document can be found attached to #839

Issue 1:
In e.g. Geant4 setup, I need access to a whole load of configuration information in quite low level classes. For example, I need access to MiceModules in order to set up the G4 geometry. At the moment this "global" type information is stored in the MICERun. Initialisation is left up to individual developers (e.g. simulation initialises it's own MiceModules and puts them on the MICERun). That's okay but a bit hacky - what if more than one user wants to access this configuration information?

Issue 2:
Some stuff needs to be set up per run, some stuff needs to be set up per code execution. e.g. MiceModules needs to be reinitialised every run because the magnet currents may change from one run to the next. Need a way to handle run reinitialisation (e.g. for online running). Ideally, we don't really want to reinitialise the whole code as this can be slow. Other things in this list are:

• Calibrations
• Cabling
• Fields
• Geometries

Issue 3:
We would like to write out some data every code execution and some data every run.

Subtlety 1:
The subtlety is that some of this stuff wants to happen in the child node. After initialisation, the child node only knows about spill data. So we have to set up a way to inspect the spill data, determine what run it is and reinitialise any per-run data like calibrations and cabling.

Solution:
Propose splitting the old MICERun into two different objects

• MAUSProcess that contains all of the data that needs to exist for the duration of the process - such as configuration datacards, etc
• MAUSRun that contains all of the data that needs to exist for the duration of the run - such as calibrations, cabling, etc
  We make an interface MAUSPerRunData that contains a single virtual method Update()
• MAUSRun contains a list of MAUSPerRunData and loops over them each time it detects a new run, calling Update() method on each MAUSPerRunData item
• Getters and Setters access the specific MAUSPerRunData objects for e.g. a TOF calibration.

Propose also two objects to handle the IO

• MAUSJobIO
• MAUSRunIO

These things have to exist on Go.py because they need to append to the data structure at the top level (before it is divided up into Spills). So in fact in the end these things are independent of the MAUSProcess and MAUSRun.