Subject: Re: muon digit container design From: David Adams Date: Thu, 04 Oct 2001 15:58:15 -0400 To: Hong Ma CC: Torre Wenaus , Srini Rajagopalan , Pavel Nevski , Yuri Fisyak , Alex Undrus , David Adams Hong: Thanks for your comments. We have somewhat different models. You have a collection of regional collections in your persistent store and present exactly the same view in memory. I have completely divorced the transient and persistent views. I believe the typical application for the digit collection (including the HLT) is to construct the collection from a pointer to the raw data and then access the data through the collection without ever writing to or reading from persistent store. I would either unpack the data completely or unpack pieces on demand. The demand might be for a specific channel or for a region of the detector. The regions for these requests and the regions appropriate to the raw data need not be the same. On those rare occasions where the digits were to be written to persistent store (root or objectivity), I would write them as a single collection in a space-saving form. When reading them back I would do it in their entirety. I don't expect this format to be used for the HLT and I don't have any speed requirement on the read from persistent store but this requirement seems to be driving your design. I may be misunderstanding an important point. Let me know a use case if this should be added as a requirement. Thanks. da Hong Ma wrote: David, I read through your docs. It may be OK to use detector technology as the granularity for now, since there is lack of information/requirements on what they should be. But we should be aware that most likely we need a collection class for a finer granularity. I basically have the same problem in deciding what the "Region" or Collection should be for LAr. That is why LAr raw data does not use the new container yet. I think the input to this decision is 1) How the raw data is stored in the raw Event? What is the granularity of ROD (readout driver, the base units in Raw EVent)? Last time I tried to find that info for LAr, I failed. You may give it a try for muon. We should aim to have 1:N and N:1 correspondance between Collection and ROD. 2) HLT access requirements. If most of the HLT algorithms access digits with some minimum granularity, then there is no point of making the Collection smaller than that. But I think it is hard to get a concrete number from them. Hong. Hong Ma Tel:631-344-2919 Physics Dept, 510A Fax:631-344-5568 Brookhaven National Lab Email: hma@bnl.gov Upton, NY 11973 On Wed, 3 Oct 2001, Torre Wenaus wrote: Looks good. David, Hong, Srini and I already discussed and the results are reflected in what David wrote. Yuri should also review and he tells me he did so and has no disagreement, so I suggest this be sent out more widely. I think the appropriate place is the Moore hypernews list, moore@hn.usatlas.bnl.gov. I suggest one change before that. Despite the explanation in your preamble, I suggest that you change 'choose' to 'propose' in appropriate places before you send it out. - Torre David Adams (dladams@bnl.gov) wrote on Tuesday 2001/10/2 15:59: > I have written down requirements and some design issues for the muon > digit container. For definetness I have made choices for each of these > issues but I feel we should come to consensus on these issues before > proceeding with the design and implementation. > > See http://www.usatlas.bnl.gov/~dladams/mudigi > > I propose we meet sometime soon to discuss these issues. > > 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 > > -- -- Torre Wenaus, BNL Preferred: torre@wenaus.com Or: wenaus@bnl.gov -- ATLAS/LHC 631-344-4755 Fax 631-344-4206 -- B. 510A Room 1-220 http://www.wenaus.com/torre.html -- 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