I have worked on BrRawDataInput this afternoon and I removed all of the hard coded table names and put instead the constants which come from the file BrTableNames.h which is in base/inc I have not had the opportunity to test it more than to compile and compile the things in the test directory and verify that things compile. But I didn't do anything mysterious, so the number of errors should be limited to the ultra dumb ones. Kris P. S. As far as splitting the methods, I took Flemmings attitude "if it aint broke dont fix it" My time right now (as almost always) is very limited and I will think about that later Flemming Videbaek wrote: > 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 somecode 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 > givenwrite and written to disk. E.G. imagine an reconstruction pass > that can generate many kinds of objectsTPC local tracking --- > CLustere-- HitClusters-- DetectorHits-- Local tracksDuring the > development and for selected analysis you might save all information > to the outputfiles, whilelater 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 followingFor 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:49:32 EST