Hi Christian (and all) The BrEvent you are talking about was purposely designed as a general way to handle BRAHMS data at all of the intermediate stages. That is how we came upon the idea of the EventNode which can in turn have lists of data elements as well as other event nodes (they all inherit from BrDataObject). In fact, it is completely trivial to put the BrEvent into a root tree. That is what is done in BrEventIO. The BrEvent's are put into trees and written into the files and read back as such. It is a straight trivial root operation. These trees are not, however, the kind of root trees that the root developers envisioned. We knew that from the beginning and our idea was that other data structures would be developed later that would have real physics meanings that would be used in root trees for the purposes of looking at data. These structures would be more specific and necessarily not as general as the BrEvents we have. On BrEvent and BrEventNode, I was not aware that we converted an internal TObjArray into a THashTable. This might be left over from the fact that we got this code from Phobos which had a THashTable and we converted it to a TObjArray. Since the code appeared to work, we did not notice the error. BrRawDataInput: I agree completely that the table names should not be hard coded into methods. I mentioned in a previous mail that I had begun the process of removing these hard codes and in fact there is already an include file called BrTableNames.h or something like that. I will make that my highest priority in the next days between our beamtime and submit it into the repository. As far as the scheme, I needed to match the names that were in the other parts of the code (also hard coded!!!) We had a scheme which is documented and on our web page somewhere, but this scheme has probably evolved over time. Anyway, the hard coded stuff should be removed and then one can worry about scheme once all of the names are in the same file. As far as the Decode methods being too large, I think that is a matter of taste. When I put it together, I thought I had made them about the right size. To divide even more led me to think I might be duplicating some code, but I will revisit that and see if that is still valid. That's my one cent response to the two pennies worth. Kris Christian Holm Christensen wrote: > 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 - 13:34:40 EST