Analysis Framework

Provisional Outline

From a meeting of Matt, Anne-Marie, Jamie and Paul on 8/1/2007: MAPS Data Analysis Meeting 8/1/2007

Paul, Anne-Marie, Matt, Jamie

Book keeping etc

  • Web accessible table of runs from beam test and elsewhere
  • Wiki providing a place for all to post comments on a per-run basis
  • Forum for other discussions?

Analysis

Need a data format that allows us to do physics analysis rather than DAQ investigations. We would prefer to work in a sensible "world space", where each sensor/pixel in the analysis knows its physical location, type, etc.

Need to integrate book keeping information such as:

  • Geometry (which sensor is where)
  • Alignment (x, y, z)
  • Noisy channel lists/mask information (i.e. for software correction of noisy channels)
  • Experiment information

We envisage a conversion of the binary files to a more tractable format for analysis: Options include,

  • LCIO:
    advantages
    already suitable for CALICE beam test; includes serialisation of objects
    disadvantages
    not very flexible
  • Homegrown:
    advantages
    complete flebibility
    disadvantages
    potentially time-consuming; requires expertise in serialisation
  • ROOT:
    advantages
    tree structure is generic; serialisation provided for classes that extend TObject; may prove convenient for analysis
    disadvantages
    somewhat obscure, variably documented and buggy API
Notes
  • All suffer from potential file-size explosion and a need to refactor the design once we come to do analysis.
  • Backwards compatibility will not be assumed.
  • Files will be batch generated when the format changes.

We have selected ROOT with TTrees, TFiles etc.

Likely structure of file

* Run |-> Configuration |-> ... |-> ... |-> Configuration |-> Bunch train |-> ... |-> ... |-> ... |-> Bunch train |-> Bunch crossing |-> Real hits |-> Hit |-> ... |-> Sim hits |-> Hit |-> ... |-> Pmt hits |-> Hit

Notes:

  • The idea behind the different types of hit is to ensure we can compare data and Monte Carlo directly.
  • A configuration is a physical configuration, not a DAQ run configuration. (Consider, for example a mpsBeamThresholdScan, where the configurations are repeated on a loop. One would therefore lop all bunch trains recorded under the same physical conditions under the same configuration.)
  • Temperature readings will be added on the configuration level, between bunch trains.

Work/deliverables

Immediate tasks (for January):

1. Wiki/web setup Presumably this is looking quite appropriate!

2. Develop a tool to collect run information and post into HTML tables Jamie to start on this.

3. Start design of data format Matt to start on this.

Medium term (1 month):

4. Design analysis framework (do we want processors?)

-- JamieBallin - 10 Jan 2008

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r2 - 2008-01-11 - JamieBallin
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CALICE All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback