Re: Tree Questions

From: Rene Brun (Rene.Brun@cern.ch)
Date: Tue Jan 12 1999 - 12:09:30 MET


S. P. Wakely wrote:
> 
> Hi ROOTers,
> 
> I have been trying to grok TTrees a little better the last few days
> and I have some questions to put to the experts.
> 
> Split vs. Non-Split:
> 
> Is there a way to access member functions in a split=1 tree??
> Here is an example from ROOT 2.20/06 on an DECUnix Alpha with cxx 6.0:
> ///////////
> CINT/ROOT C/C++ Interpreter version 5.13.83, Dec 2 1998
> Type ? for help. Commands must be C++ statements.
> Enclose multiple statements between { }.
> root [0] gSystem->Load("libEvent.so");
> root [1] f = TFile("Event.root");
> root [2] T.Draw("fTemperature");        //works Fine
> Warning in <MakeDefCanvas>: creating a default canvas with name c1
> root [3] T.Draw("event.GetTemperature()");
> 
> *** Break *** segmentation violation
> Error: No symbol T.Draw("event.GetTemperature()") in current scope
> FILE:/tmp/gaaaaDvda LINE:1
> *** Interpreter error recovered ***
> /////////////

You can access member functions in split mode only for branches
containing complete objects. For example, for test program test/Event
you can do:
   Root > T.Draw("fH.GetMean()") 
where fH is a pointer to a TH1F object.

I agree that it would be nice to have a symetric behaviour if you work
in split mode or not. We are currently a few doing brainstorming
on new requirements for TTrees. This point is being discussed.
I take this opportunity to ask users to send now specific requirements
regarding TTrees. It is the right time.

> 
> Now, if your Tree is written in split=0 mode, you get just the
> opposite behavior.  You have access to methods, but not members.
> 
> If there was access in the split=0 mode to the member variables, would
> there still be any need for split=1 mode?  We could have arbitrarily
> fine granularity via the simple process of accessing member variables:

NO. The main point of the split mode is to minimize I/O.
Accessing leaves in non-split mode is a different history.

> 
> T.Draw("Run.Event.Hit.GetRMS()")
> instead of requiring a vast (by-hand, for more than 1 layer deep)
> splitting of the tree into a branch for every variable.  I suspect I
> am missing something here.
> 

Branches of a TTree are, in general, created from the Event class.
Sub-event components going to different branches.
The automatic split mode(by default) takes each data member
of the object specified in TTree::Branch and, in turn, creates
a new branch.
You can also split by hand by calling TTree::Branch when the automatic
algorithm has limitations (see the Howto) or you want a different
behaviour.
The type of query as you show above, is in general, difficult to
implement for an automatic split algorithm. I would be curious
to know your Run and Event class definition in this case.

> also....
> 
> Terminology:  Leaves, Branches, Superbranches, Events and Entries
> 
> In the ROOT I/O overview, TTrees are said to be built of Branches and
> Leaves.  Unfortunately, I found little reference to these concepts in
> the examples...

Yes, I agree that teh formulation is far to be clear.
In general, users should not be concerned about this low level.
Think only a good object model for your Event class.
Rapidly, you will come to the conclusion that you need an organisation
that will facilitate the organisation of containers for the split mode.
> 
> For instance, in the 'How to Create and Fill a Tree' doc, we first
> make a split=0 Tree with a single branch.  Do I understand correctly,
> then, that the N leaves of the branch are each filled with an instance
> of the Event class??
> 
> And when we use split=1, some of the leaves simply contain Branch
> objects, which then have their own leaves, thus giving us the
> splitting??
> 
> I could find no mention of the concepts "Entry" or "Event" aside from
> the autodocs of the TTree class.  Are these definitions correct?
> 
> Entry:  The entire chunk of data written to a tree during a single
> Fill() call. Could include a single leaf on one branch to single
> leaves on many branches...
> 
> Event:  The chunk of data read from a Tree during a GetEvent() call.
> Includes whatever data have been explicitly 'linked to' via a
> SetBranchAddress() call.  Could include all of or only some of the
> data written in the corresponding Fill() call.
> 
> Is this right?  I found the examples confusing because they mostly use
> the sample class "Event".  They they use GetEvent() without clarifying
> the two apparently different meaning of the term.
> 

Yes, you are right. This terminology is somehow confusing.
We use alternatively the words Event or Entry. The terminology Event
is biaised with what we typically do in High Energy Physics.
Entry is probably a more appropriate term.
An Entry in a TTree corresponds to the data saved in TTree::Fill
or vice-versa in TTree::GetEvent. May be GetEvent should be renamed
to GetEntry?

Rene Brun



This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:28 MET