In our experiment events are not always independent. For example
a nuclear decay (parent) may generate an event which is followed after
long time by another decay (daughter) generating another event.
This implies that an entry in a TTree may be related to a another entry.
In the reconstruction software we make the association of the events,
and we copy quantities from the entry related to the parent to the entry
related to the daughter.
This is not efficient, since the same quantity is present in both the parent
and daughter entries. For example the quantity in the branch “Energy” , is stored
in another branch “S1_Energy” that stores the energy of the parent in the daughter entry.
Is it possible to store more efficiently the data?
Suppose that we create a branch “Parent”.
Each entry in this branch contains the entry number of the event
which has been assigned as parent of the current entry.
Then, is there a way to Draw() variables from parents?
Let say something like (I invent the syntax) Draw(“Parent$.Energy:Energy”),
where “Energy” is the value of the branch Energy, and "Parent$.Energy"
is the value of the branch Energy corresponding to the entries tagged as parent?
Currently the only way to use data from two ‘different’ entries is via the ‘Friend’ mechanism. However this mechanism is also currently limited to connecting 2 TTrees via the values of identically named branches (i.e. not your case). However, it is plausible to extend the TTreeIndex class to support the case where the names in the parent tree and friend would be different (in which case you could support your case by friending your main TTree with another instance of itself).
where parent is a branch storing the eventnumbers in ‘friend’ to be
paired to the events in ‘tree’.
However BuildIndex should be changed from
BuildIndex(const char* majorname, const char* minorname = “0”)
BuildIndex(const char* majorname, const char* minorname = “0”, const char* mastermajname = “0”, const char* masterminname = “0” )
[quote]Would it work even if ‘tree’ comes with a set of friends? In our software each analysis stage
adds a friend TTree to the first TTree produced.
[/quote]A priori yes, as long as one of the name or alias can be used to differentiate.
Yes, this was also my first idea. However the ‘mastermajname’/masterminname’ since to be more of a property of the friend relationship than inherent to the index being build for the friend. (I.e. the work needed to do the complete update would involve enhance TFriendElement, TTree::LoadFriendTree, etc…).