Root I/O

TBIOROOT works for testbeam Root files (both raw Event data and recon data).

We need Root I/O for both the PDR and the balloon.

Short-term:
Keep TBIOROOT as is.
Add in some code to handle MC and ACD recon
This would be our fall back position, in case no other alternatives present themselves.

Problems:
Discourages update of the Root classes - though it is possible.
Code is not well understood and not maintainable.

Possible list of tasks:

What if we do not have any other mechanism for Root I/O in time for PDR & balloon?  Then any updates we make to the Root classes will ripple into TBIOROOT.  We could live with this..though it will be rather painful...  If we go down this path...I would strongly suggest making one update to the raw and recon classes...updating TBIOROOT and then freeze.  That would be it until we are finished with the PDR & balloon.

New Hope:
The Brookhaven team within Atlas has developed a RootSvc for Gaudi.  This is their first attempt at bridging the gap between providing generic Root I/O and maintaining the class structure within the Root files.

How do they do it?  Their RootSvc uses Root's TDataSet abstract class to generically handle the Root I/O.  Currently, their data is stored within TTables (derived from TDataSet)...looks like a flat structure..where each event has elements:  floats, ints, arrays, etc - similar in concept to TNtuple except that we are not restricted to floats. 

Valerie tells me that Star also uses TObjectSet (also derived from TDataSet) for their "regular" classes...but that the I/O is not generic...  They are currently looking into the possibility of storing pointers to TObjects within the TTables.  But this is just getting underway...    Plus we would have to modify our own Root classes to use TObjectSet...or TTable...  

For now we may be just as well off to develop a light RootSvc of our own with specific converters to handle our data...digiRootData, reconRootData, mcRootData

Problems:
This is relatively "new" code..and is still under development.
We will have to adapt the current converters for our own use.
There are some Root (3.00.06) specific fixes within their code...Valeri recommends upgrading to Root 3.01

We will not have a completely suitable solution for Root I/O in time for the PDR & balloon..  We can have something in place, that will be understandable and maintainable..but it may be an intermediate step until we can take advantage of progress within Atlas - and our own experience with their RootSvc.