Hi Ole,
A Tree structure where a top level branch corresponds to a detector type
is indeed a frequent case. There are many possible class structure
for the detector object. For example
class MyDetector : public Tnamed {
Int_t fN1; //some bookeeping basic types
Double_t fD1;
TClonesArray *fResults1; //a collection of results1
TClonesArray *fResults2; //another collection
}
An analysis job adds one top level branch at run time for
each detector. In turn, each top level detector branch may be split
into subbranches where each data member of the TClonesArray class
will have its own branch buffer.
You can make a query like
tree.Draw("detector1.fN1");
tree.Draw("detector1.fResult2.fPx"); //etc
See examples in $ROOTSYS/test/Event.h,cxx
In your example invoking rootcint on MyEvent.h, you should do:
rootcint -f EventInt.cpp -c MyEvent.h
As I already said, it would be nice to see teh friend variables
in the TreeViewer. Point is taken.
Rene Brun
On Mon, 12 Aug 2002, Ole Streicher wrote:
> Hello Rene!
>
> Thank you for your answer.
>
> Rene Brun <brun@pcbrun.cern.ch> writes:
> > > I am just starting in using ROOT, and I have some questions in how to
> > > organize a TTree.
> > If you look carefully at the examples, in particular $ROOTSYS/test/Event,
>
> I did ;-)
>
> > you will see a way to build a Tree with two levels.
>
> Yes, but this is only possible when I try to define the tree with an
> Object, what was not my intention here. My question was in how I could
> define a "deep" structure without the need to define an TObject.
>
> The reason I need this is that I want to have the name of the branches
> and leafs definable at run-time, while tree.Branch(.. &event) has it
> fixed on compile-time.
>
> > In general, it does not make sense to go below two levels of containers
> > in the data base.
>
> Is there a specific reason for that? I need a structure
>
> event -- detector -- analysis_step -- result
>
> where the people from any "detector" may freely choose the
> "analysis_step" name, and anyone developing an "analysis_step" can
> define its own (local) result classes with their name. The idea is to
> have the results any of these steps in its own separate Root tree and
> to "mount" all the trees afterwards.
>
> That's why I thought that I would need a "deeply nested" structure for
> the tree, as well as a possibility to have "hierarchical" friends,
> t.m. to do a
>
> TFile *EventRootFile = new TFile("EventRoot.root");
> TTree *EventTree = (TTree *)EventRootFile->get("root");
>
> TFile *Detector1File = new TFile("Detector1.root");
> TTree *Detector1Tree = (TTree *)Detector1File->get("detector1");
> //...
>
> EventTree->AddFriend(Detector1Tree, "detector1");
> Detector1Tree->AddFriend(Analysis1Tree, "analysis1");
> Analysis1Tree->AddFriend(Result1Tree, "result1");
>
> and to request a certain variable as
>
> EventTree->Draw("detector1.analysis1.result1.var");
>
> Is this possible?
>
> > You organize yourself the hierarchy level using class composition.
>
> Can you explain this (or point me to the according documentation)?
>
> > When using a class, the Branch function will automatically build
> > the leaves for each data member of the class.
>
> Is there a HOWTO available for this? When I try it myself (Root
> version 3.03/07), I always get Error messages:
>
> $ cat MyEvent.h
> #include "TTree.h"
> class MyEvent {
> private:
> int MyVar;
> public:
> int GetMyVar() { return MyVar; }
> ClassDef(MyEvent,1)
> };
>
> $ rootcint -f EventInt.cpp MyEvent.h
> Limitation: Reference member not supported. Please use pointer FILE:/opt/root/include/root/TGenericClassInfo.h LINE:28
>
> Another point is that I always used "#include "root/TTree.h" which rootcint
> seems not to understand.
>
> > The TreeViewer does not show the branches/leaves of friend Trees in
> > the same pane as the main Tree. This option could be implemented.
>
> That would be *very* nice since it allows an easy "point-and-click"
> visualization of a tree together with its friends. How can one ask for
> an implementation of this?
>
> Tschuessi
>
> Ole
>
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:51:04 MET