Project

General

Profile

PC 180112 MAUSRun etc » History » Version 9

Rogers, Chris, 18 January 2012 14:08

1 1 Rogers, Chris
h1. PC 180112 MAUSRun etc
2 2 Rogers, Chris
3 6 Rogers, Chris
Globals handling:
4 1 Rogers, Chris
5 9 Rogers, Chris
Full specification document can be found attached to #839
6 8 Rogers, Chris
7 6 Rogers, Chris
Issue 1:
8
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?
9
10
Issue 2:
11 7 Rogers, Chris
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:
12 6 Rogers, Chris
* Calibrations
13
* Cabling
14
* Fields
15
* Geometries
16
17
Issue 3:
18
We would like to write out some data every code execution and some data every run.
19 1 Rogers, Chris
20 7 Rogers, Chris
Subtlety 1:
21
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.
22
23
Solution:
24
Propose splitting the old MICERun into two different objects 
25
* MAUSProcess that contains all of the data that needs to exist for the duration of the process - such as configuration datacards, etc
26
* MAUSRun that contains all of the data that needs to exist for the duration of the run - such as calibrations, cabling, etc
27
We make an interface MAUSPerRunData that contains a single virtual method Update()
28
* MAUSRun contains a list of MAUSPerRunData and loops over them each time it detects a new run, calling Update() method on each MAUSPerRunData item
29
* Getters and Setters access the specific MAUSPerRunData objects for e.g. a TOF calibration. 
30
31 1 Rogers, Chris
!class_structure_globals.png!
32 7 Rogers, Chris
33
Propose also two objects to handle the IO
34
* MAUSJobIO
35
* MAUSRunIO
36 8 Rogers, Chris
37 7 Rogers, Chris
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.
38
39
!class_structure_io.png!
40
!data_structure.png!