Nick van Eijndhoven wrote: > > > > Dear ROOTers, > > > In setting up some classes for data analysis of events concerning > > > heavy-ion collisions I wonder about the following : > > > > > > I have a class Track and a class Jet and my event data consists > > > of a ROOT Tree in which there is a branch for tracks and a branch > > > for jets of a certain event. > > > Both Track and Jet contain a data member float fEnergy > > > In case I have the libs containing the Track and Jet classes > > > available in my ROOT environment there clearly is no problem, > > > since I can just use the Track and Jet member functions to investigate > > > e.g. the fEnergy of both of them and even plot one against the other. > > > However, in case I don't have the libs, I would use the MakeCode() > > > facility to be able to analyse the Tree. > > > As far as I can see this now gives a problem, since the fEnergy > > > would be related to both classes. > > > Question : Am I right here that the produced code can't work ? > > > Or does MakeCode properly take care of the problem ? > > > > > > Obviously a way out would be to define fTrackEnergy and fJetEnergy, > > > but as far as I can see this is no solution once one thinks of > > > (re)using code of other related experiments. > > > > > > Suggestion : In case MakeCode encounters the same variable name > > > in different branches, could then on each additional > > > occurence of that variable some suffix be added auto- > > > matically be MakeCode ? > > > > > > In case of the above situation this would result in e.g. : > > > > > > fEnergy and fEnergy_2 > > > > > > In case the problems I expect in the above are real, the latter > > > is just a suggestion and in case someone has a better solution > > > please let me know. > > > -- > > Hi Axel and fellow ROOTers, > I was just trying a few things out and it seems the problem I > expected is really there (unless I do something wrong, in which > case I would like someone out there to tell me that). > Below I will attach a small macro (pbdata2.cc) in which I create > a Tree which has 3 branches. > > branch 1 = evhead which is a simple struct > branch 2 = ledaup which is an AliCalorimeter object > branch 3 = ledalw which is an AliCalorimeter object > > Clearly branch 2 and 3 have the same data members etc... defined, > but for ledaup the number of rows(i.e. fNrows) is 44 whereas this > number is 40 for ledalw. > When I run the macro (ROOT 2.00/08 on Win95) which reads some data > from an h2root converted cwn, fills my struct and AliCalorimeter objects > and writes the output into a Tree, indeed an output Tree is created > on a file (see the attached pbdata2.log for the produced log file). > As you can see here, indeed the ledaup has 44 rows and ledalw has 40 > rows. > BUT ..... > >From the tree->Print() output I get the impression that the fNrows > from ledaup and ledalw are just somehow mixed, since I see 2 times > a branch fNrows instead of ledaup_fNrows and ledalw_fNrows. > To investigate this, I startup a ROOT session and investigate the > tree in my browser. > There I nicely see the branches > > evhead > ledaup > ledalw > > and indeed for each branch the various datamembers are there. > BUT .... > When I plot fNrows of the ledaup branch I get the same result as > plotting fNrows of the ledalw branch ! > And this is exactly what I feared in my previous mail. > > Question : How can I achieve that the datamembers of 2 different > branches, containing both an object of the same class > can be be distinguishable ? > > As I said before, of course I can investigate the tree using the > AliCalorimeter memberfunctions of ledaup and ledalw, but my point > is it should also be possible without having the classes available > since if one takes my produced output tree file and uses the > MakeCode() facility, things will go terribly wrong. > In addition I would expect to be able (via the browser) to inspect > correctly the datamembers of the various branches, even in case > different branches contain different objects of the same class. > > In case I dod something wrong, please help me out on this. > Otherwise a solution could be that datamembers of (user defined) > classes in a certain branch get the branch name as a prefix (or suffix) > automatically in writing the tree. Maybe one could make a new > member function with which one could toggle this automatic prefix > (suffix) generation for each branch separately. > -- Nick, In case of a class containing pointers to objects of the same class and in split mode, the leaves of the Tree will effectively have the same name. I will change this in a future version. Note that, if instead of using a pointer, your data members are directly objects of the same class, the leaf names will be distinct. Rene Brun
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:34:36 MET