Hi Flemming, et al, On Thu, 9 Mar 2000 17:30:24 -0600 "Flemming Videbaek" <videbaek@sgs1.hirg.bnl.gov> wrote: > 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. I believe that STAR and BaBar actually is storing Event data directly in ROOT TTree's. That's anyway my impression form browsing the ROOT 2000 pages (http://root.cern.ch/root/R2000Program.html), so I guess some of your concerns (valid as they are), may be taken care of. I know STAR has developed a way to securely upgrade classes. Again, take a look at the ROOT 2000 pages. > If you look carefully you will notice that this is in fact commented > out. Oh yeah, you're right, sorry. I was looking at the web pages, and the `/* */' pair was probaly too hard to see - sorry. > 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. I don't get this. What does that have to do with the use of THashTable? > 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. In part, I agree with you. However, to ease the reading (i.e., understanding) for others than the one writting the code, good style is imperative. I'm afraid that I don't find these methods good style - sorry guys. > 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. Cool! Oh, and for Konstantin: The code I repoduced in my previous mail, was `cut-and-paste' from the existing code in `BrRawDataInput', so I don't propose to check record numbers more often than is already done in the existing code. If I inadvertly copied too much, then I'm sorry for sending the wrong message. 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 - 20:03:36 EST