I wonder, whether all of our philosophical problems have been discussed up
to an end. When I started to look into Root as an object-oriented
framework, I was a bit surprised, that all objects are kept in global
lists, and that there are globally current objects like pads, nodes, and
files. It seemed to me that this behaviour was directly inherited from
Root's Fortran predecessor and might conflict with oo-paradigms. After
working with it for some months, I got the impression, that these things
are well suited for interactive work.
The C++ project, which I am involved in, was started a long time ago, and
we tried to do it the CLHEP/Ellemtel/STL way. For analyses, we agreed,
that the ZEBRA-bank style of event data storage is too static. It is
difficult, if not impossible, to insert or delete elements in the global
tables( i.e. no-constant indices for the entries). We did not want to
restrict ourselves to putting all instances of one class into the same
container. With some effort, we could use Root for interactive work (e.g.
all occurrences of templates had to be wrapped).
This leads to a different system than the Root event examples Event/Track
and ATLFAST. Instead of TClonesArrays for each _type_ to be stored, we
wanted to create our own hierarchy of pointer-linked objects. The
possibility of handling such things seems to be a major advantage of
OODBs. When trying this with Root, we noticed another advantage: There are
many O(2000) particle tracks stored in the MC-events. In most cases, we
are only interested in the trigger particles, which are usually only two
and can be accessed by pointers. The reading of the trigger particles is
much faster than reading the entire container of tracks.
My question now: Is this a valid model for use with Root and can the
problems described below solved with keeping this model? Since there are
other packages involved, this is a crucial question for us.
Thank you for an answer
Christoph
On Wed, 25 Feb 1998, Rene Brun wrote:
> Christoph Borgmeier wrote:
[...]
> > The core of the problem looks like this:
> >
> > class Particle: public TObject
> > {
> > public:
> > [...]
> > private:
> > Particle* motherParticle;
> > };
> >
> > With this I can store simulated decays by just writing and
> > reading child objects of a certain level, e.g. the muons of
> >
> > B0 -> Jpsi -> mu+mu-
> > + unknown
> >
> > The motherParticle is shared in this case, so it must not be deleted
> > together with the first deleted child.
> >
> > I wonder, whether there is the possibility to flag the objects,
> > which are automatically created by GetEvent, and delete them
> > systematically.
>
> Hi Cristoph,
> Instead of using a pointer to *motherParticle, simply
> use the motherParticle number in the list of particles.
> This has many advantages.
> - your problem disappear in case of multiple reads referencing
> the same object.
> - I/O is more efficient in time
> - file is shorter. Index will collapse to a few bits instead
> of 4 bytes.
> The penalty is small. instead of a direct use of motherParticle,
> you must have a statement like
> PArticle *part = (Particle*)fParticles.At(index).
> This last call should go into a inline member function, such that
> you simply do
> GetMotherParticle().
[...]
---------------------------------------------------------------------------
Christoph Borgmeier | Mail: DESY -F15-, Notkestr. 85, 22607 Hamburg
Humboldt Univ Berlin | Phone: +49 40 8998 4850
Email: borg@ifh.de |
---------------------------------------------------------------------------