Subject: Re: DRAFT minutes of the reco data model meeting From: David Adams Date: Mon, 08 Oct 2001 10:01:50 -0400 To: David Rousseau CC: David Adams David: On the subject of granularity, I do include a use case which calls for partial unpacking of the data and this leads to a corresponding requirement. However, I only impose this requirement on the raw data and not on the StoreGate forms (root, objectivity, ...). If there should be a requirement for partial unpacking from these other forms, please let me know. This would be an important new requirement. I agree with your comments on common classes. I will wait for a design of the IdentifiableCollection before continuing with my design. da -------------- David Rousseau wrote: Message-ID: Priority: NORMAL X-Mailer: Execmail for Win32 5.1.1 Build (10) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Hi David, OK, in fact after sending these draft minutes out I took the time to look at your web page, and realised you were note doing exactly what I thought you were. I've now modified the action list to be: Investigate possible use of IdentifiableCollection with Muon event : David A. ( http://www.usatlas.bnl.gov/~dladams/mudigi ) Regarding granularity, a demanding use case is the one of the SiTracker where the combinatorial is very high (typically 107 track skeleton considered for an event at high luminosity), so that it is essential to reduce the number of combination as early as possible. Using the wafer granularity allows just that. Now, i can understand that there is less natural granularity for the muon. Note that at this stage I certainly don't want to impose that Ma/Meessen classes are used everywhere, it may very well be that they do not fit muon needs . But I do encourage use of common classes in general. It is usually less work to look at existing classes with respect to one's requirement and use cases, then (if no clear show-stoppers) to use them, learn from them, give feed back on them, and only when show stoppers (diverging requirement) do appear, rewrite them from scratch. Note that if you want to go for a muon specific solution, you'll have to maintain them, take care of the persistency with the connection to the Data Dictionary, of the connection to the EF bytestream and so on...while part of this would be already done for you if you use Ma/Meessen classes. Cheers David --------------- On Mon, 08 Oct 2001 08:49:59 -0400 David Adams wrote: David: My requirements and beginning of a design for the muon digit container may be found at http://www.usatlas.bnl.gov/~dladams/mudigi I sent this URL to the reconstruction mailing list last week. My plan of action would be to complete the design, identify deliverables and then begin implementation. I am waiting for some response from you before proceeding any further. I am not far enough along to have made the decision to use what you call the Hong/Meesen HitCollection or IdentifiableCollection. The only documents I have from them are dated September 11 and don't mention either of these. The most relevant class is DigitCollection which is discussed only briefly. Most of their discussion centers around DigitCollectionContainer. I have gone back and forth with Hong about this a few times but I still don't understand why this is needed. I can understand the desire to have some uniformity in the digit collections from the different subdetectors and will follow your instructions if you want to impose the requirement that one or more of the Hong/Meesen classes be used in the implementation of the muon digit collection. I need to know which one(s) and then will need a more complete description from them. Thanks. 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