Hi Federico, very many thanks for your reply, we are already in your debt for your AlLIROOT talk at Fermilab that helped push us along. Your model, that detector elements HasA TClonesArray of hits (or digits or ...) is interesting. I have seen this before, e.g. CDF, where the detector "owns" its data. It certainly more in the OO philosophy than mine where I just picture a world of anonymous containers. Multiplexing complicates things of course. We certainly should know, at readout time, know which channels produced (owned) digitisations, but, until we demultiplex, we don't know which 3D hits are owned by each detector element. Still the same principle can apply; the detector can still own its data. When it come to tracks we in MINOS may be saved by the simplicity of our events. We could argue that, though we want to put our hits into TClonesArray, we have so few Tracks and Clusters that we could settle for TObjArray and then we can have variable sized lists for the hits they own. Thanks again for sharing your thoughts. Its an interesting alternative to the ideas I am thinking about at present. I am sure we will be looking at the ALIROOT code. I hope that some day we wil be able to pay back some of the help! Cheers, Nick. In reply to:- 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 >
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:32 MET