TTrees. How it works

From: Rene Brun (Rene.Brun@cern.ch)
Date: Mon Nov 10 1997 - 15:52:43 MET


> Christoph Borgmeier wrote:
>
>  Hello Rene,
>
>  I sent you a lengthy description of my event and track classes on
Friday.
>  Now it looks like I already understand a little bit more:
>
>  If I store a pointer to an entry of a TClonesArray, the entry seems
to be
>  serialized independently of the TClonesArray. So the data of the
pointer
>  exists twice in the file. In my current work, this is acceptable,
because
>  the major part of analyses will be done only on the trigger
particles.
>

You must distinguish between the split and no-split method.
In the no-split method, if the object you are written out is a hierarchy

of other objects, these objects, in turn, pointing anywhere, thus
creating
a graph structure, ROOT will serialize all the referenced objects
in the output buffer, taking care that objects referenced multiple times

are written only once.
When you will read back the buffer, the super object will be rebuilt
in memory with all pointers correctly set.

If now, you use the automatic split method, when you create your
branches
of a TTree, you must be more careful. You may end up in the situation
that you describe where an object is going to be saved in multiple
branches.
This is essentially why we use the wording "TTree" to reflect the
hierarchical nature of this facility.
To use the split method, you must effectively ensure that your branches
do not have pointers to branches other than daughter branches.
For this reason, it is sometimes more appropriate (and also less
expensive)
to use small integers as a reference to a track number (in a list)
rather than
a direct pointer to the track.

>  But I found out, that I still have a design problem. I was used to
have
>  the CLHEP classes Hep3Vector, HepPoint3D, and HepLorentzVector, which

>  allowed to treat tracks as geometrical objects and simplified
distance
>  calculations and projections. Then I noticed that these ideas are not

>  present in the root examples, that the Event/Track example and also
>  ATLFAST contain only `flat' classes, which are mainly collections of
>  scalar entries. Will there be a kind of common three dimensional
geometry
>  in ROOT?
>

You can perfectly make a Track class using all the 3 classes  quoted
above.
By the way, the next version of Root will include this kind of classes
as well as Matrix classes. More news about this soon.

>  Now I still run into a concetional problem. A simply class to
describe a
>  straight Monte-Carlo track might look like this:
>
>  class MC_Track: public TObject
>  {
>    ...
>    ...
>  private:
>    MC_Vertex* fCreationVertex;
>    MC_Track* fMotherParticle;
>    MC_Track* fDaughterParticle;
>    ThreeVector fMomentum;
>    Float_t fLength;
>  };
>
>  Now I would not want to store the daughter particle, because it is
>  redundant, and because just reading the trigger particles would
result in
>  reading effectively the entire event.
>
>  Do I understand it right, that I have to write my own Streamer
function
>  with a line like
>
>     if( fMotherParticle!=0 ) fMotherParticle->fDaughterParticle =
this;
>
>  and that I must not use any splitting of MC_Track to have the
Streamer
>  function called?

What you should do is to create a TClonesArray of tracks as shown
in root/test/Event. Instead of your class structure above, simply have:
  class MC_Track: public TObject
  {
    ...
    ...
  private:
    Short_t fCreationVertex;
    Short_t fMotherParticle;
    Short_t fDaughterParticle;
    ThreeVector fMomentum;
    Float_t fLength;
  };
>
>  Is there the possibility to just read one Object (not one `column')
of a
>  TClonesArray?

>

Not in a TTree unless you have a fixed number of tracks and amke one
branch
for each track.

>  If you think, these things are interesting enough, would you please
reply
>  via the mailing list?
>
done


Rene Brun



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