Re: Possible problem ?

Axel Schwank (schwank@mail.desy.de)
Tue, 18 Aug 1998 09:07:48 +0200 (MET DST)

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

********************************

Axel Schwank

DESY H1-F22
Notkestrasse 85
D-22607 Hamburg

Rm. 1b/269
Tel (+49 40) 8998-3560
Fax (+49 40) 8998-4385

e-mail schwank@mail.desy.de
Quix 0165-6-2705109

********************************

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.
> --
>
> 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
> *----------------------------------------------------------------------*
>
>