Re: again ROOT db (long)

Nick van Eijndhoven (Nick@fys.ruu.nl)
Tue, 31 Mar 1998 09:54:42 +0200 (MET DST)


*** Christoph Borgmeier wrote :
>
>
> Dear ROOT developers and users,
>
> please let me come up again with my old problem of pointers in the ROOT
> DB. On my previous questions on this topic, I was strictly recommended to
> store data in a ROOT DB like shown in the `event' and ATLFAST example. Let
> me recollect this:
>
> All objects of an event should be stored in TClonesArrays, one
> TClonesArray for each type. Integer indices describe relations between
> table entries. The advantages of this are clear:
>
> * fast vertical access
> * good compression possibilities
> * TClonesArrays avoid some memory allocation and deallocation
>
> But it's obvious, that this approach also bears some restrictions:
>
> * all objects of one type must be stored in the same array. That might
> lead to problems with temporary and semi-temporary objects, i.e. objects
> which should not be stored or only be stored under certain circumstances.
>
> * all `integer pointers' point into the same array. This forbids the use
> of polymorphism, which is a major advantage of the ROOT system.
>
> * the objects pointed to are not defined by language constructs, the
> relations are not stored explicitly in the DB. So any code reading the DB
> has to have already built in the additional information about the
> relations.
>
> It seems to me that there are many possible applications for such missing
> features, e.g. reconstructed decays with generalized particles like
> different kinds of tracks and calorimeter information. They could also be
> related to different types of detector hits and calorimeter clusters.
>
> One could also have different sets of reconstructed tracks, e.g. simple
> hit fits or results of global vertex fits. One might also get a set of
> competing reconstructions and store only some of them. These things will
> have a rich substructure and will not fit well into `flat' arrays.
>
> ROOT provides part of the necessary power, e.g. the possibility to store
> canvases with deep polymorphic substructures. But up to now, I failed to
> store parts of my events in a similar way.
>
> The first reason (*) is, that there might be cross-links inside the object
> tree. These should not lead to the same object stored twice, there seems
> to be a hash table mechanism to avoid this, but I could not make it work
> yet.
>
> The second problem is the deleting of the sub-objects. In my event
> example, the objects containing the pointers do not necessarily _own_ the
> objects pointed to (maybe because of *), that's why I tried to create my
> own garbage collection for this. (It failed so far to free all memory of
> ~1000 events, but I am still struggling.)
>
> My question now: has anyone else found the need of features described here
> and maybe solved the two problems? Do I overlook important aspects?
>
> Best regards and thank you very much for the help
> Christoph
>
>

Hi Christoph,
Seems you really looked deep into setting up event structures.
Since I have only started with this (from a physics analysis point of
view) it might be that my info to you is only of limited use.
However, let's give it a try.
In setting up some 'event' structures for data analysis for the WA93/WA98
and as a development exercise for ALICE I have put together some classes
like Track, Jet (for track analysis), Invmass (for invariant mass studies)
and Calorimeter, Module, Cluster (to handle calorimeter signals).
Currently I am working on a Vertex class in relation with track reconstr.
and fitting procedures.
Clearly a Calorimeter cluster (e.g. photon) one might want to specify
as a track to enable all 'track analysis tools' for photons as well.
So obviously there are some 'inter-relational' actions needed for the
above classes.
Indeed I started out with the ideas you mentioned above, but then I
realised that it is better to define the 'relations' of all these objects
with eachother in the classes themselves.
In this way it works perfectly well to make TClonesArrays for each
class type, since all 'inter-relational' stuff is handled by the classes
(member functions) themselves.
For the moment this construction works satisfactory for me, but maybe
once I get to a more detailed level it might break down.
For the moment I can't judge on this, so here is the point where I
can't help you any further and if someone else can provide some more info on
this, please speak up so that the whole ROOT user community can profit from
it.

Cheers,

_/_/ _/ _/ _/_/_/_/ _/ _/
_/ _/ _/ _/ _/ _/ _/
_/ _/ _/ _/ _/ _/_/
_/ _/_/ _/ _/ _/ _/
_/ _/ _/ _/_/_/_/ _/ _/

*----------------------------------------------------------------------*
Dr. Nick van Eijndhoven Department of Subatomic Physics
email : nick@fys.ruu.nl Utrecht University / NIKHEF
tel. +31-30-2532331 (direct) P.O. Box 80.000
tel. +31-30-2531492 (secr.) NL-3508 TA Utrecht
fax. +31-30-2518689 The Netherlands
WWW : http://www.fys.ruu.nl/~nick Office : Ornstein lab. 172
----------------------------------------------------------------------
tel. +41-22-7679751 (direct) CERN PPE Division / ALICE exp.
tel. +41-22-7675857 (secr.) CH-1211 Geneva 23
fax. +41-22-7679480 Switzerland
CERN beep : 13+7294 Office : B 160 1-012
*----------------------------------------------------------------------*