Hi all, Here at NBI, we've made an effort to provide a easy way to access data from GEANT, but also from the event stream (EVB or DISK). This led me to think of putting the data into ROOT TTrees, since these provide many fancy/nice features. However, this turns out not to be completly trivial. For one, the current data structure, as in BrEvent, is not well suited to write to a ROOT tree. This has to do with the allowed nesting level in a ROOT tree (see my recent mail to roottalk on the ROOT Web pages). In particular, it's allowed to have TObjArrays containg TObjArrays containing TObjArrays, etc. This is fine, if you plan to write down each BrEvent to disk (1 run ~= 1000 event => 1000 BrEvents/run!), which however becomes a hassle in the analysis step. With TTrees, you'd have one TTree "Event", with some (small) number of super- and sub- TBranches. One way to do the actual convertion from GEANT/RAW data, is to go through the normal alogorithm, using BrGEantInput/BrRawInput and BrEvent, and then convert the BrEvent to a TTree. However, I feel this is a bit clumbersome. I'd prefer to overload the methods BrGeantInput::Event and BrRawInput::Event, to take a pointer to a BrEventTree object, and then write the data to that object directly. Further, I belive, that digitization and reconstruction will be much faster using TTrees, than the current nested list of TObjArrays. 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? On BrRawInput: On looking throught the code for BrRawInput::Event and related methods, I discovered a disturbingly _large_ amount of inconsitencies. Table names etc, follow no apperant scheme, and are on top of that hard-coded into the methods. Why not have some scheme, where the detector names are common to BrGeantInput and BrRawInput and GBrahms i.e., via #define in a header file or similar, and some flag telling what kind of data this is (RAW/GEANT/...). Also, the IMHO BrRawInput::Decode... methods are far too large. For each detector, there should exist a method e.g., for H1, there should be the method BrRawInput::DecodeH1. This is a rather trivial change, and could proberly be done in a matter of hours. I you think it's OK, I can do it at some point. Anyway, that's my two pennies worth. What do you think? Cheers, Christian ----------------------------------------------------------- Holm Christensen Phone: (+45) 35 35 96 91 Sankt Hansgade 23, 1. th. Office: (+45) 353 25 305 DK-2200 Copenhagen N Web: www.nbi.dk/~cholm Denmark Email: cholm@nbi.dk
This archive was generated by hypermail 2b29 : Thu Mar 09 2000 - 10:38:37 EST