Subject: Re: Muon digit container design From: LAPORTE Jean-Francois Date: Wed, 10 Oct 2001 19:45:45 +0200 (DST) To: atlas reconstruction mailing list Hi David About your points: -granularity: I have no religion on that. I guess that I prefer a single muon digit container per technology because it looks simple and thus wise. At least if some others require an other structure, I just would like to require that it should remains simple to list digits per technology. -about the ID scheme, I think that there is a great gain to expect in going to the new (not so new actually) Id scheme of the document. The actual one is a nightmare. The key issue is the time needed but since Steve seems to think that this could be done "next month", I think that it is worthwhile to do the change. -about the interfaces, I agree with Steve: start with similar but independent interfaces. Then we will look for abstraction. About the updated proposal, I have few comments: -in the definition of Identifier, it is said "An identifier is a label for a single readout channnel or time slice in such a channel" We know what is a "label for a single readout channnel" but we do not have yet something for "time slice in such a channel". I think that this is a key issue since this allows to uniquely define a digit (e.g. MDT case, the possible many digits from a single tube have the same readout Id which thus does not identify digits uniquely) as well as a readout channnel ID is uniquely defining a channel. I guess that this should be more developed since it is a crucial requirement to be able to "speak" about a given digit without having to use pointer but only label. This is not a big deal but I will be reasurred if it is shown how this enters into the game more precisely. -I noticed this definition of digit: "The implementation is self-describing, i.e. includes the identifier as well as the data". This is ok and is consistent with recent discussions among muon people, However, you later on point the MDT_Digi class which has features that I do not like at all and on which I guest that we reached some consensus. In brief the discussion was about the presence a pointer on a "volume" object. I guess that it was agreed that this pointer should be built at run time and, in order to avoid dependency between digit and geometry domains, should be only "carried" by the digit, i.e no methods should used this pointer, in such away that no more than a forward declaration in the header would be needed. This is not the case of the actual MDT_Digi class. If it is exact that there is such a consensus, this means that we are forseen a new digit. Then it is worthwile to mention this when the actual MDT_Digi.h class is referenced. A Bientot Jean-Francois On Tue, 9 Oct 2001, David Adams wrote: > I have updated my muon digit container description to impose the > requirement that it make use of the generic digit containers of Ma > Meesen. Although I still have questions and misgivings, I feel it is > most important for the various subdetectors to consistent with one > another and apparently the LAr is being developed along those lines. > > The updated page is at the same location: > > http://www.usatlas.bnl.gov/~dladams/mudigi > > If anyone disagrees with the choices made, they should speak up now. > > The above document still is at the stage of specifying requirements and > identifying design issues. Before moving to a design we need to resolve > the issues: > > 1. What is the granularity of the subcontainers (DigitCollection's in Ma > and Meesen's model)? This must be answered for each technology. > > 2. Should we implement something based on the existing detector > identifiers or wait for an implementation of the new scheme? I am > inclined to favor the latter. > > 3. What is the interface for the DigitCollection's? Should detectors > share an common or at least similar interface? Should the implementation > be shared, e.g. a template? > > Once these issues are resolved, we can move on to design, identification > of deliverable and (finally) implementation. > > da > > -- > David Adams desk: 631-344-6049 > Brookhaven National Lab fax: 631-344-5078 > PAS group, Building 510A email: dladams@bnl.gov > Upton, NY 11973-5000 http://www.usatlas.bnl.gov/~dladams > > > ------------------------------------------------------------- > Visit this US ATLAS HyperNews message (to reply or unsubscribe) at: > http://atlassw1.phy.bnl.gov/HyperNews/get/moore/66.html > ___________________________________________________________________ This mail has been sent to all members of the list atlas-reconstruction ___________________________________________________________________