Dear roottalk,
at our recent collaboration meeting, the MINOS experiment decided to adopt ROOT
for their Monte Carlo, Reconstruction and Analysis software. However, the group
assigned to this task is very small; less than 3, of which only one has had
significant practical experience of C++/OO. We are hoping that, as MINOS is a
relatively simple experiment, others have already faced all the major analysis
design issues, in a ROOT context, that we must tackle. We further hope that we
may be able to look at their code to help us formulate our own ideas. We
attended the recent ROOT workshop at Fermilab and already know of some
experiments who plan to use ROOT at the heart of their off-line, but thought it
worthwhile to post to roottalk to canvas the full ROOT community. We would be
very grateful to hear directly from other groups using ROOT like this.
Currently we are concentrating on two topics: the Data Model, and the Framework.
The Data Model
--------------
We need a data model that is specific to MINOS, but the machinery that supports
it is generic to HEP. The very simple model:-
o Hits come from detector elements
o Hits are assigned to tracks
is sufficient to illustrate the requirements of the machinery. Both of these
are n:1 relationships. Navigating n:1 e.g. hit -> detector element, the most
natural way we can think of would be to ask the hit object to return its
detector element object. Navigating the other implies iterating over a
collection. At first sight this all seems straight forward, but there are a
number of complications:-
1) Detector element objects have a different persistency to hit objects; the
same detector elements will remain in memory for a collect of events each
with its own set of hits. So if detector element objects have containers
of hits, they have to be refilled each event and there has to be a way to
associate hits with their detector element containers.
2) Some relationships are dynamic: event reconstruction may assign hits first
to one track and then to another. Iterators that are scanning over all
the hits on a track have to be well behaved if this happens during their
lifetime. Indeed the code to reassign hits may well be using such an
iterator.
3) Our legacy code is Fortran/Adamo and our users have already grown used to
being able to dictate the order of iteration by sorting on multiple data
member values. We would prefer not have to tell them that the first
"improvement" for the pain of learning C++ was the withdrawal of this
facility! So we will have to be able to pass sort functions, or possibly
sort objects, to our iterators.
None of this is technically that difficult, although we do want to have
reasonable performance so it has to be efficient. We are currently thinking of
making all our sets TClonesArrays as this provides a simple persistency
mechanism for expressing relationships i.e. by using the array index as a
reference. n:1 relationships pervade the data model so it seems natural to
develop some class that HASA TClonesArray (rather than ISA - we don't want to
expose an array interface) and an associated iterator class.
The Framework
-------------
We already know that we have to pay careful attention to the major internal
and external interfaces, and that dependencies between are class libraries must
be carefully managed and be explicitly addressed at the design stage. We are
also aware, from the wonderful Design Patterns book, of ways to engineer these
interfaces. We also see, looking at other experiments, strong processor -
object structure modules with algorithm classes to decouple processors from the
data model. So, we are beginning to understand some of the basics, but examples
of real live code would be very instructive.
So, if anyone has had the stamina to read to the end of this mail, and is
working on a ROOT Monte Carlo and Reconstruction system, we would be very
grateful to hear from you.
Thanks,
Nick West
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:31 MET