On Tue, 19 Jun 2001, Rene Brun wrote:
Hi rooters,
the scheme you are talking about is exactly what has been implemented for
H1: several trees are treated in parallel, the parallelity being
guaranteed and verifiable by Run/Eventnumber branches on each tree.
Indices are also present on each tree. Users may write their own trees
with the same scheme, and these user trees can be read in parallel. An
event selection is implemented as a generalisation of the TEventList,
but user trees containing only selected events are not yet implemented.
An interesting addition to this is the introduction of pointers from one
tree to the other.
The tree-friend concept is not yet used in our project (we are for
the moment still working with 2.25/03), but it will fit in very
nicely, and it is part of our future plans to use it.
Since our code is neither finished, nor optimised nor tuned yet,
it is not possible to make it available to everybody. We are just
starting first benchmarks. But of course we are ready to discuss our
experience with interested people.
Regards,
Ursula
> I had already similar suggestions from a few people during the ROOT
> workshop at FNAL. I agree that adding to the current loop by entry number
> the possibility to loop via the index built by TTree::BuildIndex
> or/and the TEventList machinery would be an interesting upgrade.
> As you say, most tools are there to implement this.
> Stay tuned.
>
> Rene Brun
>
> On Tue, 19 Jun 2001, Valeri Tioukov wrote:
>
> > Hi Rene and rooters,
> >
> > Chains and friends are already a lot for trees organization and
> > processing. Logically the trees developing move in direction of relational
> > tables. Why do not make one more step and introduce possibility to
> > sicnchronise tables by the primary key? It seems that everithing is exists
> > already for that. The role of key could play index value. This possibility
> > could provide more freedom to the data processing.
> >
> > The typical scenario of data processing could be as:
> > - tree(chain) with headers for example just runID, eventID for all events
> > - tree(chain) with raw data
> > - tree(chain) with processed data version1
> > - tree(chain) with processed data version2...
> > - ....
> >
> > As it is now - only if all these chains has the same number and the same
> > sequence of entries we can establish the useful friendship.
> >
> > It is not alwais convenient, othen only a small fraction of events are
> > interesting for processing. One way, of cause, - to extract useful events
> > into the new trees. But it could be avoided if one have runID, eventID
> > (naturally!) in each of these trees - them could be indexed, friendship
> > established and then sincronised using index values by the standard (new)
> > function.
> >
> > What do you think about that?
> >
> > Regards
> > Valeri
> >
>
>
*************************************************************
Ursula Berthon
E-mail berthon@in2p3.fr
Tel. 33 - 1 - 69 33 31 21
Fax 33 - 1 - 69 33 30 02
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:49 MET