Subject: Re: Muon Event Model Discussion From: "David Adams" Date: Tue, 23 Oct 2001 10:40:26 -0500 To: moore@atlassw1.phy.bnl.gov Newsgroups: http://atlassw1.phy.bnl.gov/HyperNews/get/moore.html Jean-Francois: I agree that the indexing is an important item omitted from the present description. It should be added to the use cases, requirements and design. However I am reluctant to put in much effort without some guidance from the DB group. If we can convince ourselves that our present design is unlikely to conflict with indexing, then I propose we defer it until we have implemented at least the MDT digit container. My working model is to assume that the indexing is implemented by requiring the technology container to return an integer index for a given digit and to return the corresponding digit for a given index. The second operation is required to be fast and to support deferred read of module subcontainers. I think the present design is consistent with this. da LAPORTE Jean-Francois wrote: > Hi David > > ok, I understand your distinguo between labels and indexes. > I guess that what I have in mind is indexes for digit objects. > I agree also that this is a general problem that should be > solved for all ATLAS objects. I think that this is a important > issue exactly for the pbs that you mention (point back from track > to digits). > > Now should we wait until a general solution is found? > > Can we not think to a temporary service that would provide such a > functionnality for Muon objects? > > A Bientot > Jean-Francois > > > On Tue, 23 Oct 2001, David Adams wrote: > > >>Jean-Francois: >> >>Labels >>------ >> >>If by label you mean provide a string identifier, then the muon digit >>container does not have the requirement that one be able to label >>individual digits. Is that a requirement? If so, why? How would such >>labels be used? >> >>In fact, the present design does not even require one be able to label >>channels (tubes in the MDT). It only requires identifiers for modules >>(chambers). However, it seems clear that we do want channel identifiers >>for other reasons. For example, as you indicate, the digit design calls >>for digits to be able to return their channel identifier. >> >>We might later want to give the muon containers (either technology or >>module) the capability to return the digit(s) associated with a >>particular channel. If the tubes can return multiple hits in one event, >>then the reply to this request for MDT would be a list of digits. If >>there is at most one digit, then we could return a single digit or digit >>pointer. There must then be the possibility of being in an invalid or >>null state to indicate the absence of a digit in that channel. >> >>Indexes >>------- >> >>I do believe there is a need for a compact index to specify digits >>within each muon digit container. This would enable persistent objects >>such as muon clusters or tracks to point back into the container. This >>is something that is missing from my requirements. >> >>This is a general problem and I believe the DB group should impose this >>sort of indexing requirement on all event data objects. >> >>da >> >>LAPORTE Jean-Francois wrote: >> >> >>> Dear Colleagues, >>> >>> please find below my inputs for the Muon Event Model discussion. >>> >>> A Bientot >>> Jean-Francois >>> >>> Digit Container: >>> ---------------- >>> As far as I have understood it, I'm happy with the David's >>> Digit Container proposal but on one point. >>> Given that: >>> -one aims to be able to label uniquely digits >>> -the readout channel identifier or more precisely identifier >>> of VOLUMES are the only ones referenced in the proposal >>> (BTW VOLUMES identifiers are the only one defined in the >>> Muon Id scheme document) >>> -in the case of MDT, the available identifier labels uniquely >>> a tube. >>> -MDT tubes are fundamentally multi-digits device; in one >>> event, one can have in a PARTICULAR tube MANY digits corresponding >>> to different drift times (that this depends on the electronics >>> - multi or single hit capability- is irrelevant for my point) >>> >>> then it follows that the identifier of readout channel is inconvenient >>> or at least insufficient to label uniquely MDT digits. >>> >>> So how will we label uniquely MDT digits? >>> >>> I tried to follow a recent mails exchange on "storing a >>> track to the database" (atlas-database and reconstruction lists). >>> I catched in the flow the concept of a DataHistoryService >>> service (still to be implemented, I guess) creating and returning >>> an unique Identifier (which would be arbitrary, I guess) for >>> an object. >>> >>> Are we going to rely on such a service? I have nothing against >>> the idea. I guess that I like it. My only worry is that >>> this would postpone the issue on labelling uniquely MDT digits. >>> >>> Digit: >>> ------ >>> There were some discussions on digits few weeks ago and as >>> far as I can remember and understand, some consensus was reached >>> that I would like to briefly described since I love it: >>> digit should contain >>> -the readout channel identifier >>> -the data (drift time for MDT,..) >>> -a pointer on volume to be filled at some initialisation step >>> but not "saved" persistently on the contrary to the Id and data >>> This pointer should be just passed but not "used" in the >>> digit class (e.g., no geometry methods) in order to have just >>> to have a forward declaration of volume class and thus to have >>> no dependency between digits and geometry packages. >>> >>> Now still missing is the connection to hits. Here I guess that >>> one should use the way how digits "point" to geometry in the >>> above description: refers to hits using Ids, and have >>> not-to-be-saved-neither-used pointers initialised at run-time. >>> >>> So one comes to the question of hits management, hits containers. >>> I guess that fundamentally, there are no big differences with digits >>> management but that it could happen that hits "live" in volumes >>> that are not readout channels, RPC gas gaps for instance. But we >>> can arrange hits in bags referring to volume using >>> Ids of the Muon Id scheme document since these Ids label all >>> volumes that we need (to be checked, but I guess true). >>> >>> However again, there is the question of how to label uniquely hits >>> since, more obviously than in the case of digits, many hits could >>> appears in only one volume (true for all technologies). So same >>> issue, same worry. >>> >>> Hits: >>> ----- >>> I would love something similar to the digit scheme and the >>> hit from David Calvet: >>> hit should contain: >>> -the identifier of volume in which hit came to life >>> -the data: bi-points of the step, deposited energy, time >>> -not-to-be-saved-neither-used pointer on volume >>> >>> Probably some way to refer to generated particle would be >>> nice but I know nothing on how to do. >>> >>> I'm not sure that a way to refer to digits is desirable. >>> Mainly because digits results of the conjunction of a set of >>> hits, of a digitisation model, of the actual parameters of >>> this model and on top, of random generators seeds. So it would >>> be bizarre and probably wrong to put digits objects in the state of >>> hits objects. For instance, in the case of 2 digitisations on the >>> same set of hits but with different random generators seeds or >>> digitisation parameters, the set of digits are different. So, >>> if hits state includes references to digits, the hits objects >>> are different although the hits are authentically still the same. >>> >>> Digitisation: >>> ------------- >>> An ideal testbed for digits, hits, their management and >>> their relationships would be a digitisation package in Athena. >>> I guess that David Calvet did such a package for Inner Detector. >>> In addition, it could be an opportunity to address concretely >>> the issues on management of AGDD, Magnetic Field and digitisation >>> parameters in Athena. For instance, one can hope that a side effect >>> of such a work could be to cure the sad fact that in Athena, the >>> digitisation parameters have to be hardcoded in reconstruction codes. >>> >>>On Tue, 16 Oct 2001, Steven Goldfarb wrote: >>> >>> >>> >>>>Dear Colleagues, >>>> >>>>I would like to organize a remote meeting (phone conference or VRVS) >>>>next week to discuss the muon event model. Anyone who would like to >>>>participate, should please let me know what days/times DO NOT WORK. >>>>The meeting will be scheduled late in the afternoon, to allow >>>>participation by the Brookhaven group. >>>> >>>>Here is a preliminary agenda: >>>> >>>> o Presentation of proposed Digit Container (D. Adams) >>>> o A few words on planning? (T. Wenaus?) >>>> o Implementation of new ID scheme (S. Goldfarb) >>>> o Discussion of Digit and Hit design (All) >>>> o AOB >>>> >>>>Please let me know of any other topics we could address. Thanks. >>>> >>>>Best Regards, >>>>Steve >>>> >>>>-- >>>>======================================================================== >>>>Steven Goldfarb University of Michigan / ATLAS Experiment >>>>Address: CERN-EP, 1211 Geneve 23, Suisse CERN Office: Bat 40-3-D08 >>>>Phone: +41.22.767.1226 >>>>Fax: +41.22.767.8350 >>>======================================================================== >>>>___________________________________________________________________ >>>>This mail has been sent to all members of the list atlas-muon-sw >>>>___________________________________________________________________ >>>> >>>> >>>> >>>___________________________________________________________________ >>>This mail has been sent to all members of the list atlas-muon-sw >>>___________________________________________________________________ >>> >>> >>>------------------------------------------------------------- >>>Visit this US ATLAS HyperNews message (to reply or unsubscribe) at: >>>http://atlassw1.phy.bnl.gov/HyperNews/get/moore/69/1.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 >> >> >>------------------------------------------------------------- >>Visit this US ATLAS HyperNews message (to reply or unsubscribe) at: >>http://atlassw1.phy.bnl.gov/HyperNews/get/moore/69/1/1.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 ___________________________________________________________________ This mail has been sent to all members of the list atlas-muon-sw ___________________________________________________________________ ------------------------------------------------------------- Visit this US ATLAS HyperNews message (to reply or unsubscribe) at: http://atlassw1.phy.bnl.gov/HyperNews/get/moore/69/1/1/1/1.html