Hi Rene,
Thank you for pointing me to the TTree::Bronch note. However, may I ask
why this special treatment is necessary? With a somewhat contrived
example, one gets the same name-clashing problem when attempting trying
to write different classes (say a TVector2 and TVector3) to a tree. It
would be nice if the user didn't have to know the internal structure of
all the classes being written before deciding how to write them to a
TTree.
Unless the idea is always to use the "." suffix, in which case I come
back to why isn't this the default behavior? (Backward compatability?
Optimization?)
Also, when using "dirA." as the branch name, the 3.05-04 version of
TTree::MakeClass creates variables with a '.' at the end of a variable
name, which is invalid syntax.
Finally, I guess one can read and recover the entire object by setting
the split-level at the timing of writing to 0, but is there an easy way
to get both split branches (for performance) and then, after some tests,
read in the entire object and treat it as a whole? (ie, can I glue
the sub-branches back together into a TVector3, without alot of extra
coding for each instance?)
Thanks for your help,
Rob
--------------------------------------
On Wed, 21 May 2003, Rene Brun wrote:
> Date: Wed, 21 May 2003 14:27:38 +0200 (MEST)
> From: Rene Brun <brun@pcbrun.cern.ch>
> To: Robert Feuerbach <feuerbac@jlab.org>
> Cc: roottalk@pcroot.cern.ch
> Subject: Re: [ROOT] TTree::MakeSelector needs unique variable names
>
> Hi Robert,
>
> Use a "." in case members in sub-branches have identical names.
> See doc of TTree::Branch that says:
>
> //
> // IMPORTANT NOTE about branch names
> // In case two or more master branches contain subbranches with
> // identical names, one must add a "." (dot) character at the end
> // of the master branch name. This will force the name of the
> subbranch
> // to be master.subbranch instead of simply subbranch.
> // This situation happens when the top level object (say event)
> // has two or more members referencing the same class.
> // For example, if a Tree has two branches B1 and B2 corresponding
> // to objects of the same class MyClass, one can do:
> // tree.Branch("B1.","MyClass",&b1,8000,1);
> // tree.Branch("B2.","MyClass",&b2,8000,1);
> // if MyClass has 3 members a,b,c, the two instructions above will
> generate
> // subbranches called B1.a, B1.b ,B1.c, B2.a, B2.b, B2.c
>
>
> Rene Brun
>
> On
> Tue,
> 20
> May 2003, Robert Feuerbach wrote:
>
> >
> > Hi ROOT-Team,
> >
> > I'm noticing some odd/incorrect behavior out of
> > TTree::MakeSelector, where the automatically generated code
> > does not have unique names for the variables to hold the data
> > for each branch and leaf. I'm currently testing this with
> > ROOT 3.05-04, but similar results are from 3.02-07 as well. This
> > was run on a Linux RH7.3 machine.
> >
> >
> > A simple test example is (do_1 and then do_2):
> >
> > //------------------------------
> > void do_1 ()
> > {
> > gSystem.Load("libPhysics");
> > TFile *testf = new TFile("test.root","RECREATE");
> > TTree *myT = new TTree("myT","test tree");
> >
> > TVector3 *dirAp = new TVector3(0.,0.,1);
> > TVector3 *dirBp = new TVector3(0.,0.,2);
> >
> > myT->Branch("dirA","TVector3",&dirAp);
> > myT->Branch("dirB","TVector3",&dirBp);
> >
> > myT->Fill();
> >
> > dirAp->SetXYZ(1.,0.,0.);
> > dirBp->SetXYZ(2.,0.,0.);
> > myT->Fill();
> > myT->Write();
> > testf->Close();
> > }
> >
> > void do_2 ()
> > {
> > TFile *testf = new TFile("test.root");
> > TTree *myT = (TTree*)gDirectory->Get("myT");
> > myT->Print();
> > myT->MakeSelector("my_test");
> > }
> > //------------------------------
> >
> > The resulting TSelector class looks something like:
> >
> > // part of my_test.h, created by TTree::MakeSelector
> > --------------------------------------------
> > class my_test : public TSelector {
> > public :
> > TTree *fChain; //!pointer to the analyzed TTree or
> > TChain
> > //Declaration of leaves types
> > TVector3 *dirA;
> > UInt_t fUniqueID; // <-- NOT UNIQUE
> > UInt_t fBits;
> > Double_t fX;
> > Double_t fY;
> > Double_t fZ;
> > TVector3 *dirB;
> > UInt_t fUniqueID;
> > UInt_t fBits;
> > Double_t fX;
> > Double_t fY;
> > Double_t fZ;
> >
> > //List of branches
> > TBranch *b_TObject_fUniqueID; //!
> > TBranch *b_TObject_fBits; //!
> > TBranch *b_dirA_fX; //!
> > TBranch *b_dirA_fY; //!
> > TBranch *b_dirA_fZ; //!
> > TBranch *b_TObject_fUniqueID; //!
> > TBranch *b_TObject_fBits; //!
> > TBranch *b_dirB_fX; //!
> > TBranch *b_dirB_fY; //!
> > TBranch *b_dirB_fZ; //!
> > ...
> > ---------------------------------------------
> >
> >
> > So, this is different from what I expected. What I would expect
> > to happen is:
> >
> > BEST CASE: The dirA and dirB branches are directly
> > connected to TVector3 objects.
> >
> > WORKABLE: The TBranch's are read into unique variables
> > dirA_fX, dirA_fY, dirB_fX, etc...
> >
> >
> > While I can generate the correct code for a small case like this,
> > the automatic code generation is invaluable for processing large
> > trees. Am I doing something wrong?
> >
> > I think the problem is in the name generation in
> > TTree::MakeClass, but the code seems to build the names for
> > TBranch's and the temporary variables in many places. Perhaps
> > one should use a single 'MakeUniqueLeafName' method, and then
> > just stick a 'b_' in front for a TBranch?
> >
> > Thanks for your help,
> > Rob
> >
> >
>
>
--
/***************************************************
* Robert Feuerbach feuerbac@jlab.org *
* Jefferson Lab CEBAF Center A120 *
* 12000 Jefferson Avenue Office: (757) 269-7254 *
* Mail Stop 12H Page: 584-7254 *
* Newport News, VA 23606 Fax: (757) 249-1965 *
***************************************************/
This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:11 MET