Page History

Diagram of Proposed CalRecon TDS Architecture

Prototype of CalParams Class

• Contains the basic energy reconstruction parameters

  No Format
  $USHERNFS/MemLeak

  where USHERNFS is /nfs/slac/g/glast/users/glground/usher

• ... can be found here

Prototype Definition of the CalParams Class

• Prototype class found here
• Intended to provide a single interface to all the basic energy reconstruction parameters:
  • Energy
  • The reconstructed energy centroid (cluster position)
  • The axis of the energy flow (cluster axis)
  • And the errors assigned to these
    • For energy: a number
    • For centroid and axis: two 3x3 error matrices
• Is a subclass of the main recon output classes

Prototype Definition of the CalCluster Class

• Prototype class found here
• This replaces the current CalCluster class, splitting out the corrected energy information that was formerly contained in CalCluster
• Otherwise, basically a reformatting of what was there:
  • The layer by layer information formerly stored in three std::vectors is now replaced by a subclass (CalClusterLayerData). CalCluster now derives from a std::vector of these objects making them directly accessible externally without having to provide access methods
    • Example:

      No Format
      CalClusterLayerData lyrData = calCluster[layer];

  • The energy, cluster centroid and cluster axis information is stored in an internal CalParams object.
    • Now includes errors on these quantities
    • But not yet filled with "real" values
• New things include:
  • CalCluster is a "ContainedObject"
    • typedef's are provided to defined the TDS Object container (CalClusterCol) which will store the clusters in the TDS
  • A relational table will relate CalClusters to the CalXtalRecObjects which comprise them
    • typedef's are provided to define this table
• A comment on the layer by layer data
  • Attempted to preserve the "old" system of an entry for each layer in the Cal, whether data existed or not. Unfortunately, one downside is the need to #define a default value of 8 so the constructor will be sure to create a vector of size 8 for the CalClusterLayerData objects...
  • A possible future solution would be to include a Cal identifier in the CalClusterLayerData object and then only keep non-zero entries
  • Other possibilities?
• Something forgotten: a status bit word...

Prototype Definition of the CalCorToolResult Class

• Prototype class found here
• DISCLAIMER: bare bones version, no attempt yet to add mechanism for storing correction tool dependent information
• CalCorToolResult will store the output of any given energy correction tool that runs during event reconstruction
  • There will be one CalCorToolResult output for each correction tool run (they will be stored in CalEventEnergy, see below)
• Vary basic minimum output includes:
  • CalParams to give energy, position, direction and errors
  • "ChiSquare" to give some measure of the "goodness" of the correction
  • A status bit word to describe:
    • The correction tool which provided this output
    • Other useful things that we will think of...
• CalCorToolResult is a Gaudi "ContainedObject" and typedef's are provided to define the container to hold the collection of them.
• typedef's are also provided to define a the table which will relate each CalCorToolResult to the cluster(s) from which the result was derived.

Prototype Definition of the CalEventEnergy Class

• Prototype class found here
• CalEventEnergy is the "final" output of the Calorimeter energy reconstruction.
• The basic makeup of the class:
  • The class derives from an ObjectVector of CalCorToolResult objects, thereby acting as their "Gaudi Container" for the TDS.
    • Note that this introduces some interesting problems which cause a couple of issues with ownership and deletion, etc.
      • Just need to be aware of this
  • The class contains a CalParams object to contain the "final" corrected energy for use outside CalRecon
    • It is envisaged that the CalEnergyAlg which creates CalEventEnergy will provide a mechanism (via a Tool or something) which will select the "best" energy solution amongst those returned by the various correction tools
  • A status bit word which can
    • Keep track of what stage of recon the contained output came from
    • Identify which correction tool provided the "final" energy
    • etc.

Status as of May 4, 2005

• Above classes implemented with necessary modifications made to:
  • CalRecon v5r24p1
    • Note: this is already several revisions behind the current CalRecon tag so the modifications made to CalRecon for this demonstration most likely cannot be checked into cvs
  • Event v10r3p1
  • HepRepSvc v0r13
  • RootIO v14r7
    • No attempt made to make PDS versions, just mods to reconRootWrigerAlg and reconRootReaderAlg to compile and run
  • TkrRecon v10r3p10
• Add one new Algorithm to CalRecon:
  • CalEnergyAlg
    • This assumes responsibility for driving the energy correction tools
    • Provides user definable correcton tool result selection for the "final" answer
• Add one new Tool to CalRecon
  • CalRawEnergyTool
    • Runs at the end of the first pass iteration of energy recon and serves to sum the energy over all available clusters and re-calculate a "grand" cluster centroid and axis
    • Serves as the "super" cluster result
• Modify the job options flow:

  No Format
  Reconstruction.Members={ "Sequencer/Cal1", "Sequencer/Tkr", "Sequencer/Cal2", "Sequencer/TkrIter", "Sequencer/Acd" }; Cal1.Members = { "CalXtalRecAlg", "CalClustersAlg/first", "CalEnergyAlg/RawEnergy" }; Tkr.Members = { "TkrReconAlg/FirstPass" }; Cal2.Members = { "CalEnergyAlg/second" }; TkrIter.Members = { "TkrReconAlg/Iteration" };

  • Assumes clustering only need be called in the first pass recon
  • Sets up call to CalEnergyAlg which will run only the CalRawEnergyTool in the first pass
  • Sets up call to CalEnergyAlg in the second pass which will call all remaining correction tools
• The above structure appears to work in test Gleam jobs (10k 100 MeV gammas and 10k 1 GeV muons). So... on the right track?Use this space to store the top level job options file for controlling the job (I still rely on the basicOptions file as much as possible)