Accessing ACD data

Some general comments: 

• Use the same data structure as input to AcdRecon no matter where the data originates from.  (aka Toby principle #1)

• The objects that AcdRecon actually manipulates may or may not be TdVetoData objects...could convert from TdVetoData into some other form if deemed necessary.

• The AcdRecon will not be manipulating digis directly...but there should be a mechanism to "convert" AcdDigis into a list of TileIds, energies, etc..

• An AcdRecon package does not yet exist...but a true Gaudi algorithm can be easily derived from the existing VetoRecon.

• Output from AcdRecon must be added to the Recon Root file.

• TBIOROOT does not currently handle ACD data.

• Any converter that can handle the Root based ACD data (TBEM & BFEM), must obtain geometry information from somewhere...

• Handling IRF data (conversion into TdVetoData) will take care of ACD needs for the PDR...I believe.  Will have to provide updated PRS file for PDR geometry.

Possible Paths from Raw Root files into TdVetoData

Carry on with TBIOROOT

Create rTreeRawAcdAlg within the new (see Ian's slides) TBIOROOT.

Does this rTreeRawAcdAlg fill TdVetoData directly?  Remember..raw root files contain digi data...would have to provide conversion from PHA->energy

Need to provide Geometry information for both TBEM and BFEM ACD configurations....how does that happen?

• Read in the instrument.xml file for either TBEM or BFEM     configuration.
• Then calculate the position of the ACD tiles?

Bravely go...

Load the ACD GlastDetector objects with "raw" ACD data from the Root file.

This provides access to all of the geometry information available in the PRS file...but this requires a mapping from ACD ids in Raw Root to ids in the PRS file.

One still has to provide a conversion for the raw "digi" ACD data into the non-digi GlastDetector object.

Then once AcdRecon has done its job...the output must be stored in the Recon Root file...So there should be an input for ACD in the rTreeReconAlg... right?