Axel Schwank wrote:
>
> Dear Nick,
> I read about your problem with equally named data members in a ROOT TTree.
> I wonder if it really turns out to be a problem. Have you tried this out?
> I use a TTree built of TClonesArrays in split mode. Probably you would use
> the approach to build the tree directly of your classes. But then, each
> class would go into a separate branch and thus each subbranch would be
> uniquely named, e.g.
> Track_fEnergy and Jet_fEnergy.
> If I understand you well, that's how you build your Tree.
> Or do I misunderstand something here?
> Could you spare the time and tell me how your Tree is organized and where
> the branches collide?
>
> Thank you in advance,
> Axel
>
> On 13 Aug 1998, 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.
--
Cheers,
_/_/ _/ _/ _/_/_/_/ _/ _/
_/ _/ _/ _/ _/ _/ _/
_/ _/ _/ _/ _/ _/_/
_/ _/_/ _/ _/ _/ _/
_/ _/ _/ _/_/_/_/ _/ _/
*----------------------------------------------------------------------*
Dr. Nick van Eijndhoven Department of Subatomic Physics
email : nick@phys.uu.nl Utrecht University / NIKHEF
tel. +31-30-2532331 (direct) P.O. Box 80.000
tel. +31-30-2531492 (secr.) NL-3508 TA Utrecht
fax. +31-30-2518689 The Netherlands
WWW : http://www.phys.uu.nl/~nick Office : Ornstein lab. 172
----------------------------------------------------------------------
tel. +41-22-7679751 (direct) CERN PPE Division / ALICE exp.
tel. +41-22-7675857 (secr.) CH-1211 Geneva 23
fax. +41-22-7679480 Switzerland
CERN beep : 13+7294 Office : B 160 1-012
*----------------------------------------------------------------------*
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:34:36 MET