Re: ROOT based Data Models and Frameworks

Federico Carminati (Federico.Carminati@cern.ch)
Mon, 26 Apr 1999 21:24:41 +0200 (METDST)

Dear Nick,
welcome on board! During a quiet Monday evening I had the stamina, as
you put it, to come to the end of your message. Some of the issues you
address, we are struggling with too. Our "embrional" aliroot framework
contains our present answer to them. As I told you already in FNAL, and
as I am repeating to the whole list, I would be more than happy to share
our code with all the interested parties and to exchange ideas and
modifications.
Coming to your specific points, we solved the difference of persistency
with a class for each detector that HAS a pointer to a TClonesArray of
hits. We are reading the detectors once, and then we are reading and
deleting and reading and deleting the TClonesArray of hits.
The question of the relation between hits and tracks is more
complicated, as you already found out. The solution we have adopted at
the moment is to have a reduced list of tracks that each hit can have (btw
I imagine that you consider a hit the response of the detector, we call
this a digit or a cluster), limited for the moment to three. We limit it
because we want to use TClonesArrays that are faster, but must contains
objects of the same size. Nevertheless we do not like this very much, and
we are planning to have a different schema, where you have hits that
ignore which track they come from, and a sort of dictionary, capable to
hold n:m relations, connecting hits to tracks. In this environment you may
imagine all clever functions that act on the dictionary in the order you
want. Remember that this part is only in our dreams at the moment... Hope
this helps. Please do not hesitate to contact me if you think I can be of
any help. I will appreciate the possibility of discussing with you. Ciao,
Federico

On Fri, 16 Apr 1999, Nick West wrote:

> 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
>