I will not attempt to comments on all the aspects of Christians /Kris recent e-mail, but limit to a few. Some of the reasons for the present implementation of events were the following. o We wanted a general structure since it is very difficult apriori to know what kind of datatables, dataobjects (or clonesarrays) that one wants to store. The needs can also be different at different stages of analysis and life cycle of the experiment. o A tree structure is definetely needed- it allows different parts to exists in different files e,g -- digitized one file (input) -- local tracks, hits,... (first output) -- spectrometer tracks ,pid (analysis) o We also wanted to be able to write this in a way thawould be usable should the Root IO for some reasons not survive for long time. This is probably not a concern today - though one has to carafully watch that in two three years from now we can still read older files. (issue on classes, schema evolution). E.g. Phenix uses root but wrote the persistent part as far I know using STL classes and non based root io thus being in complete control. o It should be possible as you go through analysis by Usermodule to add new information like tables of a given kind ONLY knowing a event or eventnode and refering by its name. o I believe that IF/ WHEN root supports such a dynamic tree structure, which to my knowledge it does not, it would make a lot of sense as Christian proposes to use root tree to a deeper level to simplify analysis. I think we should look carefully into what is really possible within ROOT, and think that particular for the later stages of analysis (following reconstruction) much could be gained by this. I also recollect that the major reason we use the (simple) tree for output is that the serial output of the TObjArrays will not work well with ROOT since it generates a key per events,- those are all kept in memeory and the writting time increased dramatically with number of eventts analysed. "Further, I belive, that digitization and reconstruction will be much faster using TTrees, than the current nested list of TObjArrays. " This is not correct most time is spend doing lost of other stuff. The gain in having Tree's would be that users interactive analysis would be much faster - not the production runs of digi, reco, pid, etc. " On BrEvent and BrEventNode: (this is for Flemming and Kris mostly I think) Why does the BrEvent::Streamer and BrEventNode::Streamer convert the internal TObjArray into a THashTable before writting to disk? TObjArray and THashTable are in different inheritance brances (blood lines) of TCollection, doesn't this pose a problem? " If you look carefully you will notice that this is in fact commented out. It is a Kris a left-over from some code way back. It though has a certain idea behind it, namely the following. When you deal with an EventNode one should be able to defined if a 'subtree' is persistent for a given write and written to disk. E.G. imagine an reconstruction pass that can generate many kinds of objects TPC local tracking --- CLustere -- HitClusters -- DetectorHits -- Local tracks During the development and for selected analysis you might save all information to the outputfiles, while later during routine production you would drop these. The reason for doing it at the 'output' stage could be to have the information avaliable for several modules. I do agree the commented code is not the right implementation, but is not urgent at this point. On the BrRawDataInput I think some of the issue is a matter of style if methods are too large. Though I do not think one should spend much time of fixing style in this area - if it aint' broke don't fixe it. The naming issue is relevant and we should fix it now. The naming is meant to be the following For DataTables the name is "<ClassName><space><DetectorName>" where the ClassName is omitting the Br (try to a=evaluate how many Gb you save over a year that way. It is unique in so far it describes the dataobjects in the table. -------------------------------------------------------- Flemming Videbaek Physics Department Brookhaven national Lab tlf: 516-344-4106 fax: 516-344-1334 email: videbaek@bnl.gov
This archive was generated by hypermail 2b29 : Thu Mar 09 2000 - 17:22:14 EST