From MAILER-DAEMON Tue Feb 23 09:45:18 1999 Date: Tue, 23 Feb 1999 09:45:18 +0000 (GMT) From: Mail System Internal Data Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA X-IMAP: 0919237826 0000000048 Status: RO This text is part of the internal format of your mail folder, and is not a real message. It is created automatically by the mail system software. If deleted, important folder data will be lost, and it will be re-created with the data reset to initial values. From reichold@al1.physics.ox.ac.uk Tue Feb 16 18:38:06 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Tue, 16 Feb 1999 18:38:06 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10CpNl-0005Pv-00; Tue, 16 Feb 1999 18:38:05 +0000 Received: from oxpc01.fnal.gov (azfar@oxpc01.fnal.gov [131.225.103.10]) by mail.physics.ox.ac.uk id SAA19007; Tue, 16 Feb 1999 18:38:04 GMT Received: from localhost (azfar@localhost) by oxpc01.fnal.gov (8.8.7/8.8.7) with ESMTP id MAA12747; Tue, 16 Feb 1999 12:37:12 -0600 Date: Tue, 16 Feb 1999 12:37:12 -0600 (EST) From: Farrukh Azfar To: Todd Huffman , Armin Reichold Subject: hello Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 1 Hey Guys, I had to skip out of the meeting a bit early (after 1 hour) since I am catching a plane in about 2 hours. the RRL3 discussion will resume later this week, hopefully with Armin in some form of attendance. i) basically, Rob Kennedy has concluded that there is no conflict with the EDM ii) furthermore it is being suggested that Active flags and and Trigger identifiers be removed from the RRL3 and each trigger path will set these via a Talk to in the Trigger init module. For more details on the last two points see (c) and (d) of Chris Greenes e-mail. I think the situation is vastly improved, with regard to the CDF (Confusion Density Factor). Personally I didn't understand how we managed to confuse people in the first place !! Dave should have more details, and the discussion will continue. Your furry friend, Farrukh ------------------------------------------- ba'd az sama' guyi k-an shur-ha kuja shud? ya khud na-bud chizi, ya bud o an fana shud Jalal Ad-Din Rumi From reichold@al1.physics.ox.ac.uk Tue Feb 16 16:09:49 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Tue, 16 Feb 1999 16:09:49 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10Cn4G-0002No-00; Tue, 16 Feb 1999 16:09:48 +0000 Received: from purpc03.fnal.gov (greenc@purpc03.fnal.gov [131.225.107.141]) by mail.physics.ox.ac.uk id QAA16003; Tue, 16 Feb 1999 16:04:01 GMT Received: from localhost (greenc@localhost) by purpc03.fnal.gov (8.9.1a/8.8.7) with ESMTP id KAA04950; Tue, 16 Feb 1999 10:03:15 -0600 X-Authentication-Warning: purpc03.fnal.gov: greenc owned process doing -bs Date: Tue, 16 Feb 1999 10:03:15 -0600 (EST) From: Chris Green To: CDF Event Data Model WG -- Liz Buckley-Geer , dan@fnal.gov, ehafen@fnal.gov, jbk@fnal.gov, kennedy@fnal.gov, Kevin McFarland , leeiv@fnal.gov, murat@fnal.gov, pcalafiura@lbl.gov, rolli@fnal.gov, rs@fnal.gov, sexton@fnal.gov, shapiro@cdfsga.fnal.gov, singh@fnal.gov, Todd Huffman , tamburello@fnal.gov cc: Joe Boudreau , Oxford CDF group -- Armin Reichold , Dr Farrukh Azfar , David Waters , Todd Huffman , Jim Loken Subject: Discussion material: Regional bookkeeping and the EDM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: A X-Keywords: X-UID: 2 Hi, This mail is being sent to the union of the EDM working group and several people who have been exchanging mails in the last week regarding Oxford's proposed scheme for the `management' of regional tracking in Level 3 reconstruction as outlined in CDF-4826 and its impact on and requirements of the EDM. This mail is likely to be fairly long and detailed, but I hope that some of you at least will be able to read and digest it before the EDM meeting at 11.30 this morning. I spent the weekend trying to read and collate the information contained in the many mails which have been flying around. It appears that there were one or two unfortunate cases where `emotive' words were used both in the mails and in the original note ( ``administrate'', ``Bank'' ) where their meaning was unclear or ambiguous. This muddied the waters somewhat, and created the image of serious conflicts between plans for regional tracking management, `RRL3' and both the present EDM and any currently considered future EDM. I therefore try to present below my `take' on the matter having tried to read all the relevant material. Also, just as a thought exercise and to reinforce the idea that there is no conflict whatsoever between RRL3 and the current direction of the EDM discussions, I present below a possible solution for handling at least the persistent part of the regional tracking management within a (hopefully) reasonable extrapolation of current EDM-related discussions to a final solution.. As a quick summary and clarification, the RRL3 object/module/entity is intended to collate information of regional relevance to facilitate regional reconstruction of various types (COT, outside-in, silicon clustering, vertex finding and tracking) from seeds which may be L1/L2 seed objects or even higher level objects like previously reconstructed COT (eg for outside-in tracking). Since some types of reconstruction -- silicon tracking, for example -- depend upon previous results of regional reconstruction (clusters), it is important to maintain a link between the defined regions and the successive results of various reconstruction processes. The catch-all name for the system which handles this has been chosen as RRL3. This will almost certainly *NOT* map onto any one transient or flat/persistent object (`bank') and any previous implication that this might be the case was an unfortunate confusion of the issue. >From CDF 4826, RRL3 contains `entries', which are uniquely identified by two items of information: the seed object, and the region type. It also holds or maintains access (links) to the following items of information: a) A list of reconstruction requests; b) Reconstruction results, including: what type of reconstruction has been done; the region `object'; a silicon strip set; clustered data; reconstructed tracks of various types; (possibly) other high-level physics objects; c) An `active flag', denoting whether a given region should be / is being considered in the current trigger path; d) Trigger identifiers, denoting which triggers are / have been interested in each region. As can be seen, the information to be held has so far been defined only in a very vague way. I see several technical issues related to RRL3 which are directly related to the EDM and persistence: 1) How can the regional information above be accessed from all relevant areas in the event quickly and efficiently? 2) How does one maintain the information and update it where required whilst still holding on to the cherished concepts of reproducibility and traceability at all stages? 3) How is the information kept in persistent storage bearing in mind the above concerns? I do *not* intend to provide specific, code-design-level answers with this mail as to the exact form of the transient representation of this information. Several mails over the last week have focussed on this and the frequently encountered problem of heterogeneous collections. I think Jim's contribution was very useful, and the concept of factories for reconstruction-level objects as used *all over* the code needs to be considered very carefully. In terms of its application to RRL3 though, I think it will be possible to design a system which works within what the EDM is currently evolving towards, and the EDM itself will probably provide a common base class for all persistent or storable objects which will have the properties needed for the efficient storage and treatment of heterogeneous collections. I asked myself the following questions while reading through CDF 4826 and considering it in the context of the EDM discussions: *) Is re-use of regional objects possible or even desirable? *) What does the active flag signify and is it necessary? *) Does an `entry' need to know what triggers are interested in it, or is it sufficient to organise the list of regions by trigger rather than triggers by region? *) Path-killing: when? why? how does it affect entries and the reproducibility of reconstruction results? I left the first question mostly open, although I personally believe that at least the region objects (whatever they are) themselves should be re-usable, even if tracks, electrons, etc, etc, are not. After thinking about the matter for a while, I believe that the `active' flag is *not* necessary. Regional reconstruction modules in a given path should already know (via talk-to?) the class of seed object/region with which they should be concerned, and be able to loop over them all in sequence. Any concept of an `active' flag which is cleared by every path (and therefore cannot easily have its history made persistent) causes serious problems for any EDM scenario considered thus far, and I think these problems can be worked around with talk-tos. Talk-to parameters will be saved as AbsParmSets and therefore the history will persist as desired. So now I try to briefly describe one possible way of saving the required bookkeeping data persistently (almost) within the current EDM. As far as I can tell the only extended features required are ones which have already been discussed: a `hunk ID'/key concept, write-locks on individual hunks, and at least the concept of collections of different types of key (possibly descending from a simple base class). Define a tag Q consisting of: a seed object identifier S (implementation not specified here); a region-type R (implementation not specified here). Stored units (`hunks', cf RDK) thus consist here of units tagged by keys of type Q. Individual units are locked after construction and are therefore consistent with the EDM. A hunk will contain: its own unique unit identifier U; a tag Q; data D; where D can be: a list of reconstruction requests (implementation not specified here); a region object; a list of one or more hunk IDs linking to other regional data (SIXD/ISLD pairs, QSIC/QSIP pairs, track collections etc); Identifiers and tags should therefore be very small as with a system mainly concerned with bookkeeping such as RRL3, they actually make up a significant part of the stored information. I am not sure yet whether one actually needs to save information about which triggers are interested in which regions, but there are three ways of doing this: a) via saved talk-to parameters as described above (information is diffuse and hard to collate); b) small units consisting only of tags (U,Q,T), where T uniquely identifies the trigger (much space (and processing?) overhead); c) The RegionInitModule (see CDF-4826) writing out a unit (U,T,Q1...Qn) for each trigger path; Finally, Armin mentioned the need for all regional reconstruction modules to be able to loop over regions, and raised questions about whether this functionality should be provided by the Framework. In conjunction with this, I wonder whether the RRL3 system should be constructed in a similar way to the geometry system: a `manager' module which sets up objects (possibly singletons like CdfDetector) with carefully managed functionality which can be accessed from the event loop of any module to (say) iterate over all regions, sorted by tags Q. This will require careful thought and much discussion with C++ and Framework experts (Liz) and perhaps Joe as the other main implementor of the geometry system, and I do not presume to short-circuit that process here, merely to jump-start it. Anyway -- this is the current progress of my thoughts on this matter. I hope they are at least specific enough to provide material for discussion, and that they reassure people that nothing is being envisaged for the RRL3 system which will either usurp Framework functions or unduly strain the EDM. Discussion at the 11.30 meeting this morning is welcome should anyone actually have time to read it before then, and of course afterwards also. Cheers, Chris. -- Chris Green. HEP, Purdue University. CDF SVXII project. Based at Fermilab. MAIL greenc@fnal.gov; PHONE (630) 840-2308 From reichold@al1.physics.ox.ac.uk Tue Feb 16 17:29:30 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Tue, 16 Feb 1999 17:29:30 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10CoJN-0004lP-00; Tue, 16 Feb 1999 17:29:29 +0000 Received: from purpc03.fnal.gov (greenc@purpc03.fnal.gov [131.225.107.141]) by mail.physics.ox.ac.uk id RAA17823; Tue, 16 Feb 1999 17:29:09 GMT Received: from localhost (greenc@localhost) by purpc03.fnal.gov (8.9.1a/8.8.7) with ESMTP id LAA15056; Tue, 16 Feb 1999 11:25:43 -0600 X-Authentication-Warning: purpc03.fnal.gov: greenc owned process doing -bs Date: Tue, 16 Feb 1999 11:25:43 -0600 (EST) From: Chris Green To: CDF Event Data Model WG -- Liz Buckley-Geer , dan@fnal.gov, ehafen@fnal.gov, jbk@fnal.gov, kennedy@fnal.gov, Kevin McFarland , leeiv@fnal.gov, murat@fnal.gov, pcalafiura@lbl.gov, rolli@fnal.gov, rs@fnal.gov, sexton@fnal.gov, shapiro@cdfsga.fnal.gov, singh@fnal.gov, Todd Huffman , tamburello@fnal.gov cc: Joe Boudreau , Oxford CDF group -- Armin Reichold , Dr Farrukh Azfar , David Waters , Jim Loken Subject: Re: Discussion material: Regional bookkeeping and the EDM In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 3 Hi, These are comments I just received from Kevin. Cheers, Chris. On Tue, 16 Feb 1999, Kevin McFarland wrote: > > Date: Tue, 16 Feb 1999 11:53:09 -0500 (EST) > From: Kevin McFarland > To: Chris Green > Subject: Re: Discussion material: Regional bookkeeping and the EDM > > Chris, > > This is a comfortingly sane discussion. My comments with some of your > text as necessary. > > >>After thinking about the matter for a while, I believe that the `active' > >>flag is *not* necessary. Regional reconstruction modules in a given path > >>should already know (via talk-to?) the class of seed object/region with > >>which they should be concerned, and be able to loop over them all in > >>sequence. Any concept of an `active' flag which is cleared by every path > >>(and therefore cannot easily have its history made persistent) causes > >>serious problems for any EDM scenario considered thus far, and I think > >>these problems can be worked around with talk-tos. Talk-to parameters > >>will be saved as AbsParmSets and therefore the history will persist as > >>desired. > > As you know, the reason that an active flag was introduced was to avoid > having the tracking module(s) have to know about the details of seed > objects. If tracking is many different modules, each of which need to > know about regions, this solution with talk-tos could become quite > cumbersome. If on the other hand, there is only one module that needs to > know about seeding, then this solution is equivalent to the active flag > solution in talk-to information needed. In my opinion, the active flag > proposl resulted from uncertainty over what the module structure of > tracking would be. If it conflicts with the EDM, then we can either make > it a "special" case, or just swallow whatever additional overhead there > will be to not have it. > > >>So now I try to briefly describe one possible way of saving the required > >>bookkeeping data persistently (almost) within the current EDM. As far as > >>I can tell the only extended features required are ones which have > >>already been discussed: a `hunk ID'/key concept, write-locks on > >>individual hunks, and at least the concept of collections of different > >>types of key (possibly descending from a simple base class). > > As far as I can tell, this (and what follows) is reasonable, and a > faithful implementation of the functionality of our proposal. > > >>Finally, Armin mentioned the need for all regional reconstruction > >>modules to be able to loop over regions, and raised questions about > >>whether this functionality should be provided by the Framework. In > >>conjunction with this, I wonder whether the RRL3 system should be > >>constructed in a similar way to the geometry system: a `manager' module > >>which sets up objects (possibly singletons like CdfDetector) with > >>carefully managed functionality which can be accessed from the event > >>loop of any module to (say) iterate over all regions, sorted by tags > >>Q. This will require careful thought and much discussion with C++ and > >>Framework experts (Liz) and perhaps Joe as the other main implementor of > >>the geometry system, and I do not presume to short-circuit that process > >>here, merely to jump-start it. > > I'm not sure why this is necessary, although it may be convenient. In my > view, this looping should just be a function of the module period. If > talk-tos inform the module that it does global reconstruction (default), > then the meaning of a loop over regions is very clear. Otherwise, one > needs access to the RRL3 information. I'm not sure why a manager is > needed to handle this since the only case outside the RRL3 mileu is the > global case. > > Thanks for taking the time with this, by the way... Hopefully the 11:30 > discussion is sane, and reasonable conclusions that will satisfy Armin are > the result. > > Kevin > > > -- Chris Green. HEP, Purdue University. CDF SVXII project. Based at Fermilab. MAIL greenc@fnal.gov; PHONE (630) 840-2308 From reichold@al1.physics.ox.ac.uk Tue Feb 16 20:35:22 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Tue, 16 Feb 1999 20:35:22 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10CrDG-0003Xt-00; Tue, 16 Feb 1999 20:35:22 +0000 Received: from cdfsga.fnal.gov (cdfsga.fnal.gov [131.225.109.4]) by mail.physics.ox.ac.uk id UAA20387; Tue, 16 Feb 1999 20:35:18 GMT Received: from localhost (dwaters@localhost) by cdfsga.fnal.gov (8.9.0/8.9.0) with SMTP id OAA10159; Tue, 16 Feb 1999 14:35:38 -0600 (CST) Date: Tue, 16 Feb 1999 14:35:38 -0600 (CST) From: David Waters To: Armin Reichold , Chris Green , James Loken , "Todd Huffman (LHC)" , Farrukh Azfar Subject: EDM meeting today. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 4 Hi Armin, I thought you'd probably want to know what was discussed in the EDM meeting today w.r.t. RRL3. Actually relatively little was discussed, and some key people like Marge S. were absent, so we definitely should have a follow-up meeting later this week that you can join in. A few points that came up : [1] "Active flags" in RRL3. As you know, Chris had a number of suggestions for how we might avoid having these. It was generally thought that his suggested solution (c) would be the most appropriate. As I understand it, this means that a list of the types of region which a given trigger path needs to be reconstructed (i.e. marked "active" in the original concept) is pre-defined and in addition stored somewhere for reproducibility. [2] What functionality needs to be provided by the Framework ? As you know, in the current 'prototype' regional tracking code, all the regional stuff is intra-modular, namely loops over the SimpleSiRegionSet. There is no inter-modular coordination required, so we do not need help from the Framework. However, Chris mentioned that in a regional approach to tracking there could in general be inter-dependencies among the different modules (e.g. a track finding module checking the results of the clustering in a particular region) which could in principle need Framework support. [3] Should we wait for the EDM to provide a common base class for persistable or storable objects before embarking on an implementation of RRL3 ? Rob Kennedy says this will take around a month, so it depends on our time schedule. So, this is the current status as I understand it. We should pick up the discussion from here later in the week, - Dave. ******************************************* * Dr. David Waters * * University of Oxford * * Fermilab MS318 * * P.O.Box 500 * * Batavia * * IL 60510-0500, USA * * * * Tel : (USA)-630-840-2147 * * Fax : (USA)-630-840-2968 * * * * E-Mail: dwaters@cdfsga.fnal.gov * ******************************************* From reichold@al1.physics.ox.ac.uk Tue Feb 16 20:44:27 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Tue, 16 Feb 1999 20:44:27 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10CrM2-000230-00; Tue, 16 Feb 1999 20:44:26 +0000 Received: from purpc03.fnal.gov (greenc@purpc03.fnal.gov [131.225.107.141]) by mail.physics.ox.ac.uk id UAA20473; Tue, 16 Feb 1999 20:44:20 GMT Received: from localhost (greenc@localhost) by purpc03.fnal.gov (8.9.1a/8.8.7) with ESMTP id OAA15489; Tue, 16 Feb 1999 14:44:15 -0600 X-Authentication-Warning: purpc03.fnal.gov: greenc owned process doing -bs Date: Tue, 16 Feb 1999 14:44:15 -0600 (EST) From: Chris Green To: David Waters cc: Armin Reichold , James Loken , "Todd Huffman (LHC)" , Farrukh Azfar Subject: Re: EDM meeting today. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: A X-Keywords: X-UID: 5 On Tue, 16 Feb 1999, David Waters wrote: > > Hi Armin, > > I thought you'd probably want to know what was discussed in the EDM > meeting today w.r.t. RRL3. Actually relatively little was discussed, and > some key people like Marge S. were absent, so we definitely should have a > follow-up meeting later this week that you can join in. Hi, I should just briefly add here that Marjorie *was* present by telephone, and did contribute to the discussion (David may not have recognised her voice). Present were: Farrukh Azfar; Chris Green; Elizabeth (Betsy) Hafen (by 'phone); Rob Kennedy (chair); Jim Kowalkowski; Liz Sexton-Kennedy; Prem Singh (left half-way through); Marjorie Shapiro (by 'phone); Rick Snider; David Waters. > A few points that came up : > > [1] "Active flags" in RRL3. As you know, Chris had a number of suggestions > for how we might avoid having these. It was generally thought that his > suggested solution (c) would be the most appropriate. As I understand it, > this means that a list of the types of region which a given trigger > path needs to be reconstructed (i.e. marked "active" in the original > concept) is pre-defined and in addition stored somewhere for > reproducibility. > > [2] What functionality needs to be provided by the Framework ? As you > know, in the current 'prototype' regional tracking code, all the regional > stuff is intra-modular, namely loops over the SimpleSiRegionSet. There is > no inter-modular coordination required, so we do not need help from the > Framework. However, Chris mentioned that in a regional approach to > tracking there could in general be inter-dependencies among the different > modules (e.g. a track finding module checking the results of the > clustering in a particular region) which could in principle need Framework > support. > > [3] Should we wait for the EDM to provide a common base class for > persistable or storable objects before embarking on an implementation of > RRL3 ? Rob Kennedy says this will take around a month, so it depends on > our time schedule. I would seriously advocate finding something to do on this project which doesn't depend on this bottleneck rather than trying to preempt things. > So, this is the current status as I understand it. We should pick up the > discussion from here later in the week, I agree. Rob K should be trying to arrange something for Thursday if you are able to make that. Cheers, Chris. > > - Dave. > > ******************************************* > * Dr. David Waters * > * University of Oxford * > * Fermilab MS318 * > * P.O.Box 500 * > * Batavia * > * IL 60510-0500, USA * > * * > * Tel : (USA)-630-840-2147 * > * Fax : (USA)-630-840-2968 * > * * > * E-Mail: dwaters@cdfsga.fnal.gov * > ******************************************* > -- Chris Green. HEP, Purdue University. CDF SVXII project. Based at Fermilab. MAIL greenc@fnal.gov; PHONE (630) 840-2308 From reichold@al1.physics.ox.ac.uk Wed Feb 17 13:50:04 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Wed, 17 Feb 1999 13:50:04 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10D7Ma-0004fV-00 for reichold@al1.physics.ox.ac.uk; Wed, 17 Feb 1999 13:50:04 +0000 Received: from purpc03.fnal.gov (greenc@purpc03.fnal.gov [131.225.107.141]) by mail.physics.ox.ac.uk id NAA29815 for ; Wed, 17 Feb 1999 13:47:28 GMT Received: from localhost (greenc@localhost) by purpc03.fnal.gov (8.9.1a/8.8.7) with ESMTP id HAA14768 for ; Wed, 17 Feb 1999 07:47:26 -0600 X-Authentication-Warning: purpc03.fnal.gov: greenc owned process doing -bs Date: Wed, 17 Feb 1999 07:47:26 -0600 (EST) From: Chris Green To: "Armin Reichold (LHC)" Subject: Re: Discussion material: Regional bookkeeping and the EDM In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 6 On Wed, 17 Feb 1999, Armin Reichold (LHC) wrote: > Hi Chris, > only read your message now. Could you provide me with a hint as to where I > can find information that explains the concepts of hunks, tags, locking > etc. that you are heavily using. I amnot at all familiar with these - in > fact I have never ever heared the words before. Not even in real language. > Therefore I am still very much in the dark as to what you ment in your > mail and I'll try to comment when I understand more. > Cheers Armin Hi Armin, The first place to look would be the EDM web page, which has links to all the documents, presentations and meeting minutes generated during the current discussions. The meeting minutes are very comprehensive. The URL is: http://www-cdf.fnal.gov/upgrades/computing/projects/edm/edm.html If I were you I would ask to be put on the EDM mailing list. On the web page you will find under a heading `Selected Notes and messages' a link entitled, `Notes on EDM Use-Cases by Rob Kennedy (plain text), 10-11 February 1999' which was actually updated yesterday, probably after the meeting. The minutes for yesterday's meeting will probably appear there some time today. Basically my use of the word `hunk' was as general as possible, describing a small, self-contained unit of persistent data. The dictionary meaning (Webster's New World), is, ``A large piece, lump or slice of bread, meat, etc.'' The meaning of `tag' I was applying here was, ``A card, ticket, plastic marker, etc, tied or attached to something as a label or worn as identification, etc.'' A recurring theme you will find as you follow the EDM discussions through the meetings is the concept of write-locks. That is, once a `hunk' is placed in the event record using some mechanism or other, it cannot be altered in any way -- it becomes read-only. This will apply to persistent *collections* as well as the objects which make up those collections ie once a track set has been placed in the record, it can neither gain nor lose elements, nor can any of those component elements be changed in any way. While thinking of a possible persistent solution for the RRL3 system therefore, I was careful to split the data up into units which would not need to be altered at a later time. That is why the concepts of the `active flag' and the list of interested triggers cause so much trouble. However as you can see from Dave's account of the meeting, it was clear that people thought that solution (c): c) The RegionInitModule (see CDF-4826) writing out a unit (U,T,Q1...Qn) for each trigger path; would be the best way of providing a historical list of the regions required by each trigger. Each regional reconstruction module would then only need to be instructed about the trigger path it was in (talk-to? Ask the Framework?), and be able to read and loop through the list of identifiers of the interesting RRL3 `entries' Qn from the correct unit. I hope this makes things a little clearer. Please do not hesitate to mail me back with any more questions you may have. Cheers, Chris. > ************************************************* > * Dr. Armin Reichold | private: * > * Research Officer | 17 Frys Hill * > * University of Oxford | Oxford * > * Particle & Nuclear Phys. Lab. | OX4 5GW * > * 1 Keble Road | UK * > * Oxford OX1 3RH * > * UK * > * Room 612 * > * * > * Tel.: +44-(0)1865-273358...(office) * > * Tel.: +44-(0)1865-434856...(private) * > * Fax.: +44-(0)1865-273418...(office) * > * E-Mail: a.reichold1@physics.ox.ac.uk * > ************************************************* > > -- Chris Green. HEP, Purdue University. CDF SVXII project. Based at Fermilab. MAIL greenc@fnal.gov; PHONE (630) 840-2308 From reichold@al1.physics.ox.ac.uk Thu Feb 18 15:38:33 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Thu, 18 Feb 1999 15:38:33 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10DVX7-0006RM-00; Thu, 18 Feb 1999 15:38:33 +0000 Received: from cdfsga.fnal.gov (cdfsga.fnal.gov [131.225.109.4]) by mail.physics.ox.ac.uk id PAA18358; Thu, 18 Feb 1999 15:38:04 GMT Received: from localhost (kennedy@localhost) by cdfsga.fnal.gov (8.9.0/8.9.0) with SMTP id JAA24269; Thu, 18 Feb 1999 09:37:54 -0600 (CST) Message-Id: <199902181537.JAA24269@cdfsga.fnal.gov> X-Authentication-Warning: cdfsga.fnal.gov: kennedy@localhost didn't use HELO protocol X-Mailer: exmh version 1.6.6 3/24/96 To: "Armin Reichold (LHC)" cc: kennedy@fnal.gov, pcalafiura@lbl.gov, greenc@fnal.gov, ehafen@fnal.gov, t.huffman1@physics.ox.ac.uk, jbk@fnal.gov, leeiv@fnal.gov, ksmcf@fnal.gov, murat@fnal.gov, rolli@fnal.gov, singh@fnal.gov, tamburello@fnal.gov Cc: dan@fnal.gov, buckley@fnal.gov, sexton@fnal.gov, shapiro@cdfsga.fnal.gov, rs@fnal.gov, dhahn@fnal.gov, s.geddes1@physics.ox.ac.uk, S.Topp-Jorgensen@physics.ox.ac.uk, dwaters@fnal.gov Date: Thu, 18 Feb 1999 09:37:53 CST From: Robert Kennedy Status: RO X-Status: X-Keywords: X-UID: 7 Subject: RRL3 meeting postponed In-reply-to: Your message of "Thu, 18 Feb 1999 14:11:16 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii -------- Hello, Because the video conference details for the RRL3-Infrastructure meeting amongst all the sites were not worked out 24 hours in advance, we will not have the meeting today. Given that this discussion is broader than just the EDM, I am going to ask the I&I folks, Liz S-K and Rick S, to arrange a meeting for next week. Hopefully they will start to make the arrangements now so that this does not happen again. Thanks, Rob K. From reichold@al1.physics.ox.ac.uk Fri Feb 19 08:32:26 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Fri, 19 Feb 1999 08:32:26 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10DlMH-0002kc-00; Fri, 19 Feb 1999 08:32:25 +0000 Received: from al1.physics.ox.ac.uk (al1.physics.ox.ac.uk [163.1.244.73]) by mail.physics.ox.ac.uk id IAA28162; Fri, 19 Feb 1999 08:32:24 GMT Received: from huffman (helo=localhost) by al1.physics.ox.ac.uk with local-smtp (Exim 2.05 #1) id 10DlMG-0000GC-00; Fri, 19 Feb 1999 08:32:24 +0000 Date: Fri, 19 Feb 1999 08:32:24 +0000 (GMT) From: "Todd Huffman (CDF/ATLAS)" To: "Armin Reichold (LHC)" cc: "David S. Waters" , "\"hud-hud-e-jAn\", Farrukh Azfar" , Todd Huffman , Jim Loken , "Matthew Martin (CDF)98" , Tim Hessing , "Dr. Peter Renton" , Louis Lyons Subject: New office, and Strategy remarks. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: "Todd Huffman (LHC),631,73370" Status: RO X-Status: X-Keywords: X-UID: 8 WOW, Armin has a reallly impressive title. My title is just "Deputy Assistant Back-up Courier" You should treat Dee in any case though. --------------------------------------------------------- I have been trying to at least understand the gist of the RRL3 discussions. My only potentially useful comments deal with strategy. Here is my take from the point of view of an outside look. 1). We seem to have encountered a luke-warm reception to regional tracking from Dave's talk. I consider this important. There is no point in having an RRL3 bank if there is no regonal tracking. (Looks like 'bank' may not be politically correct anymore, so take your pick from the following: 'StorableObject', 'record', 'PersistableObject', 'PersistantRecord' whatever is best.) Because of this I think that Dave made a good suggestion, certainly at least he and Jim Loken ought to continue to work on validating Regional tracking with OI tracking and try to move on into a regional SvxCot version with all deliberate speed. (Like my test-pilot-Chuck-Yeager-type language?) Any optimisations that don't require significant re-coding should be done. Optimisations that DO require significant re-coding should wait until we have at least one version of regonal tracking that works to the level required by the collaboration. We should continue to enlist Mat's help in this as well. I would put this program as our #1 priority. 2). RRL3 is a real cross-cultural item as is evident by the flurry of interest, or at least concern, that we have generated. It seems to be intimately tied to the capabilities of the EDM and requires some real EDM/CDF/AC++ gods to make sure that it make sense. We seem to have summoned these deities to first order. Maybe I missed something, but there still seems to be some thinking that RRL3 might actually just end up as part of the capability of the EDM? or has that idea been thrown away? I think we need to get as much help from them as we can in the formation of RRL3. Dave's suggestion of enlisting the help of Jim Kowolski (if he still shows even a remote interest) is a good one. So far Armin is following this quite closely (and Farrukh?), Farrukh had been looking into RRL3 before he took off for Fermilab and should get involved with the intention of ensuring that in the end, RRL3 (or whatever corruption is the right path) does what L3 regional tracking needs. Cheers, Todd ******************************* ~ Dr. B. Todd Huffman ~ ~ Particle and Nuclear Physics~ ~ University of Oxford ~ ~ Rm 631 ~ ~ Keble Rd ~ ~ Oxford OX1 3RH UK ~ ~ ~ ~ Phone: 44 - 1865 - 273402 ~ ~ LMH: 44 - 1865 - 274307 ~ ~ FAX: 44 - 1865 - 273418 ~ ~ Home: 44 - 1865 - 450240 ~ ******************************* From reichold@al1.physics.ox.ac.uk Fri Feb 19 16:24:50 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Fri, 19 Feb 1999 16:24:50 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10DsjR-0006Po-00; Fri, 19 Feb 1999 16:24:49 +0000 Received: from purpc03.fnal.gov (greenc@purpc03.fnal.gov [131.225.107.141]) by mail.physics.ox.ac.uk id QAA06205; Fri, 19 Feb 1999 16:24:25 GMT Received: from localhost (greenc@localhost) by purpc03.fnal.gov (8.9.1a/8.8.7) with ESMTP id KAA20612; Fri, 19 Feb 1999 10:23:53 -0600 X-Authentication-Warning: purpc03.fnal.gov: greenc owned process doing -bs Date: Fri, 19 Feb 1999 10:23:53 -0600 (EST) From: Chris Green To: "Armin Reichold (LHC)" cc: CDF Event Data Model WG -- Liz Buckley-Geer , dan@fnal.gov, ehafen@fnal.gov, jbk@fnal.gov, kennedy@fnal.gov, Kevin McFarland , leeiv@fnal.gov, murat@fnal.gov, pcalafiura@lbl.gov, rolli@fnal.gov, rs@fnal.gov, sexton@fnal.gov, shapiro@cdfsga.fnal.gov, singh@fnal.gov, Todd Huffman , tamburello@fnal.gov, Joe Boudreau , Oxford CDF group -- Dr Farrukh Azfar , David Waters , Jim Loken Subject: Re: Discussion material: Regional bookkeeping and the EDM In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 9 On Thu, 18 Feb 1999, Armin Reichold (LHC) wrote: > Dear Chris, Hi Armin, > having read your auxiliary message I think I am now able to make some > comments on you suggestions below. > > Several mails over the last week have focussed on this and the > > frequently encountered problem of heterogeneous collections. I think > > Jim's contribution was very useful, and the concept of factories for > > reconstruction-level objects as used *all over* the code needs to be > > considered very carefully. > I guess with *all over* you want to say *not just in L3*? Yes, basically anywhere large numbers of objects are being created or destroyed on an ad-hoc basis. > I think the performance advantages (avoiding the heap manager and > fragmentation) that Jim mentioned are most relevant for L3. I would > like to suggest that we definitely try to produce objects that come > and go in large numbers through the life of a job via factories even > if this is a solution that only L3 needs to take. However I think that > the factories we use be at least stereotypical of factories *for > everybody* and should thus be developed in close contact (maybe even > by?) the EDM group. I certainly think there's a case for having at least an agreed structure for what a factory looks like. This also goes hand in hand with discussions I have had with Jim about writing one or two STL allocators with the same goal (ie efficient management of objects on the heap) in mind. > > In terms of its application to RRL3 though, I think it will be > > possible to design a system which works within what the EDM is > > currently evolving towards, and the EDM itself will probably provide > > a common base class for all persistent or storable objects which > > will have the properties needed for the efficient storage and > > treatment of heterogeneous collections. > This does not relate to the factories any more? I'll rephrase this, as it became a little muddled on the journey from brain to fingers: I think it is possible to design a complete RRL3 system which works within what the EDM is currently evolving towards. The EDM itself will probably provide a common base class for all persistent or storable objects which will be a suitable basis for the construction of heterogeneous collections where appropriate. I believe the concept of factories should be dealt with centrally and not just in the context of RRL3. > > I asked myself the following questions while reading through CDF 4826 > > and considering it in the context of the EDM discussions: > > > > *) Is re-use of regional objects possible or even desirable? > With reuse you are addressing the factory approach I guess? Not at all. Here I am talking about whether and in what circumstances the results of regional construction from one context are usable in another context. > > I left the first question mostly open, although I personally believe > > that at least the region objects (whatever they are) themselves should > > be re-usable, even if tracks, electrons, etc, etc, are not. > I agree!! > > After thinking about the matter for a while, I believe that the > > `active' flag is *not* necessary. Regional reconstruction modules in > > a given path should already know (via talk-to?) the class of seed > > object/region with which they should be concerned, and be able to > > loop over them all in sequence. Any concept of an `active' flag > > which is cleared by every path (and therefore cannot easily have its > > history made persistent) causes serious problems for any EDM > > scenario considered thus far, and I think these problems can be > > worked around with talk-tos. Talk-to parameters will be saved as > > AbsParmSets and therefore the history will persist as desired. > I agree with your solution for abolishing the active flag but I also > want to know what it means to talk to every regional module in in > every path in terms of overheads. Is this not a very slow process? Or > does this not hurt us because it is only done at the beginning of the > job? If so, does this mean that we have lots and lots of modules (a > complete set of regional modules for every path) present whereas > without this specialisation we would only need one set for all paths? > I am not sure what this means for the performance or the workload on > the framework. Maybe I misunderstood the concept completely wrong and > you need to teach me even more. The talk-to is simply a way of getting parameters from the command line into a module. This takes place at the beginning of execution at the AC++ prompt. The values of these parameters can be obtained anywhere in the code by using the inlined value() method with zero overhead. You do *not* need a differently coded module for every path. A simple way of doing this would be (using strings for clarity): AbsParmGeneral _ttSeedObjectType; >From the talk-to one would say something like: SeedObjectType set "XFT" The value can subsequently be used in the event loop to only consider RRL3 entries of that type: for (RRL3Iterator i=RRL3.begin(); i!=RRL3.end(); ++i) { if ((*i).seedKey()!=_ttSeedObjectType.value()) continue; . . . } Obviously one would have a restricted set of seed object types from which to choose -- a string gives the user too much freedom to set a garbage value. One would *actually* write an APPCommand, but the above is useful as a proof of principle. > I do not fully understand why the active flag is so much in conflict with > the EDM. I can see that it would violate the write-lock principle if it > changes during an event, but why does it need to be part of the persistent > representation of RRL3 data? It is truly meaningless after a certain path > has finished and it is very easy to reconstruct which path was interested > in which region-type/seed object because of the absParms. The active flag for each entry will change not only in every event, but in every trigger path as you say. If one were to rely on the AbsParmSet as being the repository of the information regarding which path was interested in which region-type/seed object then it does not need to be stored in its own hunk, vis my (c) solution. It's just a matter of how one wants to collate the data for easy access later. The AbsParmSet will contain all sorts of crap. > My comments on the part below are trying to translate from EDM language to > RRL3 language so I make sure that we mean the same thing. > > So now I try to briefly describe one possible way of saving the required > > bookkeeping data persistently (almost) within the current EDM. As far as > > I can tell the only extended features required are ones which have > > already been discussed: a `hunk ID'/key concept, write-locks on > > individual hunks, and at least the concept of collections of different > > types of key (possibly descending from a simple base class). > > > > Define a tag Q consisting of: > > > > a seed object identifier S (implementation not specified here); > > a region-type R (implementation not specified here). > > So the tag is the new word for the RRL3_EntryId? Yes, the tag (or RRL3_EntryId) will uniquely identify an RRL3 entry. > > Stored units (`hunks', cf RDK) thus consist here of units tagged by keys > > of type Q. Individual units are locked after construction and are > > therefore consistent with the EDM. A hunk will contain: > > > > its own unique unit identifier U; > > a tag Q; > > data D; > > > > where D can be: > I would like to modify the above line to: > where D is a list like container of : > > a list of reconstruction requests (implementation not specified here); > > a region object; > > a list of one or more hunk IDs linking to other regional data > > (SIXD/ISLD pairs, QSIC/QSIP pairs, track collections etc); > and I'd like to modify the above 4 lines to: > several unique unit identifiers U > these unit identifiers point us to: > a list of reconstruction requests > a region object; > any other regional result data > (QSIC/QSIP pairs (I dont know what they are, cluster banks, track > collections etc); > Your hunk, so it seems to me, was not meant to be our RRL3_Entry but rather > a way of attaching a tag Q to anything that could end up in the event > record. To me this seems unnecessary since the data D does not need to > know about the tag. Only an RRL3_entry needs to know what data (results) > it contains. This is why I modified your proposal. NO NO NO NO NO NO NO! The point is that the persistent version of an RRL3 entry *cannot* be a single entity because once a storable item is placed in the record (which it must be to be passed between modules) it can no longer be altered. An RRL3 entry must therefore be persistently stored as *several* hunks. Each hunk will be characterised by: *) its own HunkID (to preserve the nomenclature for now) to identify what sort of information it contains; *) The tag Q to identify the RRL3 entry to which this hunk belongs; *) The data, where this could be either: +) a list of reconstruction requests; +) the geometrical region definition (or HunkID of same); +) one or more hunkIDs which point to the regional data one wishes to associate via an RRL3 entry. For instance, one may have hunks (schematically speaking) for each seed object/region type Q: { {"RRL3_RecoReqList",n} Q {"Clustering","COT","OI","SI"} } { {"RRL3_Region",n} Q { Furthermore I think you forgot a piece of data here, namely the part > that stores how much of the reconstruction request has already been > satisfied. (Or in other words the fact that the reconstruction request > is not so much a request as a status indicator). This, in the same way > as the active flag, is changing during the event and I think it is > needed. Please allow me an example: > > If a clustering module should run inside a region than it would of > course be possible for future clustering modules to check if it has > done so by checking if a link to cluster data exists in RRL3 for this > region. However if the cluster module did not find clusters it will > not make a cluster bank (this probably happens more often with > tracking modules and track sets) and any future clustering module will > just try again. So this part of RRL3 can not be "put into the event > record" once and then write locked. But I do not know if it would need > to be there anyway. We can reconstruct the temporal sequence of which > module did satisfy which request at what time by simply reconstructing > which modules where in the paths in which sequence (trigger table?) > and what there parameters were. Then we run the job again and get the > same answer as during L3. But maybe this is too simplistic? One can obtain the same effect by writing an empty hunk: { {"RRL3_TrackList",n} Q {ReconstructionType} {} } or { {"RRL3_ClusterData",n} Q {} } I am seriously against passing anything between modules which has not been write-locked. Admittedly were there no other way of passing the information in this case, one *may* be able to make the case that passing this data between modules does not affect reproducibility. However, there is a fine line between considering exceptions on a case-by-case basis and opening the door to widespread abuse. Here, one can avoid trying a failed reconstruction process by noting the presence of an empty hunk so we don't need to strain the EDM. Comments Rob, Marjorie? > > Identifiers and tags should therefore be very small as with a system > > mainly concerned with bookkeeping such as RRL3, they actually make up a > > significant part of the stored information. > This is an important point in my view. > > I am not sure yet whether one actually needs to save information about > > which triggers are interested in which regions, but there are three ways > > of doing this: > > > > a) via saved talk-to parameters as described above (information is > > diffuse and hard to collate); > > > > b) small units consisting only of tags (U,Q,T), where T uniquely > > identifies the trigger (much space (and processing?) overhead); > > > > c) The RegionInitModule (see CDF-4826) writing out a unit (U,T,Q1...Qn) > > for each trigger path; > I think storing which trigger was interested in which region is only > needed if someone wants to use this during analysis. It does not influence > the way the L3 program would run. Fine, but this may be interesting. One should not preclude the possibility of doing this later, though. > > Finally, Armin mentioned the need for all regional reconstruction > > modules to be able to loop over regions, and raised questions about > > whether this functionality should be provided by the Framework. In > > conjunction with this, I wonder whether the RRL3 system should be > > constructed in a similar way to the geometry system: a `manager' > > module which sets up objects (possibly singletons like CdfDetector) > > with carefully managed functionality which can be accessed from the > > event loop of any module to (say) iterate over all regions, sorted > > by tags Q. This will require careful thought and much discussion > > with C++ and Framework experts (Liz) and perhaps Joe as the other > > main implementor of the geometry system, and I do not presume to > > short-circuit that process here, merely to jump-start it. > I only brought this idea up to show how "un-framework-like" such a loop > would be. I would like to agree with Kevin here that this loop is really an > intra module task and very clearly reconstructable at any later time. I agree here also. > In summary: > > - Sorry the comments are so long. Not at all. We need to have a clear idea of everyone's thoughts in order to eventually converge on the best system for the job -- this goes for both the EDM and the RRL3 system. > - Factories are good. > (should develop widely usable and fast ones) I agree, but this should not be an RRL3 feature but a generally available one wherever appropriate. If the RRL3 folks develop one and make it generally applicable and available, however ... > - unique identifiers U are our way to link persistent results into RRL3 See my clarifications of my intended use of identifiers and tags above. > - I either disagree about the concept of your hunk or I do not understand > how I can build an RRL3 entry out of them. For example the RRL3 never > needs to know about the SIXD/SILD banks. There is only ever one of them > and it is not a results of the recontruction but an input to it. My mention of SIXD/ISLD was a mistake. The conceptual problem I had was that you mentioned storing unclustered regional SiStripSets at some point in the past. Currently the persistent version of an SiStripSet *is* and ISLD/SIXD pair, so I was confused. One would have to develop a new persistent representation specific to a regional SiStripSet were one to want to do this. > - The recontruction request needs to be called recontructin status and it > changes during the event. No. See my comments above. > - we have no way of linking changing objects into the RRL3 yet as they > could not be hunks I'm not sure what your last comment here means. The Q tag ties together all the different hunks comprising an RRL3 entry. I don't see the problem. As for ``linking changing objects into RRL3'', one will never be able to do this, which is why the information needs to be broken down into smaller entities which do not change. These entities are either there, or they aren't. Cheers, Chris. > > > Cheers Armin > -- Chris Green. HEP, Purdue University. CDF SVXII project. Based at Fermilab. MAIL greenc@fnal.gov; PHONE (630) 840-2308 From reichold@al1.physics.ox.ac.uk Fri Feb 19 16:45:54 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Fri, 19 Feb 1999 16:45:54 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10Dt3q-00009X-00 for reichold@al1.physics.ox.ac.uk; Fri, 19 Feb 1999 16:45:54 +0000 Received: from cdfsga.fnal.gov (cdfsga.fnal.gov [131.225.109.4]) by mail.physics.ox.ac.uk id QAA06637; Fri, 19 Feb 1999 16:45:48 GMT Received: from localhost (dwaters@localhost) by cdfsga.fnal.gov (8.9.0/8.9.0) with SMTP id KAA07408; Fri, 19 Feb 1999 10:45:32 -0600 (CST) Date: Fri, 19 Feb 1999 10:45:31 -0600 (CST) From: David Waters To: Chris Green cc: "Armin Reichold (LHC)" , Jim Loken Subject: Re: Some questions from a slow learner. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: A X-Keywords: X-UID: 10 I'll display my ignorance by asking a few C++ questions : > > > Several mails over the last week have focussed on this and the > > > frequently encountered problem of heterogeneous collections. I think > > > Jim's contribution was very useful, and the concept of factories for > > > reconstruction-level objects as used *all over* the code needs to be > > > considered very carefully. By factory you mean a pattern whereby the virtual creation of auxilliary objects in a base class is overloaded in the derived classes. Is this right ? This seems to me quite separate from the concept of a heterogeneous container. Please explain the relevance of factories. > I think it is possible to design a complete RRL3 system which works > within what the EDM is currently evolving towards. The EDM itself will > probably provide a common base class for all persistent or storable > objects which will be a suitable basis for the construction of > heterogeneous collections where appropriate. I believe the concept of > factories should be dealt with centrally and not just in the context of > RRL3. But if there's a common base class, a heterogeneous collection is exactly what you *don't* need ! Any old container will do. Cheers, Dave. From reichold@al1.physics.ox.ac.uk Tue Feb 9 17:39:13 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Tue, 9 Feb 1999 17:39:13 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10AH7w-00013N-00 for reichold@al1.physics.ox.ac.uk; Tue, 9 Feb 1999 17:39:12 +0000 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.9.8]) by mail.physics.ox.ac.uk id RAA07117; Tue, 9 Feb 1999 17:39:00 GMT Received: from b0nd18.fnal.gov ("port 19894"@b0nd18.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.1-12 #3998) with SMTP id <01J7JEAXNVMS0006CI@FNAL.FNAL.GOV>; Tue, 9 Feb 1999 11:38:57 -0600 CDT Received: from localhost by b0nd18.fnal.gov via SMTP (950413.SGI.8.6.12/940406.SGI) id LAA11462; Tue, 09 Feb 1999 11:37:58 -0600 Date: Tue, 09 Feb 1999 11:37:57 -0600 (CST) From: Liz Sexton-Kennedy Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers In-reply-to: "Your message of Tue, 09 Feb 1999 12:50:28 CST." To: "Armin Reichold (LHC)" Cc: jbk@fnal.gov, kennedy@fnal.gov, shapiro@cdfsga.fnal.gov, "ELIZABETH S. SEXTON KENNEDY" , "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Mat Martin , t.hessing1@physics.ox.ac.uk, Todd Huffman , "David S. Waters" , Christopher Henry Green , Kevin McFarland , Alfred Lee , snider@al1.physics.ox.ac.uk, Joseph Boudreau , rs@fnal.gov Message-id: <199902091737.LAA11462@b0nd18.fnal.gov> Status: RO X-Status: A X-Keywords: X-UID: 11 > From Armin: > > Dear experts, > I would like to consult all of you concerning your opinion on a decision > that we (Oxford and the L3 tracking people) have to make very soon. It is > about the RRL3 (Results and Regions (Banks) for Level 3 triggers, see > http://b0urpc01.fnal.gov/~ksmcf/Results_and_Regions.ps for details. > I have little experience in design questions and would like to get an > overview of what limitations or problems, advatages and blessing our > proposed design choice would inflict on us. > > > The problem I would like to ask you about is the following: > > For each L3 trigger region (this is a simplification) RRL3 will store > and administer many different objects such as the region itself, the > triggers that requested them, the silicon clusters, any tracks found, L2 > objects (calo clusters or muon stubs etc.). All of these objects sound to me like EVENT! objects, I don't think RRL3 should be admistering it. Banks are supposed to be some of the dumbest objects in the system not the smartest. This is just one of the problems I have with the proposal you all outlined in your CDF note. > > The class of these objects, how many of them and in which mixture is not > per se predictable and will vary from trigger to trigger and from event to > event. > > The container that is supposed to hold all of them thus has the difficult > task of conaining apples, pears, cows and cars which is not easy for a > container. > > > We hope to solve this problem by making all of the classes that we would > like to store derive from a possibly modified version of Al Lees' > cloneable class (see TrackingUtils/GenericC++Examples/clonable and vectorc > directories with good readme files for details) which would allow the > container (a vectorc = vector of cloneables) to do what we wish (or at > least we think so). > However, a lot of classes would have to derive from cloneable and thus > this choice may affect more people then just the L3 crowd. We need your > opinions in such a decision before we can seek agreement for our proposal > and make it part of the official code. We would be very gratefull if you > could help us a little by commenting on this. Maybe you could cc your > answers to all recipients of this mail as to encourage a little bit of > discussion. > Yes of course this is the classic heterogenious collection class problem and in order to solve it you have to involve everyone writing reconstruction software. The right place for these discussions is at the EDM meetings. I do not think it will be possible to discuss this via e-mail. From reichold@al1.physics.ox.ac.uk Wed Feb 10 07:13:39 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Wed, 10 Feb 1999 07:13:39 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10ATq6-0001jj-00; Wed, 10 Feb 1999 07:13:38 +0000 Received: from kfesg.lbl.gov (kfesg.lbl.gov [128.3.2.46]) by mail.physics.ox.ac.uk id HAA12525; Wed, 10 Feb 1999 07:13:31 GMT Received: from localhost (shapiro@localhost) by kfesg.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id VAA00423; Tue, 9 Feb 1999 21:33:05 -0800 Date: Tue, 9 Feb 1999 21:33:05 -0800 (PST) From: Marjorie Shapiro To: Liz Sexton-Kennedy cc: "Armin Reichold (LHC)" , jbk@fnal.gov, kennedy@fnal.gov, shapiro@cdfsga.fnal.gov, "ELIZABETH S. SEXTON KENNEDY" , "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Mat Martin , t.hessing1@physics.ox.ac.uk, Todd Huffman , "David S. Waters" , Christopher Henry Green , Kevin McFarland , Alfred Lee , snider@al1.physics.ox.ac.uk, Joseph Boudreau , rs@fnal.gov Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers In-Reply-To: <199902091737.LAA11462@b0nd18.fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: A X-Keywords: X-UID: 12 I would like to second Liz Sexton's comment that the issues raised by the recent email on the RRL3 bank are general concerns of the event data model (EDM) and not really Level-3 specific issues. Just to get people talking, let me make some observations. Please feel free to disagree: 1) The RRL3 bank seems to be serving several different purposesat once: - Control of Level 3 flow - Specification of parameters needed by algorithms - Storage of processing history It seems to me it would be a real advantage to separate these functions rather than lumping them together. Moreover, some of these functions can probably be more appropriately addressed in a more general context (see items 2-4 below) 2) One of the main purposes of AC++ is to provide flow control for the modules. I haven't yet understood why this control is not adequate for Level 3. But if there is a problem, I would rather augment AC++ than introduce a Level-3 specific mechanism for flow control. What deficiencies in AC++ are you trying to solve with the RRL3 bank and its associated infrastructure? 3) One of the most important features the physics groups have demanded is that we be able to keep track of and reproduce exactly the processing done in Level 3 and production. This means we cannot allow any hysteresis to creep into the system. I believe this means we cannot allow modules to overwrite numbers in banks that were created by earlier modules. I therefore have a real problem with the clearing of status words in RRL3 every path. Wouldn't it make more sense for each path to create its own RRL3? 4) Since Level 3 many need to use any reconstruction object, Level 3 really cannot require that the objects it uses be derived from a Level 3 specific base class. It seems to me that what you really are asking for is that the EDM provide a general collection class that allows you to make lists (or vectors) of persistable objects and tag them by a unique key (for example the trigger name or the path name or the module instance). I believe this is a reasonable request to make to Rob K. We need this functionality in many, many places in the system. We really should setup a meeting (with video) to discuss these questions as part of the EDM group. I'll ask Rob Kennedy to contact Armin about scheduling this. Marjorie On Tue, 9 Feb 1999, Liz Sexton-Kennedy wrote: > > From Armin: > > > > Dear experts, > > I would like to consult all of you concerning your opinion on a decision > > that we (Oxford and the L3 tracking people) have to make very soon. It is > > about the RRL3 (Results and Regions (Banks) for Level 3 triggers, see > > http://b0urpc01.fnal.gov/~ksmcf/Results_and_Regions.ps for details. > > I have little experience in design questions and would like to get an > > overview of what limitations or problems, advatages and blessing our > > proposed design choice would inflict on us. > > > > > > The problem I would like to ask you about is the following: > > > > For each L3 trigger region (this is a simplification) RRL3 will store > > and administer many different objects such as the region itself, the > > triggers that requested them, the silicon clusters, any tracks found, L2 > > objects (calo clusters or muon stubs etc.). > > All of these objects sound to me like EVENT! objects, I don't think > RRL3 should be admistering it. Banks are supposed to be some of the dumbest > objects in the system not the smartest. This is just one of the problems > I have with the proposal you all outlined in your CDF note. > > > > > > The class of these objects, how many of them and in which mixture is not > > per se predictable and will vary from trigger to trigger and from event to > > event. > > > > The container that is supposed to hold all of them thus has the difficult > > task of conaining apples, pears, cows and cars which is not easy for a > > container. > > > > > > We hope to solve this problem by making all of the classes that we would > > like to store derive from a possibly modified version of Al Lees' > > cloneable class (see TrackingUtils/GenericC++Examples/clonable and vectorc > > directories with good readme files for details) which would allow the > > container (a vectorc = vector of cloneables) to do what we wish (or at > > least we think so). > > However, a lot of classes would have to derive from cloneable and thus > > this choice may affect more people then just the L3 crowd. We need your > > opinions in such a decision before we can seek agreement for our proposal > > and make it part of the official code. We would be very gratefull if you > > could help us a little by commenting on this. Maybe you could cc your > > answers to all recipients of this mail as to encourage a little bit of > > discussion. > > > Yes of course this is the classic heterogenious collection class > problem and in order to solve it you have to involve everyone writing > reconstruction software. The right place for these discussions is at the > EDM meetings. I do not think it will be possible to discuss this via e-mail. > From reichold@al1.physics.ox.ac.uk Wed Feb 10 13:00:16 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Wed, 10 Feb 1999 13:00:16 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10AZFX-0000LT-00 for reichold@al1.physics.ox.ac.uk; Wed, 10 Feb 1999 13:00:16 +0000 Received: from pas.rochester.edu (qmailr@alfalfa.pas.rochester.edu [128.151.144.13]) by mail.physics.ox.ac.uk id MAA18483 for ; Wed, 10 Feb 1999 12:59:28 GMT Received: (qmail 7962 invoked by uid 568); 10 Feb 1999 12:58:30 -0000 Date: Wed, 10 Feb 1999 07:58:30 -0500 (EST) From: Kevin McFarland To: Marjorie Shapiro cc: Liz Sexton-Kennedy , "Armin Reichold \(LHC\)" , Christopher Henry Green , Kirsten Tollefson , kennedy@fnal.gov Subject: RRL3 and AC++/EDM In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 13 Hello All, Although Armin has done an excellent job in his previous note, please allow me to try to further clarify a few points here. As Armin has said, we *definitely* believe these issues are tied up intimately with the data model. Unfortunately, few of us involved in the work can attend the meetings for practical reasons (no critism of Rob's organizing effort implied! trying to participate remotely is just often too difficult, particularly with large time differences and meetings that don't have an established place on the schedule hierarchy), but one of us can and has actively participated, namely Chris. I am confident that Chris has kept the RRL3 case in mind during the discussions, and I don't see any direction being chosen by the EDM group that does not allow us to proceed with the RRL3 work. As Kirsten pointed out in the January offline meeting where the Level-3 schedule and WBS was discussed, the EDM schedule does delay somewhat the RRL3 ("Regional Framework" development); thus Armin is knocking on the door, so to speak, and trying to get a preview of how to proceed. Although the RRL3 specification memo is very convoluted because we were trying to address every use case possible for all the regional tracking algorithms, the RRL3 spec only addresses one of Marjorie's three functions. >> - Control of Level 3 flow >> - Specification of parameters needed by algorithms >> - Storage of processing history Specifically, it is only meant to store processing history in a way that can be used by other modules executed in the same event. The complicated design is *precisely* to avoid hysteresis and to avoid duplication with AC++ functionality. Believe us, we are keenly aware of these problems! Best, Kevin ************************************************************************ Kevin McFarland at Fermilab: Fermilab MS 318, PO Box 500 Office: B&L 152 Batavia, IL 60510-0500 Department of Physics and Astronomy (630)840-3500, (630)840-3266 University of Rochester FAX: (630)840-2968 Rochester, NY 14627 Office: B0 Trailers, 168-M (716)275-7076, FAX (716)275-8527 ************************************************************************ From reichold@al1.physics.ox.ac.uk Wed Feb 10 15:59:18 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Wed, 10 Feb 1999 15:59:18 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10Ac2n-0000pJ-00 for reichold@al1.physics.ox.ac.uk; Wed, 10 Feb 1999 15:59:18 +0000 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.9.8]) by mail.physics.ox.ac.uk id PAA21463 for ; Wed, 10 Feb 1999 15:57:03 GMT Received: from fnal.gov ("port 1064"@d-cd-65.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.1-12 #3998) with ESMTP id <01J7KP03OTCG0000I8@FNAL.FNAL.GOV> for a.reichold1@physics.oxford.ac.uk; Wed, 10 Feb 1999 09:56:29 -0600 CDT Date: Wed, 10 Feb 1999 09:55:28 -0600 From: Jim Kowalkowski Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers To: "Armin Reichold (LHC)" Cc: Marjorie Shapiro , Liz Sexton-Kennedy , "Armin Reichold (LHC)" , kennedy@fnal.gov, shapiro@cdfsga.fnal.gov, "ELIZABETH S. SEXTON KENNEDY" , "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Mat Martin , t.hessing1@physics.ox.ac.uk, Todd Huffman , "David S. Waters" , Christopher Henry Green , Kevin McFarland , Alfred Lee , snider@al1.physics.ox.ac.uk, Joseph Boudreau , rs@fnal.gov Message-id: <36C1ABF0.DA3FF1AA@fnal.gov> Organization: Computing Division MIME-version: 1.0 X-Mailer: Mozilla 4.04 [en] (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: Status: RO X-Status: A X-Keywords: X-UID: 14 Hi Armin, Armin Reichold (LHC) wrote: > > 1) The RRL3 bank seems to be serving several different purposesat once: > > a) Control of Level 3 flow > > b) Specification of parameters needed by algorithms > > c) Storage of processing history > on a) > In the sense of AC++ RRL3 does not control the flow of the execution of > modules in the various trigger paths of L3. Every module will still run in > every path. The task of a modul is somehow different though. In our > proposal every module allways loops over all "regions" it is supposed to > process. If it finds that region has allready been processed by itself, > the loop iteration will simply ignore it. So we are controlling intra > module execution not inter module flow which as I understand is not part > of AC++. Is that correct? I'm still trying to get a handle on the problem. Does this mean that paths contains large AC++ modules, such that if I peek inside one, I see a bunch on sub-modules (not AC++ ones, but similar concept)? If so, then does the large AC++ module coordinate the flow of event data to the sub-modules based on information inside the RRL3 object? > > 2) One of the main purposes of AC++ is to provide flow control for the > > modules. I haven't yet understood why this control is not adequate for > > Level 3. But if there is a problem, I would rather augment AC++ than > > introduce a Level-3 specific mechanism for flow control. What > > deficiencies in AC++ are you trying to solve with the RRL3 bank and its > > associated infrastructure? > As I tried to say in the beginning, RRL3 is not trying to control flow on > the module level but on the "loop over regions in the module"-level. This > may sound a bit pedantic but it may indicate the this loop should be moved > out of the modules into AC++ in which case a, say clusering module would > run in a AC++ controlled loop over all regions and thus AC++ would be in > control. Are you indicating that you would like the "loop over regions in the module"-level submodules to become full AC++ modules? > > Wouldn't it make more sense for each path to create its own RRL3? > I don't think it would. The nature of RRL3 is, to say it once more, not > that of bank. It is a register that orders banks. The main point of this > register is that is provides a pool for everyone to announce results for a > certain region and to be able to tell everyone whether a certain result is > allready available or rather whether a certain request has allready been > fullfilled. This sounds a lot like issues that the EDM group is dealing with increating transient objects that can be stored in the AC++ event object. The RRL3 object, in the context you describe above, appears to me to be supporting state machine concepts that are relevant to level 3. I guess I think of AC++ as a sort-of data flow architecture (the event flows through a series of modules in the simplest case). Level 3 seems more like a real state machine, and most state machines really need support for a global scoreboard/register/status objects. This is all based on my limited knowledge of the system. I hope I'm not rambling too much here needlessly. > > > > 4) Since Level 3 many need to use any reconstruction object, Level 3 > > really cannot require that the objects it uses be derived from a Level 3 > > specific base class. It seems to me that what you really are asking for > > is that the EDM provide a general collection class that allows you to make > > lists (or vectors) of persistable objects and tag them by a unique key > > (for example the trigger name or the path name or the module instance). > > I believe this is a reasonable request to make to Rob K. We need this > > functionality in many, many places in the system. > I could not agree more with this. You have correctly summarised what an > RRL3_Entry is supposed to do. It has an Identifier and a Container. I only > suggested "our own" aproach because I was not aware that this may be > something that would be popular outside L3-regional tracking. We "want" it > very urgently though, so this was driving us maybe a bit more than the > others. It seems to me that organization of the keys, the container, and thesearch methods are very important here if high performance is crucial. Especially if level 3 modules are going to bang on this general collection object a lot.Jim -- Jim Kowalkowski - jbk@fnal.gov D0: 630/840-2215 - 5th floor of the D0 assembly building CDF: 630/840-6457 - 169F in the CDF trailers http://www-cdf.fnal.gov/internal/people/links/JamesKowalkowski/my.html http://www-d0.fnal.gov/~jbk/index.html From reichold@al1.physics.ox.ac.uk Wed Feb 10 19:06:16 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Wed, 10 Feb 1999 19:06:16 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10Aexk-00043X-00; Wed, 10 Feb 1999 19:06:16 +0000 Received: from cdfsga.fnal.gov (cdfsga.fnal.gov [131.225.109.4]) by mail.physics.ox.ac.uk id TAA24726; Wed, 10 Feb 1999 19:06:11 GMT Received: from localhost (kennedy@localhost) by cdfsga.fnal.gov (8.9.0/8.9.0) with SMTP id NAA13267; Wed, 10 Feb 1999 13:06:25 -0600 (CST) Message-Id: <199902101906.NAA13267@cdfsga.fnal.gov> X-Authentication-Warning: cdfsga.fnal.gov: kennedy@localhost didn't use HELO protocol X-Mailer: exmh version 1.6.6 3/24/96 To: "Armin Reichold (LHC)" cc: Marjorie Shapiro , jbk@fnal.gov, kennedy@fnal.gov, "ELIZABETH S. SEXTON KENNEDY" , "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Mat Martin , t.hessing1@physics.ox.ac.uk, Todd Huffman , "David S. Waters" , Christopher Henry Green , Kevin McFarland , Alfred Lee , Joseph Boudreau , rs@fnal.gov, kennedy@cdfsga.fnal.gov Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers In-reply-to: Your message of "Wed, 10 Feb 1999 09:23:17 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Feb 1999 13:06:25 CST From: Robert Kennedy Status: RO X-Status: A X-Keywords: X-UID: 15 > > 3) One of the most important features the physics groups have demanded is > > that we be able to keep track of and reproduce exactly the processing done > > in Level 3 and production. This means we cannot allow any hysteresis to > > creep into the system. I believe this means we cannot allow modules to > > overwrite numbers in banks that were created by earlier modules. I > > therefore have a real problem with the clearing of status words in RRL3 > > every path. > The clearing of status words in this case I think does not present the > potential for histeresis. It is the "deactivation" of all entries in the > beginning of each trigger path. This actually makes sure that there is no > hysteresis in the system. Every path starts from scratch in the sense that > it will only "activate" those regions that are of interest for this > trigger and then only ever look into those regions during reconstruction. > I must admit that the sentecte on page 7 of the RRL3 note that describes > this not only has a typo in it but is also very confusing. > So in summary the resetting of this status bit is there to avoid > hysteresis. The other "status" parts are all dealing with the sotrage of > processing hitory Hello, The EDM proposal (and it is still just an icompletely written proposal "in committee") states that once any object is stored, the stored form of the object is read-only. This is one of a few policies to avoid the hysteresis we are concerned about. We have not done this in the past (YBOS banks were read-write scratchpads wherever they are), and will have some work to do in order to adapt existing code to this approach. Nevertheless, this is the simplest approach we have come up with that is enforceable at run-time to insure that the processing history of each object in the event is well-understood. D0's Event Data Model uses this approach too. I would be invaluable, for me at least, to see the grand concept RRL3 broken down into component parts which we understand can obey this policy. In some cases we have to rethink our objects to accomplish this, since the obvious transient object classes are not restricted by this read-only policy. Nevertheless this may help our discussions since we will be able to identify and separate the grand RRL3 abstraction and the storable representation... at least at the design concept level. A simple example is a circular list. The transient form is fine, but a direct translation of that to the storable form is impossible since the policy prevents circular link (persistent pointer) chains. The adaptation of the circular list is to store the list node data as objects and then store a list summary object which contains links to all the list nodes. Or just store the list in a storable STL vector of list nodes. Also soted with the object is the ID of the module and its parameter set. Yes, there is some overhead for translating the transient and storable formats (which can be minimized with some technology), but now there is no chance that another module will come along and "secretly" change a few numbers in the list. If you want to change a number in it, you have to make your own copy, store that copy with a different object ID (bank number) and module/parameter set ID. From discussions so far, we understand that the EDM will need to support a few collection classes ! ! so that others can re-use the transforms from/to transient collections to/from stored collections. Thanks, Rob K. From reichold@al1.physics.ox.ac.uk Thu Feb 11 14:54:45 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Thu, 11 Feb 1999 14:54:45 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10AxVt-0006Xa-00 for reichold@al1.physics.ox.ac.uk; Thu, 11 Feb 1999 14:54:45 +0000 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.9.8]) by mail.physics.ox.ac.uk id OAA06356 for ; Thu, 11 Feb 1999 14:54:33 GMT Received: from fnal.gov ("port 1185"@ogre.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.1-12 #3998) with ESMTP id <01J7M14PM2IY0000WN@FNAL.FNAL.GOV> for a.reichold1@physics.oxford.ac.uk; Thu, 11 Feb 1999 08:54:26 -0600 CDT Date: Thu, 11 Feb 1999 08:53:32 -0600 From: Jim Kowalkowski Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers To: "Armin Reichold (LHC)" Message-id: <36C2EEEC.CBC29C66@fnal.gov> Organization: Computing Division MIME-version: 1.0 X-Mailer: Mozilla 4.04 [en] (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: Status: RO X-Status: A X-Keywords: X-UID: 16 Armin, Did you find my long email about containers useful? Is this the sort of thing you were looking for? Do you need further information? Jim Armin Reichold (LHC) wrote: > > It seems to me that organization of the keys, the container, and thesearch > > methods are very important here if high performance is crucial. > > Especially if level 3 modules are going to bang on this general > > collection object a lot.Jim > I agree, the logical makeup of the key is simple. It is just the ID of the > type of region combined with the ID of object that seeded the region. How > to translate this into an efficient key, I don't know yet. I know very > little about the efficiency problems involved with this and I would be > very happy if you could keep an open ear for my questions and advise us on > efficiency problems. -- Jim Kowalkowski - jbk@fnal.gov D0: 630/840-2215 - 5th floor of the D0 assembly building CDF: 630/840-6457 - 169F in the CDF trailers http://www-cdf.fnal.gov/internal/people/links/JamesKowalkowski/my.html http://www-d0.fnal.gov/~jbk/index.html From reichold@al1.physics.ox.ac.uk Fri Feb 5 21:02:13 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Fri, 5 Feb 1999 21:02:13 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 108sOC-0001lk-00; Fri, 5 Feb 1999 21:02:13 +0000 Received: from einstein.phy.duke.edu (root@einstein.phy.duke.edu [152.3.182.4]) by mail.physics.ox.ac.uk id VAA22992; Fri, 5 Feb 1999 21:02:10 GMT Received: from dukheu.phy.duke.edu (leeiv@dukheu.phy.duke.edu [152.3.57.28]) by einstein.phy.duke.edu (8.8.8/8.8.8) with ESMTP id QAA21098; Fri, 5 Feb 1999 16:02:05 -0500 (EST) Received: from localhost (leeiv@localhost) by dukheu.phy.duke.edu (8.8.5/8.8.5) with SMTP id QAA06677; Fri, 5 Feb 1999 16:02:04 -0500 (EST) X-Authentication-Warning: dukheu.phy.duke.edu: leeiv owned process doing -bs Date: Fri, 5 Feb 1999 16:02:04 -0500 (EST) From: Alfred Lee To: "Armin Reichold (LHC)" cc: "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Mat Martin , t.hessing1@physics.ox.ac.uk, Todd Huffman , "David S. Waters" , Christopher Henry Green , Kirsten Tollefson , Kevin McFarland Subject: Re: Lee's clonable class In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: A X-Keywords: X-UID: 17 Dear Armin, The clonable (and related VectorC vector of clonables - class) live in the TrackingUtils/GenericC++Examples/clonable and vectorc directories. The purpose of these classes are simple: provide a generic interface which allows copy construction of of a class that is otherwise specified only by an abstract interface. The VectorC class allows the same copy semantics as the STL vector class (copies are added to the vector, not pointers to objects whose memory is controlled elsewhere), for classes that obey the clonable interface (they don't actually have to inherit from it to work). This allows sets of different objects that obey that inherit from the same clonable interface to be stored in the the VectorC list. I don't believe either of these classes is used anywhere in the code directly. The interface does lack a "downcasting" function, e.g., whoAreYou() that returns a string with the name of the concrete class behind the interface may be useful. This is easily added, however, it probably isn't needed. If RTTI is enabled (which I think is the CDF default), then one can just attempt safe dynamic casting of an object in a set to see if it is the type you need, rather than getting a string and then deciding to cast based on that. As I mention in the comments, there is nothing magical about the clone class; it is a fairly straight forward implementation of the general idea of "virtual constructors" as is described in Stroustrup (15.6.2 of 3rd edition of "The C++ Language"). It may well be a good idiom for the collection class you want. If you look at mytest.cc in the vectorc directory, you may get some idea how it could work. All that is missing from the example is a line like Asub * pHeresOne = dynamic_cast(&supervector[1]) if (!pHeresOne) { cout << "Dynamic cast to Asub failed" << endl; } to show how dynamic_casting would work (dynamic_cast returns 0 if the cast fails). I hope this helps. Cheers, Al On Fri, 5 Feb 1999, Armin Reichold (LHC) wrote: > Hi Al, > I hope you still have a little bit of time left to look at a C++ problem > these days, if not - don't worry - just let me know and ignore the > following. > I have, by accident bumped into your clonable class in the example area. > It seems rather old (from g++ days) and I wonder whether you have given up > on this completely or if it is currently used in CDF code anywhere. > > We, oxford L3 group, may have an application for this but I am not realy > sure that I understand what this realy does. So may I try to tell you what > problem I had in mind for the application and you could tell me if your > clonable would be good basis for solving it? > > We are about to design a class which is supposed to collect and organise > the results obtained during regional tracking for L3. This will require > storing references to a lot of different classes which all can form parts > of the reconstruction chain (clusters, COT tracks, calo-showers, > track-sets, etc.) and we would like to avoid having to hardwire all > combinations of these objects that should be stored togehter. We would > much rather like to have a very lightweight base class that that all these > objects could inherit from and thus we store them by their base class > types. However, since they are very different beasts we would need to be > able to turn them into what they realy are when we manipulate the data > they contain. Or at least they should tell us what they realy are so we > can cast them or copy them or god nows what. Your cloneable classes seem > to provide a lot of this functionality (if I undertand them correctly) > > Could you advise us a little bit on that? > > Cheers Armin > > ************************************************* > * Dr. Armin Reichold | private: * > * Research Officer | 17 Frys Hill * > * University of Oxford | Oxford * > * Particle & Nuclear Phys. Lab. | OX4 5GW * > * 1 Keble Road | UK * > * Oxford OX1 3RH * > * UK * > * Room 612 * > * * > * Tel.: +44-(0)1865-273358...(office) * > * Tel.: +44-(0)1865-434856...(private) * > * Fax.: +44-(0)1865-273418...(office) * > * E-Mail: a.reichold1@physics.ox.ac.uk * > ************************************************* > > From reichold@al1.physics.ox.ac.uk Mon Feb 8 14:14:37 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Mon, 8 Feb 1999 14:14:37 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 109rSN-0003Sh-00; Mon, 8 Feb 1999 14:14:35 +0000 Received: from einstein.phy.duke.edu (root@einstein.phy.duke.edu [152.3.182.4]) by mail.physics.ox.ac.uk id OAA15974; Mon, 8 Feb 1999 14:14:14 GMT Received: from dukheu.phy.duke.edu (leeiv@dukheu.phy.duke.edu [152.3.57.28]) by einstein.phy.duke.edu (8.8.8/8.8.8) with ESMTP id JAA08626; Mon, 8 Feb 1999 09:14:00 -0500 (EST) Received: from localhost (leeiv@localhost) by dukheu.phy.duke.edu (8.8.5/8.8.5) with SMTP id JAA12945; Mon, 8 Feb 1999 09:13:59 -0500 (EST) X-Authentication-Warning: dukheu.phy.duke.edu: leeiv owned process doing -bs Date: Mon, 8 Feb 1999 09:13:59 -0500 (EST) From: Alfred Lee To: "Armin Reichold (LHC)" cc: "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Louis Lyons , Mat Martin , "Peter B. Renton" , t.hessing1@physics.ox.ac.uk, Todd Huffman , "David S. Waters" , Christopher Henry Green , Frederick Snider , Joseph Boudreau , Kevin McFarland Subject: Re: Lee's clonable class In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 18 Dear Armin, You could also run design ideas past Jim Kowalkowski (jbk@fnal.gov). He is a computing professional working with CDF and DO, and generally has good OO design ideas. Rob Kennedy (kennedy@fnal.gov) and Liz Sexton-Kennedy (sexton@fnal.gov) are also good people for design stuff; they are the physicist/programmers who are developing AC++ and Trybos, among other things, for CDF. Cheers, Al On Mon, 8 Feb 1999, Armin Reichold (LHC) wrote: > Hi Al, > thank you very much for your detailed message. I think we will consider > the cloneable aproach in our container for RRL3. I'll bring the subject up > tomorrow in our group meeting. I would also like to get some more opinion > from other OO experts (Rick, Chris, Joe who else?) to find out if there > are any problems with this aproach. After all this may become a key > feature of the RRL3 entries class. > > Cheers Armin > > > ************************************************* > * Dr. Armin Reichold | private: * > * Research Officer | 17 Frys Hill * > * University of Oxford | Oxford * > * Particle & Nuclear Phys. Lab. | OX4 5GW * > * 1 Keble Road | UK * > * Oxford OX1 3RH * > * UK * > * Room 612 * > * * > * Tel.: +44-(0)1865-273358...(office) * > * Tel.: +44-(0)1865-434856...(private) * > * Fax.: +44-(0)1865-273418...(office) * > * E-Mail: a.reichold1@physics.ox.ac.uk * > ************************************************* > > On Fri, 5 Feb 1999, Alfred Lee wrote: > > > Dear Armin, > > > > The clonable (and related VectorC vector of clonables - class) live > > in the TrackingUtils/GenericC++Examples/clonable and vectorc directories. > > The purpose of these classes are simple: provide a generic interface > > which allows copy construction of of a class that is otherwise specified > > only by an abstract interface. The VectorC class allows the same copy > > semantics as the STL vector class (copies are added to the vector, not > > pointers to objects whose memory is controlled elsewhere), for > > classes that obey the clonable interface (they don't actually have to > > inherit from it to work). This allows sets of different objects that > > obey that inherit from the same clonable interface to be stored in the > > the VectorC list. > > > > I don't believe either of these classes is used anywhere in the code > > directly. The interface does lack a "downcasting" function, e.g., > > whoAreYou() that returns a string with the name of the concrete class > > behind the interface may be useful. This is easily added, however, > > it probably isn't needed. If RTTI is enabled (which I think is the CDF > > default), then one can just attempt safe dynamic casting of an object > > in a set to see if it is the type you need, rather than getting a string > > and then deciding to cast based on that. > > > > As I mention in the comments, there is nothing magical about the clone > > class; it is a fairly straight forward implementation of the general idea > > of "virtual constructors" as is described in Stroustrup (15.6.2 of 3rd > > edition of "The C++ Language"). It may well be a good idiom for the > > collection class you want. If you look at mytest.cc in the vectorc > > directory, you may get some idea how it could work. All that is missing > > from the example is a line like > > > > Asub * pHeresOne = dynamic_cast(&supervector[1]) > > if (!pHeresOne) { > > cout << "Dynamic cast to Asub failed" << endl; > > } > > > > to show how dynamic_casting would work (dynamic_cast returns 0 if the cast > > fails). I hope this helps. > > > > Cheers, > > > > Al > > > > On Fri, 5 Feb 1999, Armin Reichold (LHC) wrote: > > > > > Hi Al, > > > I hope you still have a little bit of time left to look at a C++ problem > > > these days, if not - don't worry - just let me know and ignore the > > > following. > > > I have, by accident bumped into your clonable class in the example area. > > > It seems rather old (from g++ days) and I wonder whether you have given up > > > on this completely or if it is currently used in CDF code anywhere. > > > > > > We, oxford L3 group, may have an application for this but I am not realy > > > sure that I understand what this realy does. So may I try to tell you what > > > problem I had in mind for the application and you could tell me if your > > > clonable would be good basis for solving it? > > > > > > We are about to design a class which is supposed to collect and organise > > > the results obtained during regional tracking for L3. This will require > > > storing references to a lot of different classes which all can form parts > > > of the reconstruction chain (clusters, COT tracks, calo-showers, > > > track-sets, etc.) and we would like to avoid having to hardwire all > > > combinations of these objects that should be stored togehter. We would > > > much rather like to have a very lightweight base class that that all these > > > objects could inherit from and thus we store them by their base class > > > types. However, since they are very different beasts we would need to be > > > able to turn them into what they realy are when we manipulate the data > > > they contain. Or at least they should tell us what they realy are so we > > > can cast them or copy them or god nows what. Your cloneable classes seem > > > to provide a lot of this functionality (if I undertand them correctly) > > > > > > Could you advise us a little bit on that? > > > > > > Cheers Armin > > > > > > ************************************************* > > > * Dr. Armin Reichold | private: * > > > * Research Officer | 17 Frys Hill * > > > * University of Oxford | Oxford * > > > * Particle & Nuclear Phys. Lab. | OX4 5GW * > > > * 1 Keble Road | UK * > > > * Oxford OX1 3RH * > > > * UK * > > > * Room 612 * > > > * * > > > * Tel.: +44-(0)1865-273358...(office) * > > > * Tel.: +44-(0)1865-434856...(private) * > > > * Fax.: +44-(0)1865-273418...(office) * > > > * E-Mail: a.reichold1@physics.ox.ac.uk * > > > ************************************************* > > > > > > > > > > > > From reichold@al1.physics.ox.ac.uk Wed Feb 10 17:11:18 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Wed, 10 Feb 1999 17:11:18 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10AdAU-00013t-00 for reichold@al1.physics.ox.ac.uk; Wed, 10 Feb 1999 17:11:18 +0000 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.9.8]) by mail.physics.ox.ac.uk id RAA22733; Wed, 10 Feb 1999 17:05:17 GMT Received: from fnal.gov ("port 1084"@d-cd-65.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.1-12 #3998) with ESMTP id <01J7KRDKDYBG0000HN@FNAL.FNAL.GOV>; Wed, 10 Feb 1999 11:04:32 -0600 CDT Date: Wed, 10 Feb 1999 11:03:35 -0600 From: Jim Kowalkowski Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers To: "Armin Reichold (LHC)" Cc: kennedy@fnal.gov, "ELIZABETH S. SEXTON KENNEDY" , "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Mat Martin , t.hessing1@physics.ox.ac.uk, Todd Huffman , "David S. Waters" , Christopher Henry Green , Kevin McFarland , Alfred Lee , snider@al1.physics.ox.ac.uk, Joseph Boudreau Message-id: <36C1BBE7.5F848B33@fnal.gov> Organization: Computing Division MIME-version: 1.0 X-Mailer: Mozilla 4.04 [en] (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: Status: RO X-Status: A X-Keywords: X-UID: 19 Armin Reichold (LHC) wrote: > The container that is supposed to hold all of them thus has the difficult > task of conaining apples, pears, cows and cars which is not easy for a > container. > > We hope to solve this problem by making all of the classes that we would > like to store derive from a possibly modified version of Al Lees' > cloneable class (see TrackingUtils/GenericC++Examples/clonable and vectorc > directories with good readme files for details) which would allow the > container (a vectorc = vector of cloneables) to do what we wish (or at > least we think so). > However, a lot of classes would have to derive from cloneable and thus > this choice may affect more people then just the L3 crowd. We need your > opinions in such a decision before we can seek agreement for our proposal > and make it part of the official code. We would be very gratefull if you > could help us a little by commenting on this. Maybe you could cc your > answers to all recipients of this mail as to encourage a little bit of > discussion. Armin, Just a few notes on technical issues concerning heterogeneous containers. If you get bored reading it before you reach (5), then skip to (5) and look at it briefly. As Al Lee's example shows, it is very easy to create container of dissimilar objects by using a base class where all things are derived from and stored in something like this: vector hetero_container; There is a couple of problems associated with this: ------------------- 1) As you said, everyone must have this base class visable and present in their code - this is understood well enough. ------------------- 2) In the simplest case, one would fill the container with three different things like this assuming the Cow, Pig, Horse are all derived from BasicObject): hetero_container.push_back(new Cow); hetero_container.push_back(new Pig); hetero_container.push_back(new Horse); When is time to clean up the container, the owner of it must loop through all the stuff inside it and do a "delete" on each item. vector::iterator iter = hetero_container.begin() while(iter!=hetero_container.end()) delete *iter; If the heap is used in this fashion, there will be a performance penalty. The heap is known not to be fast. Also, using the heap in this fashion could cause memory fragmentation leading to degradation in performance (presuming the process runs for a long time). We can fix this situation by using object instance pools, where we manage freelists of commonly used objects such as Cows, Pigs, and Horses. Now the code becomes (assuming a simple templated solution to the pool problem): hetero_container.push_back(Factory::make()); hetero_container.push_back(Factory::make()); hetero_container.push_back(Factory::make()); and the clean up becomes: vector::iterator iter = hetero_container.begin() while(iter!=hetero_container.end()) FactoryAdmin::destroy(*iter); Factories can help out a lot in these cases. I prefer using factories over cloning - if cloning would be used to create new instances of object only. Factories can be set up in many ways - where a simple call like BasicObject* obj1 = Factory::make("COW"); BasicObject* obj2 = Factory::make("PIG"); Notice that this code is not coupled at compile time to the class Cow or Pig. Setting this up is a bit more difficult and in the case above, does require a string look-up to create the correct object. (The code here is really just for illustrative purposes only) -------------------- 3) From the messages and notes I've been reading, it seems likely that access to the things in the vector will be through a key - probably involving strings: map hetero_container; Now we introduced more potential performance problems. a) Is can be expensive to put an item into a map, remember that it is a complex tree structure that maintains the relationships between Keys and BasicObjects. b) Searching is good, but not great for applications that require maximum performance and will be looking in here a lot. Seaching requires a Key comparison, and if key is a string, then this is not fast. c) Cleanup of the map is expensive. d) The pointers in the map are subject to the same problems as the vector. How can performance be improved? Use factories/pools for creating/destroying objects instead of the heap. Fix the location or slot where a particular Key and associated object will be stored at the beginning of the job. Add a method called "int getSlotID(Key)". This method can be called by modules during job initialization and the slot id recorded can be recorded. If the module needs to use or access the object associated with the key, the slot_id can be used instead. Of couse the slot_id would be implemented as a direct index into an array of BasicObject pointers. This would be the fastest way to get at the object. ----------------- 4) Finding based on type of object. Many times users want to find an object in the hetero_container above by type, such as "give_me_the_first_object_of_type" This is going to be slow and if this is part of the required access pattern needed, then special things must be done if performance is critical. I'll assume this is not important. ----------------------------- 5) There is an alternative to using a Base class for all objects stored in the container. Do this (by no means is this a complete implementation): // support class class AnyObject { AnyObject(); ~virtual AnyObject(); ... } // support class - wrapper for object template class SpecificObject : AnyObject { SpecificObject(T* d):obj(d) { } ... static T* get(AnyObject x); static void put(AnyObject x, T*); T* d; } // utility to extract stuff template int find(map& h, Key k, T*& d) { map::iterator iter = h.find(k); if(iter==h.end()) return error message - not found if( (d=dynamic_cast(iter->second)) == 0) { // not the correct type, return an error! } else return success } // utility to put stuff in template int insert(map& h, Key k, T* d) { // check if key inside container already h[k]=new SpecificObject(d); } // ----------------------example user application---------------- // collection of anything with key map hetero_container; insert(hetero_container,"MYCOW",new Cow); insert(hetero_container,"MYPIG",new Pig); insert(hetero_container,"MYHORSE", new Horse); Cow* cow; find(hetero_container,"MYCOW",cow); // pull out MYCOW Pig* pig; find(hetero_container,"MYPIG",pig); // pull out MYPIG Notice that the Cow, Pig, and Horse do not need to be derived from anything. ------------------------- There are just a couple of items to keep in mind, you may be using some of them already. It is all I can think of at the current time. I'm not yet sure which, if any, apply to the problems you are solving. Jim -- Jim Kowalkowski - jbk@fnal.gov D0: 630/840-2215 - 5th floor of the D0 assembly building CDF: 630/840-6457 - 169F in the CDF trailers http://www-cdf.fnal.gov/internal/people/links/JamesKowalkowski/my.html http://www-d0.fnal.gov/~jbk/index.html From reichold@al1.physics.ox.ac.uk Thu Feb 11 16:44:04 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Thu, 11 Feb 1999 16:44:04 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10AzDa-0007fK-00; Thu, 11 Feb 1999 16:44:03 +0000 Received: from cdfsga.fnal.gov (cdfsga.fnal.gov [131.225.109.4]) by mail.physics.ox.ac.uk id QAA08367; Thu, 11 Feb 1999 16:37:02 GMT Received: from localhost (kennedy@localhost) by cdfsga.fnal.gov (8.9.0/8.9.0) with SMTP id KAA14916; Thu, 11 Feb 1999 10:36:28 -0600 (CST) Message-Id: <199902111636.KAA14916@cdfsga.fnal.gov> X-Authentication-Warning: cdfsga.fnal.gov: kennedy@localhost didn't use HELO protocol X-Mailer: exmh version 1.6.6 3/24/96 To: "Armin Reichold (LHC)" cc: Robert Kennedy , "Armin Reichold (LHC)" , Marjorie Shapiro , jbk@fnal.gov, kennedy@fnal.gov, "ELIZABETH S. SEXTON KENNEDY" , "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Mat Martin , t.hessing1@physics.ox.ac.uk, Todd Huffman , "David S. Waters" , Christopher Henry Green , Kevin McFarland , Alfred Lee , Joseph Boudreau , rs@fnal.gov, kennedy@cdfsga.fnal.gov Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers In-reply-to: Your message of "Thu, 11 Feb 1999 15:51:21 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Feb 1999 10:36:28 CST From: Robert Kennedy Status: RO X-Status: A X-Keywords: X-UID: 20 Hello, Here are some of the quick answers to your questions: > Dear Rob, > also to you thanks for updating us on the status of the EDM w.r.t. our > RRL3 problems. Here are my comments > > > > The clearing of status words in this case I think does not present the > > > potential for histeresis. It is the "deactivation" of all entries in the > > > beginning of each trigger path. This actually makes sure that there is no > > > hysteresis in the system. Every path starts from scratch in the sense that > > > it will only "activate" those regions that are of interest for this > > > trigger and then only ever look into those regions during reconstruction. > > > I must admit that the sentecte on page 7 of the RRL3 note that describes > > > this not only has a typo in it but is also very confusing. > > > So in summary the resetting of this status bit is there to avoid > > > hysteresis. The other "status" parts are all dealing with the sotrage of > > > processing hitory > > > Hello, > The EDM proposal (and it is still just an icompletely written proposal > "in committee") states that once any object is stored, the stored form > of the object is read-only. > I have two questions here: > 1. Stored referes to the status of the object after a call to write > persistent? > 2. read-only last only until the next event when a new RRL3 is > constructed? This would exclude the alternative of "resetting" RRL3 > every event and we really have to create a new one. But only if RRL3 is > seen as a bank which ends up beeing written. It may be that only a > small fraction of RRL3 stored associations get written. Stored refers to the state of the object when it is in the Event Record (its data format may be similar to transient form except pointers replaced by links, or it may be quite different like Banks). Persistent refers to the state when it is written to disk (its data format is an encoded byte stream). The separation of these two concepts has been made to clarify how we will make storing and read/writing of object simpler for developers by pushing the "stored" format as close to the transient format as reasonably possible. Yes, the read-only status of stored objects lasts until the next event, as far as the user modules are concerned. > > This is one of a few policies to avoid the > hysteresis we are concerned about. We have not done this in the past > (YBOS banks were read-write scratchpads wherever they are), and will > have some work to do in order to adapt existing code to this approach. > Nevertheless, this is the simplest approach we have come up with that is > enforceable at run-time to insure that the processing history of each > object in the event is well-understood. D0's Event Data Model uses this > approach too. > I would be invaluable, for me at least, to see the grand concept RRL3 > broken down into component parts which we understand can obey this > policy. > I think this is exactly our next job. We have to brake RRL3 down into its > classes and associated banks and then show that we can comply to this > policy. Agreed. > > In some cases we have to rethink our objects to accomplish this, > since the obvious transient object classes are not restricted by this > read-only policy. Nevertheless this may help our discussions since we > will be able to identify and separate the grand RRL3 abstraction and the > storable representation... at least at the design concept level. > So RRL3 will be first broken down into the part of it which needs to be > stored in the event history and thus has to comply to the rules of read > only after first write persistent. And the part which is the transient > scratchpad organiser that should just be reset every event. Good first step. > > A simple example is a circular list. The transient form is fine, but a > direct translation of that to the storable form is impossible since the > policy prevents circular link (persistent pointer) chains. The > adaptation of the circular list is to store the list node data as > objects and then store a list summary object which contains links to all > the list nodes. Or just store the list in a storable STL vector of list > nodes. > Most of the actual data that will be arranged into RRL3 allready exists > (or will very soon) in storable form. I.e. the TrackSets or ClusterData. > Some don't yet have a bank representation like the regions themselves or > the L3 trigger path identifiers. These will get one soon. > The biggest problem will be the storable form of the "link", i.e. the > information that a certain L3-trigger Id and a certain cluster data are > associated or linked to a region and a seed. The transient form of this is > the RRL3_Entry which has this heterogeneous container I keep hoping for. > It stores pointers or references. The persistant version of it is not > clear to me. Somehow I must be able to find a unique identifier for any > object that was linked into an entry and made persistent. Our current plan is to use (what we also call "links") a StorableObjectLink == (object name, object number) which are unique throughout the lifetime of an event. In Run 1, the equivalent thing was a bank name, number pair. This uniqueness is a change from Run 1 when we enforced it only at the moment an object was inserted into an event. Bank numbers could be re-used, which confused objects which meant to link to the old bank and not the new one. We are trying to provide a much more robust link at the expense of having to adapt existing code to this new scheme. This is part of your solution.... > > Also soted with the object is the ID of the module and its > parameter set. > I am not sure I undertand fully what you mean here. Do you say that if a > module wants to write a bank it has to store a list of all its parameters > with the bank? This refers to storing a simple ID number in each "bank" which can be mapped (if desired) to a module name and a parameter set. We have called this AbsParms in Infrastructure design. D0 calls it RCP Ids. The parameters themselves will be stored in the BeginRun record (as in Run 1) and/or in a database. Users who want to ask "who created a bank and under what conditions" use this ID number as a key to query AC++ and/or a database for the information. Note that so far we (and D0) leave it up to the developer to decide whether to store and maintain this module/parameter ID in a bank. As with version numbers, there is no plan yet for a mechanism to force this to be done. > Yes, there is some overhead for translating the transient > and storable formats ... > formats of what? The bank or the module parameter list that is attached to > the bank? I am referring to the format of the bank, or more generally the format of the future generalization of banks. We want to generalize banks to permit storage of C++ objects that contain data members. In the EventRecord though, we do not permit objects that contain pointers (a few other restrictions too), so transient (unstored) objects must be translated to the stricter format in order to be stored. For instance, we now have to translate a nice C++ class like TowerCollection into a different (stupid) format, TOWE_Bank, in order to store towers. We are trying to reduce the overhead of this translation and the development and maintenance time to create vastly different transient and storable formats. > ... (which can be minimized with some technology), but > now there is no chance that another module will come along and > "secretly" change a few numbers in the list. If you want to change a > number in it, you have to make your own copy, store that copy with a > different object ID (bank number) and module/parameter set ID. From > discussions so far, > > we understand that the EDM will need to support a > few collection classes !! so that others can re-use the transforms > from/to transient collections to/from stored collections. > Yes, a collection suitable of transiently holding all sorts of storable > objects which, when made persitent itself, will not store the objects it > contains but will store some form of the links to them. The EDM will supply "storable" forms of some basic data structures. There are only a few needed, I think, since the storable forms do not require the variety in space/time trade-offs and data structure model that transient collections need. Developers can specialize by derivation, or specialize using them as examples of implementation. The EventRecord itself will be such a specialization. Collections by value and by reference are planned, as well as classes to support storage of heterogenous collections. > I must say that I feel very much that I am out of touch with the ideas and > vocabulary behind the EDM. I realy need to attend some of your meetings > to catch up and if I can't come maybe you can fill your knowledge into one > of Oxford Group so I can be breast fed from them. > > > Cheers Armin The ideas and vocabulary in the EDM are evolving rapidly as we are coming to some consensus on the trade-off between backwards-compatibility, future robustness, and developer productivity. The paper describing the current plan is behind schedule, but a draft is due out in the next few days. So, you are probably not the only one who feels this way. We do hope to bring everyone up to speed by next week, beginning with the EDM meeting on Tuesday 16-Feb 11:30 CST, followed by the Offline meeting, and the RR in L3 meeting Marge and/or I are arranging. Thanks, Rob K. From reichold@al1.physics.ox.ac.uk Thu Feb 11 17:14:10 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Thu, 11 Feb 1999 17:14:10 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10Azgo-0001FV-00; Thu, 11 Feb 1999 17:14:10 +0000 Received: from cdfsga.fnal.gov (cdfsga.fnal.gov [131.225.109.4]) by mail.physics.ox.ac.uk id RAA09047; Thu, 11 Feb 1999 17:12:21 GMT Received: from localhost (kennedy@localhost) by cdfsga.fnal.gov (8.9.0/8.9.0) with SMTP id LAA10322; Thu, 11 Feb 1999 11:12:30 -0600 (CST) Message-Id: <199902111712.LAA10322@cdfsga.fnal.gov> X-Authentication-Warning: cdfsga.fnal.gov: kennedy@localhost didn't use HELO protocol X-Mailer: exmh version 1.6.6 3/24/96 To: "Armin Reichold (LHC)" cc: Robert Kennedy , "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Todd Huffman , "David S. Waters" , kennedy@cdfsga.fnal.gov Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers In-reply-to: Your message of "Thu, 11 Feb 1999 17:06:54 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Feb 1999 11:12:30 CST From: Robert Kennedy Status: RO X-Status: X-Keywords: X-UID: 21 Hello, OK. I will do what I can to provide a laymen explanation. At the same time, I do need to provide the "legal-eze" expert description in to be sure this is all self-consistent... and this will slip into my general conversation from time to time. Hopefully folks will catch this and help point it out to me, as you have. Thanmks, Rob K. From reichold@al1.physics.ox.ac.uk Thu Feb 11 17:14:45 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Thu, 11 Feb 1999 17:14:45 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10AzhM-0007IS-00 for reichold@al1.physics.ox.ac.uk; Thu, 11 Feb 1999 17:14:44 +0000 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.9.8]) by mail.physics.ox.ac.uk id RAA09040 for ; Thu, 11 Feb 1999 17:11:54 GMT Received: from fnal.gov ("port 1059"@d-cd-65.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.1-12 #3998) with ESMTP id <01J7M5WTTJT40000WX@FNAL.FNAL.GOV> for a.reichold1@physics.oxford.ac.uk; Thu, 11 Feb 1999 11:11:40 -0600 CDT Date: Thu, 11 Feb 1999 11:10:44 -0600 From: Jim Kowalkowski Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers To: "Armin Reichold (LHC)" Cc: Alfred Lee , Rob kennedy Message-id: <36C30F14.397BCA96@fnal.gov> Organization: Computing Division MIME-version: 1.0 X-Mailer: Mozilla 4.04 [en] (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: Status: RO X-Status: A X-Keywords: X-UID: 22 Armin, I'm only sending this to you. If you want to forward it, that is fine, I'm just not sure if everyone wants to hear this or not. Here are responses to your questions. This is a difficult subject to discuss in detail using email. I have running code that is in use that illustrates everything that I talk about. If fact, every performance critical application I've even done uses many of these techiques, esspecially management of object pools so the default new/delete memory manager does not get used once the program reaches a stable state. Jim Armin Reichold (LHC) wrote: > Hi Jim, > here are a few more questions about heterogeneous container problems you > mentioned > > > > As Al Lee's example shows, it is very easy to create container of > > dissimilar objects by using a base class where all things are derived from > > and stored in something like this: > > vector hetero_container; > > > > There is a couple of problems associated with this: > > > > ------------------- > > 1) As you said, everyone must have this base class visable and > > present in their code - this is understood well enough. > I hope it is, how bad a problem is this really. We would -in the worst > case- simply create Level3 versions of the classes we needed which did > nothing more but: > > class L3_CDF_TrackSet > public: CDF_TrackSet, clonable > } > } > > we only need to do this for a few classes that we want to group inside > RRL3. It's not that bad, it just causes coupling that many people might not like. > > If the heap is used in this fashion, there will be a performance > > penalty. The heap is known not to be fast. Also, using the > > heap in this fashion could cause memory fragmentation > > leading to degradation in performance (presuming the process > > runs for a long time). > I was not aware of these performance problems at all. Is this a realy big > drawback? We are currently relying a lot on pointers to heap stored in stl > containers for look up tables to navigate with regions in the detector. > They are singletons and live forever, thus fragmentation is probably not a > problem, but what about the performance and why is the heap slow (for a > laymen please) Using the heap is of essential and fine. The performance problems Iam speaking of occur when you continually make use of default new and delete in an application as it's running - for example, building up a large heterogeneous container using default new, and clearing it using default delete for each of the events processed. It's the calls to malloc/free within default new/delete that are expensive, not using the memory on the heap - it's aquiring the memory from the heap manager that is costly. Also, the heap manager is made to work for the general case, which means fragmentation should be a concern. > > call like > > BasicObject* obj1 = Factory::make("COW"); > > BasicObject* obj2 = Factory::make("PIG"); > > > > Notice that this code is not coupled at compile time to the > > class Cow or Pig. Setting this up is a bit more difficult and > > in the case above, does require a string look-up to create the > > correct object. > > But this still assumes that COW and PIG both inherit from basic object? In this example yes. In general, the factory or pool manager would returnan object of the specific type. > So if COWs where CDF_Tracks and PIGs were ClusterData then both of them > would have to inherit from basic object, say RRL3able and basic object > must provide a mytype() function which would allow us to find out if we > actually got a Track or Cluster Data. In how far, other than the actuall > object sitting on the stack since they are created in the factory without > operator new, does this differ from the situation in which BasicObject is > replced with clonable? Yes, in this method you would be required to register the name associatedwith the object in the factory so that it would know which thing it should create in a call to make().The difference is that the factory or pool manager creates and owns a poolof buffers that it uses to create new objects from - instead of going to the default heap manager. As objects are deleted by the user, they go back to a freelist held by the pool manager. Since all the buffers are the same size, it is very fast to get one off the free list for use in creating the requested instance. > > > > c) Cleanup of the map is expensive. > I don't understand why? Of course I am talking about the STL map here...The map I put in the example has pointers toobjects and instances of keys. To clean it up requires a call to default delete (the heap manager), running the destructors of the object (expensive because calls are through the virtual destructor mechanism, basically a pointer to a function), and the destructor of the key to be called (if it is not a primitive data type). This occurs for each item in the map. Not only that, but the map has a complex indexing hierarchy of pointers, nodes, and keys that must be dismantled piece by piece as the elements are removed during the cleanup process. The map is a complex data structure, it is made to give fast, predictable search times given an arbitrary key. This of course means it cannot possibly be optimal for a specific type of key or access pattern. A map is not just an indexed lookup, it is a tranversal of an index tree - I believe its perforance is O(nlogn) but I could be slightly off here. > > > > d) The pointers in the map are subject to the same problems as the > > vector. > You mean they are pointes to heap? Yes, but it's not the heap memory that is the problem, it's the callto default new/delete using the heap manager to aquire/return the memory to/from the heap. > > > > How can performance be improved? Use factories/pools for > > creating/destroying objects instead of the heap. Fix the location or > > slot where a particular Key and associated object will be stored > > at the beginning of the job. Add a method called "int getSlotID(Key)". > > This method can be called by modules during job initialization and the > > slot id recorded can be recorded. If the module needs to use or > > access the object associated with the key, the slot_id can be used > > instead. Of couse the slot_id would be implemented as a direct > > index into an array of BasicObject pointers. This would be the > > fastest way to get at the object. > But how can I do this if I don;t know: > a) what keys I am going to get in any event, since I can't predict all > seed objects and region type combinations > b) how many keys a module should reserve > If I understand you correctly you want to anticipate all keys that I could > ever have and then translate it into a slotID at the beginning of the run? > A clustring module only gets its keys which describes what data to > read or where to store its results, at the beginning of each event. I am > confused here. How should I apply this? This is of course just an idea here and a solution in some cases. To elaborate a bit, as each of the submodules (or modules) that will interact with the RRL3 object (for example) comes alive, it announces the key and perhaps the object it will be using (or creating). It does this by calling performing a registration procedure in a singleton utility class associated with the RRL3 object - SubModReco1: id1 = RRL3_Registry::instance()->IwillUse("KEY1"); id2 = RRL3_Registry::instance()->IwillUse("KEY2"); ... SubModReco2: id1 = RRL3_Registry::instance()->IwillUse("KEY2"); id2 = RRL3_Regsitry::instance()->IwillUse("KEY3"); Here Reco1/id2 and Reco2/id1 will be identical. When the real RRL3 objects comes to life, it builds the map up based on the information recorded in the RRL3_Registry object. It would not preclude other things from being added and manipulated, but it could be that it gives fast index lookup for preregistered things, whereas it would give map/key access for other things. There is a milliion different ways to design and implement such a system, this is just one limited example to illustrate it's usefulness (or uselessness?). > > > > ----------------- > > 4) Finding based on type of object. Many times users want to > > find an object in the hetero_container above by type, such as > > "give_me_the_first_object_of_type" > > This is going to be slow and if this is part of the required access > > pattern needed, then special things must be done if > > performance is critical. I'll assume this is not important. > I am afraid that this is important. Again an example: > The track finding module will need cluster data on its input. it is going > to loop through our hetero container and will do exactly what you fear, it > will do a loop over all regional cluster banks like. > for (RRL3::heteroContainer::Iterator ClusterIter, > ClusterIter.isValid(), > ++ClusterIter) > This is actually the main access mode for read. Other modules would do the > same thing just not with clusters but with tracks or with strip-ADC values > etc. The loop above is a good way to do it, but it does require tranversal of theentire list or map object, and a call to "dynamic_cast" for each item to determine the type. It would depend on the number of times it needs to be done and the structure of the associative array within the RRL3 object (map or vector or combination of both or many - example being one map for general access, and one vector for each type of object with pointers into the map - the EDM classes would probably manage objects put into the event like this). > > 5) There is an alternative to using a Base class for all objects > > stored in the container. Do this (by no means is this a complete > > implementation): > > > > // support class > > class AnyObject > > { > > AnyObject(); > > ~virtual AnyObject(); > > ... > > } > So this is just something with a virtual constructor typically gets made > in a factory? It replaces the base class that in the old solution we would > have to derive from? Is removes the need to have the object stored in the heterogeneouscontainer be derived from a common base class. Look at the sample insert() and find template function I put later in the example and the example user application code. > I'll try and annotate this to show what I do and what I don't understand > about it. > > > > // support class - wrapper for object > > template class SpecificObject : AnyObject > > { > > SpecificObject(T* d):obj(d) { } > did you not mean: > SpecificObject(T* d):_myd(d) { } > > > ... > > static T* get(AnyObject x); > > static void put(AnyObject x, T*); > why are these static functions? And what are they needed for? > > > > > T* _myd; > so Specific object contains a pointer to T, > > } Yes. The wrapper class SpecificObject just holds a pointer to thereal thing. The static methods can be used to hide the dynamic cast required to extract the AnyObject into the object that it holds. I was running out of type when typing in the previous message and realize that there is a few error in the example implementation (in other words it is really incomplete). I will put a corrected version at the end of this email. > To be honest, I don't know how this works at all. Can I give you a phone > call? Please look at my recoded example below. I actually use this code inanother application to remove coupling - the user does not actually know that the objects are stored in a heterogeneous container.Jim ------------------------------------------------------- class AnyObject { AnyObject() { } virtual ~AnyObject() { } } template class SpecificObject { SpecificObject(T* obj):_myobj(obj) { } ~SpecificObject() { } T* _myobj; static T* get(AnyObject* obj) { return dynamic_cast(obj->_myobj); } } typedef map HeteroMap; template int find(const HeteroMap& m, string key, T*& ret) { HeteroMap::iterator i = m.find(key); if(i==m.end()) return -1; // not found // fill users pointer with answer - use static get method here !!!!!!! ret=SpecificObject::get(i->second); if(ret==0) return -1; // error, not correct type return 0; } template int insert(HeteroMap& m, string key, T* obj) { // no checking in this example for duplicates!! m[key] = new SpecificObject(obj); return 0; } // remove function missing // example user application - Cow and Pig are derived from nothing HeteroMap my_map; int func(Cow* c, Pig* p) { // insertion insert(my_map, "MYCOW", c); insert(my_map, "MYPIG", p); // extraction Cow* ce; Pig* pe; find(my_map, "MYCOW", ce); find(my_map,"MYPIG",pe); find(my_map,"MYPIG,ce); // Error condition !!!!! ... } I hope I did not make any mistakes again - I'm running out of time again... -- Jim Kowalkowski - jbk@fnal.gov D0: 630/840-2215 - 5th floor of the D0 assembly building CDF: 630/840-6457 - 169F in the CDF trailers http://www-cdf.fnal.gov/internal/people/links/JamesKowalkowski/my.html http://www-d0.fnal.gov/~jbk/index.html From reichold@al1.physics.ox.ac.uk Thu Feb 11 19:08:00 1999 +0000 Return-path: Envelope-to: reichold@al1.physics.ox.ac.uk Delivery-date: Thu, 11 Feb 1999 19:08:00 +0000 Received: from mail.physics.ox.ac.uk ([163.1.244.140]) by al1.physics.ox.ac.uk with esmtp (Exim 2.05 #1) id 10B1Sx-0006Og-00 for reichold@al1.physics.ox.ac.uk; Thu, 11 Feb 1999 19:07:59 +0000 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.9.8]) by mail.physics.ox.ac.uk id TAA11071 for ; Thu, 11 Feb 1999 19:07:58 GMT Received: from fnal.gov ("port 1079"@d-cd-65.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.1-12 #3998) with ESMTP id <01J7MA005L6E0000Y0@FNAL.FNAL.GOV> for a.reichold1@physics.oxford.ac.uk; Thu, 11 Feb 1999 13:07:54 -0600 CDT Date: Thu, 11 Feb 1999 13:07:02 -0600 From: Jim Kowalkowski Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers To: "Armin Reichold (LHC)" Message-id: <36C32A56.F1D20596@fnal.gov> Organization: Computing Division MIME-version: 1.0 X-Mailer: Mozilla 4.04 [en] (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: Status: RO X-Status: X-Keywords: X-UID: 23 Armin Reichold (LHC) wrote: > > template class SpecificObject > shoud this not be > template class SpecificObject: public AnyObject > > I knew I could not type all that in without making at least onemistake! Yes, you are correct. Jim -- Jim Kowalkowski - jbk@fnal.gov D0: 630/840-2215 - 5th floor of the D0 assembly building CDF: 630/840-6457 - 169F in the CDF trailers http://www-cdf.fnal.gov/internal/people/links/JamesKowalkowski/my.html http://www-d0.fnal.gov/~jbk/index.html From reichold@al1.physics.ox.ac.uk Fri Feb 5 11:46:47 1999 +0000 Date: Fri, 5 Feb 1999 11:46:47 +0000 (GMT) From: "Armin Reichold (LHC)" To: Alfred Lee cc: "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Mat Martin , t.hessing1@physics.ox.ac.uk, Todd Huffman , "David S. Waters" , Christopher Henry Green , Kirsten Tollefson , Kevin McFarland Subject: Lee's clonable class Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 25 Hi Al, I hope you still have a little bit of time left to look at a C++ problem these days, if not - don't worry - just let me know and ignore the following. I have, by accident bumped into your clonable class in the example area. It seems rather old (from g++ days) and I wonder whether you have given up on this completely or if it is currently used in CDF code anywhere. We, oxford L3 group, may have an application for this but I am not realy sure that I understand what this realy does. So may I try to tell you what problem I had in mind for the application and you could tell me if your clonable would be good basis for solving it? We are about to design a class which is supposed to collect and organise the results obtained during regional tracking for L3. This will require storing references to a lot of different classes which all can form parts of the reconstruction chain (clusters, COT tracks, calo-showers, track-sets, etc.) and we would like to avoid having to hardwire all combinations of these objects that should be stored togehter. We would much rather like to have a very lightweight base class that that all these objects could inherit from and thus we store them by their base class types. However, since they are very different beasts we would need to be able to turn them into what they realy are when we manipulate the data they contain. Or at least they should tell us what they realy are so we can cast them or copy them or god nows what. Your cloneable classes seem to provide a lot of this functionality (if I undertand them correctly) Could you advise us a little bit on that? Cheers Armin ************************************************* * Dr. Armin Reichold | private: * * Research Officer | 17 Frys Hill * * University of Oxford | Oxford * * Particle & Nuclear Phys. Lab. | OX4 5GW * * 1 Keble Road | UK * * Oxford OX1 3RH * * UK * * Room 612 * * * * Tel.: +44-(0)1865-273358...(office) * * Tel.: +44-(0)1865-434856...(private) * * Fax.: +44-(0)1865-273418...(office) * * E-Mail: a.reichold1@physics.ox.ac.uk * ************************************************* From reichold@al1.physics.ox.ac.uk Mon Feb 8 09:31:54 1999 +0000 Date: Mon, 8 Feb 1999 09:31:54 +0000 (GMT) From: "Armin Reichold (LHC)" To: Alfred Lee cc: "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Louis Lyons , Mat Martin , "Peter B. Renton" , t.hessing1@physics.ox.ac.uk, Todd Huffman , "David S. Waters" , Christopher Henry Green , Frederick Snider , Joseph Boudreau , Kevin McFarland Subject: Re: Lee's clonable class In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 26 Hi Al, thank you very much for your detailed message. I think we will consider the cloneable aproach in our container for RRL3. I'll bring the subject up tomorrow in our group meeting. I would also like to get some more opinion from other OO experts (Rick, Chris, Joe who else?) to find out if there are any problems with this aproach. After all this may become a key feature of the RRL3 entries class. Cheers Armin ************************************************* * Dr. Armin Reichold | private: * * Research Officer | 17 Frys Hill * * University of Oxford | Oxford * * Particle & Nuclear Phys. Lab. | OX4 5GW * * 1 Keble Road | UK * * Oxford OX1 3RH * * UK * * Room 612 * * * * Tel.: +44-(0)1865-273358...(office) * * Tel.: +44-(0)1865-434856...(private) * * Fax.: +44-(0)1865-273418...(office) * * E-Mail: a.reichold1@physics.ox.ac.uk * ************************************************* On Fri, 5 Feb 1999, Alfred Lee wrote: > Dear Armin, > > The clonable (and related VectorC vector of clonables - class) live > in the TrackingUtils/GenericC++Examples/clonable and vectorc directories. > The purpose of these classes are simple: provide a generic interface > which allows copy construction of of a class that is otherwise specified > only by an abstract interface. The VectorC class allows the same copy > semantics as the STL vector class (copies are added to the vector, not > pointers to objects whose memory is controlled elsewhere), for > classes that obey the clonable interface (they don't actually have to > inherit from it to work). This allows sets of different objects that > obey that inherit from the same clonable interface to be stored in the > the VectorC list. > > I don't believe either of these classes is used anywhere in the code > directly. The interface does lack a "downcasting" function, e.g., > whoAreYou() that returns a string with the name of the concrete class > behind the interface may be useful. This is easily added, however, > it probably isn't needed. If RTTI is enabled (which I think is the CDF > default), then one can just attempt safe dynamic casting of an object > in a set to see if it is the type you need, rather than getting a string > and then deciding to cast based on that. > > As I mention in the comments, there is nothing magical about the clone > class; it is a fairly straight forward implementation of the general idea > of "virtual constructors" as is described in Stroustrup (15.6.2 of 3rd > edition of "The C++ Language"). It may well be a good idiom for the > collection class you want. If you look at mytest.cc in the vectorc > directory, you may get some idea how it could work. All that is missing > from the example is a line like > > Asub * pHeresOne = dynamic_cast(&supervector[1]) > if (!pHeresOne) { > cout << "Dynamic cast to Asub failed" << endl; > } > > to show how dynamic_casting would work (dynamic_cast returns 0 if the cast > fails). I hope this helps. > > Cheers, > > Al > > On Fri, 5 Feb 1999, Armin Reichold (LHC) wrote: > > > Hi Al, > > I hope you still have a little bit of time left to look at a C++ problem > > these days, if not - don't worry - just let me know and ignore the > > following. > > I have, by accident bumped into your clonable class in the example area. > > It seems rather old (from g++ days) and I wonder whether you have given up > > on this completely or if it is currently used in CDF code anywhere. > > > > We, oxford L3 group, may have an application for this but I am not realy > > sure that I understand what this realy does. So may I try to tell you what > > problem I had in mind for the application and you could tell me if your > > clonable would be good basis for solving it? > > > > We are about to design a class which is supposed to collect and organise > > the results obtained during regional tracking for L3. This will require > > storing references to a lot of different classes which all can form parts > > of the reconstruction chain (clusters, COT tracks, calo-showers, > > track-sets, etc.) and we would like to avoid having to hardwire all > > combinations of these objects that should be stored togehter. We would > > much rather like to have a very lightweight base class that that all these > > objects could inherit from and thus we store them by their base class > > types. However, since they are very different beasts we would need to be > > able to turn them into what they realy are when we manipulate the data > > they contain. Or at least they should tell us what they realy are so we > > can cast them or copy them or god nows what. Your cloneable classes seem > > to provide a lot of this functionality (if I undertand them correctly) > > > > Could you advise us a little bit on that? > > > > Cheers Armin > > > > ************************************************* > > * Dr. Armin Reichold | private: * > > * Research Officer | 17 Frys Hill * > > * University of Oxford | Oxford * > > * Particle & Nuclear Phys. Lab. | OX4 5GW * > > * 1 Keble Road | UK * > > * Oxford OX1 3RH * > > * UK * > > * Room 612 * > > * * > > * Tel.: +44-(0)1865-273358...(office) * > > * Tel.: +44-(0)1865-434856...(private) * > > * Fax.: +44-(0)1865-273418...(office) * > > * E-Mail: a.reichold1@physics.ox.ac.uk * > > ************************************************* > > > > > > From reichold@al1.physics.ox.ac.uk Tue Feb 9 12:26:26 1999 +0000 Date: Tue, 9 Feb 1999 12:26:26 +0000 (GMT) From: "Armin Reichold (LHC)" To: "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Louis Lyons , Mat Martin , "Peter B. Renton" , t.hessing1@physics.ox.ac.uk, Todd Huffman , "David S. Waters" Subject: RRL3 drawings Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1789315892-918563186=:5379" Status: O X-Status: X-Keywords: X-UID: 27 --0-1789315892-918563186=:5379 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear all, If the Fermilab crue wake up early enough they may have the time to pick these files up and print them and this web page: http://www-pnp.physics.ox.ac.uk/~huffman/cdf_MOU.html for discussion during the meeting. Cheers Armin ************************************************* * Dr. Armin Reichold | private: * * Research Officer | 17 Frys Hill * * University of Oxford | Oxford * * Particle & Nuclear Phys. Lab. | OX4 5GW * * 1 Keble Road | UK * * Oxford OX1 3RH * * UK * * Room 612 * * * * Tel.: +44-(0)1865-273358...(office) * * Tel.: +44-(0)1865-434856...(private) * * Fax.: +44-(0)1865-273418...(office) * * E-Mail: a.reichold1@physics.ox.ac.uk * ************************************************* --0-1789315892-918563186=:5379 Content-Type: APPLICATION/PostScript; name="RRL3_main_view.ps" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="RRL3_main_view.ps" JSFQUy1BZG9iZS0zLjAKJSVUaXRsZTogUm9zZSBEaWFncmFtKHMpCiUlQ3Jl YXRvcjogV2luZG93cyBOVCA0LjAKJSVDcmVhdGlvbkRhdGU6IDExOjAgMi85 LzE5OTkKJSVQYWdlczogKGF0ZW5kKQolJUJvdW5kaW5nQm94OiAxMSAxNSA1 ODIgODMxCiUlTGFuZ3VhZ2VMZXZlbDogMgolJURvY3VtZW50TmVlZGVkRm9u dHM6IChhdGVuZCkKJSVEb2N1bWVudFN1cHBsaWVkRm9udHM6IChhdGVuZCkK JSVFbmRDb21tZW50cwolJUJlZ2luUHJvbG9nCg0KJSVCZWdpblJlc291cmNl OiBwcm9jc2V0IE5UUFNPY3Q5NQ0KL05UUFNPY3Q5NSAxMDAgZGljdCBkdXAg YmVnaW4vYmR7YmluZCBkZWZ9YmluZCBkZWYvbGR7bG9hZCBkZWZ9YmQvZWR7 ZXhjaCBkZWZ9DQpiZC9he2N1cnJlbnRwb2ludH1iZC9jL2N1cnZldG8gbGQv ZC9kdXAgbGQvZS9lb2ZpbGwgbGQvZi9maWxsIGxkL3RyL3RyYW5zbGF0ZQ0K bGQvZ3IvZ3Jlc3RvcmUgbGQvZ3MvZ3NhdmUgbGQvai9zZXRsaW5lam9pbiBs ZC9ML2xpbmV0byBsZC9NL21vdmV0byBsZC9uDQovbmV3cGF0aCBsZC9jcC9j bG9zZXBhdGggbGQvcm0vcm1vdmV0byBsZC9zbC9zZXRsaW5ld2lkdGggbGQv c2Qvc2V0ZGFzaCBsZC9nDQovc2V0Z3JheSBsZC9yL3NldHJnYmNvbG9yIGxk L3Mvc3Ryb2tlIGxkL3Qvc2hvdyBsZC9hdy9hd2lkdGhzaG93IGxkL2ltDQov aW1hZ2VtYXNrIGxkL01Te21vdmV0byBzaG93fWJkL1NGe2ZpbmRmb250IGV4 Y2ggc2NhbGVmb250IHNldGZvbnR9YmQvU017Y210eA0Kc2V0bWF0cml4fWJk L01Ge2ZpbmRmb250IGV4Y2ggbWFrZWZvbnQgc2V0Zm9udH1iZC9DTXsvY210 eCBtYXRyaXggY3VycmVudG1hdHJpeA0KZGVmfWJkL0J7TSBleGNoIGR1cCAw IHJsdCBleGNoIDAgZXhjaCBybHQgbmVnIDAgcmx0fWJkL0NCe0IgY3AgZW9j bGlwfWJkL0VBezENCmluZGV4IDAvRzAgcHV0IDQgc3RyaW5nIDEgMSA0IC0x IHJvbGx7MyBjb3B5IG5lZyBleGNoIGN2cyBkdXAgMCA3MSBwdXQgY3ZuIDMg LTENCnJvbGwgZXhjaCBwdXR9Zm9yIHBvcH1iZC9ybHQvcmxpbmV0byBsZC9M Mj8vbGFuZ3VhZ2VsZXZlbCB3aGVyZXtwb3ANCmxhbmd1YWdlbGV2ZWwgMiBn ZX17ZmFsc2V9aWZlbHNlIGRlZiBlbmQgZGVmIA0KJSVFbmRSZXNvdXJjZQ0K JSVFbmRQcm9sb2cKJSVCZWdpblNldHVwClt7MAovbGFuZ3VhZ2VsZXZlbCB3 aGVyZXtwb3AgbGFuZ3VhZ2VsZXZlbCAyIGdlfXtmYWxzZX1pZmVsc2UKezEg ZGljdCBkdXAvSm9iVGltZW91dCA0IC0xIHJvbGwgcHV0IHNldHVzZXJwYXJh bXN9CntzdGF0dXNkaWN0L3NldGpvYnRpbWVvdXQgZ2V0IGV4ZWN9aWZlbHNl Cn1zdG9wcGVkIGNsZWFydG9tYXJrClt7MzAwCi9sYW5ndWFnZWxldmVsIHdo ZXJle3BvcCBsYW5ndWFnZWxldmVsIDIgZ2V9e2ZhbHNlfWlmZWxzZQp7MSBk aWN0IGR1cC9XYWl0VGltZW91dCA0IC0xIHJvbGwgcHV0IHNldHVzZXJwYXJh bXN9CntzdGF0dXNkaWN0L3dhaXR0aW1lb3V0IDMgLTEgcm9sbCBwdXR9aWZl bHNlCn1zdG9wcGVkIGNsZWFydG9tYXJrCi8jY29waWVzIDEgZGVmClt7CiUl QmVnaW5GZWF0dXJlOiAqU21vb3RoaW5nIEZhbHNlCg0KICAyIGRpY3QgZHVw IC9Qb3N0UmVuZGVyaW5nRW5oYW5jZSBmYWxzZSBwdXQgc2V0cGFnZWRldmlj ZQ0KCiUlRW5kRmVhdHVyZQp9IHN0b3BwZWQgY2xlYXJ0b21hcmsKW3sKJSVC ZWdpbkZlYXR1cmU6ICpCaXRzUGVyUGl4ZWwgTm9uZQoNCiAgMiBkaWN0IGR1 cCAvUHJlUmVuZGVyaW5nRW5oYW5jZSBmYWxzZSBwdXQgc2V0cGFnZWRldmlj ZQ0KCiUlRW5kRmVhdHVyZQp9IHN0b3BwZWQgY2xlYXJ0b21hcmsKW3sKJSVC ZWdpbkZlYXR1cmU6ICpQYWdlU2l6ZSBBNAoNCiAgIDIgZGljdCBkdXAgL1Bh Z2VTaXplIFs1OTUgODQyXSBwdXQgZHVwIC9JbWFnaW5nQkJveCBudWxsIHB1 dCBzZXRwYWdlZGV2aWNlCiUlRW5kRmVhdHVyZQp9IHN0b3BwZWQgY2xlYXJ0 b21hcmsKW3sKJSVCZWdpbkZlYXR1cmU6ICpUcmF5U3dpdGNoIEZhbHNlCjEg ZGljdCBkdXAgL1RyYXlTd2l0Y2ggZmFsc2UgcHV0IHNldHBhZ2VkZXZpY2UK JSVFbmRGZWF0dXJlCn0gc3RvcHBlZCBjbGVhcnRvbWFyawpbewolJUJlZ2lu RmVhdHVyZTogKlZNT3B0aW9uIDhNZWcKCiUlRW5kRmVhdHVyZQp9IHN0b3Bw ZWQgY2xlYXJ0b21hcmsKW3sKJSVCZWdpbkZlYXR1cmU6ICpPcHRpb25hbENh c3NldHRlMSBGYWxzZQoKJSVFbmRGZWF0dXJlCn0gc3RvcHBlZCBjbGVhcnRv bWFyawpbewolJUJlZ2luRmVhdHVyZTogKk9wdGlvbmFsRW52ZWxvcGVGZWVk ZXIgRmFsc2UKCiUlRW5kRmVhdHVyZQp9IHN0b3BwZWQgY2xlYXJ0b21hcmsK JSVFbmRTZXR1cApOVFBTT2N0OTUgYmVnaW4KJSVQYWdlOiAxIDEKTlRQU09j dDk1IC9QYWdlU1Ygc2F2ZSBwdXQKMTEuNjggODMxLjk2MSB0cmFuc2xhdGUg NzIgNjAwIGRpdiBkdXAgbmVnIHNjYWxlCjAgMCB0cmFuc2Zvcm0gLjI1IGFk ZCByb3VuZCAuMjUgc3ViIGV4Y2ggLjI1IGFkZCByb3VuZCAuMjUgc3ViIGV4 Y2ggaXRyYW5zZm9ybSB0cmFuc2xhdGUKMSBzZXRsaW5lY2FwCjEgc2wKMC4x OTEgZwpuCjg2MyA1MTUgMTYwNiAzMDggQgpjcApncwowLjk3NyBnCmUKZ3IK Q00gMS45OTYgMiBzY2FsZQpzClNNCiUlSW5jbHVkZUZvbnQ6IEhlbHZldGlj YQpbODQgMCAwIC04NCAwIDBdL0hlbHZldGljYSBNRgowIGcKKFJSTDMpMTkz MCA0MDUgTVMKMC4xOTEgZwpuCjg2MyAzOTUgMTYwNiA0MjggQgpjcApDTSAx Ljk5NiAyIHNjYWxlCnMKU00Kbgo4NjMgMjU1IDE2MDYgNTY4IEIKY3AKQ00g MS45OTYgMiBzY2FsZQpzClNNCi9BZG9iZV9XaW5OVF9Ecml2ZXJfR2Z4IDE3 NSBkaWN0IGR1cCBiZWdpbgoNCiUlQmVnaW5SZXNvdXJjZTogZmlsZSBBZG9i ZV9XaW5OVF9VdGlscyAyLjAgMA0KL3wvZGVmIGxvYWQgZGVmLywvbG9hZCBs b2FkIHwvfi9leGNoIGxvYWQgZGVmLz8vaWZlbHNlIGxvYWQgZGVmLyEvcG9w IGxvYWQgZGVmDQovYC9iZWdpbiBsb2FkIGRlZi9eL2luZGV4IGxvYWQgZGVm L0AvZHVwIGxvYWQgZGVmLysvdHJhbnNsYXRlIGxvYWQgZGVmLyQvcm9sbA0K bG9hZCBkZWYvVS91c2VyZGljdCBsb2FkIGRlZi8tL3JsaW5ldG8gbG9hZCBk ZWYvJi9jdXJyZW50ZGljdCBsb2FkIGRlZi86L2dzYXZlDQpsb2FkIGRlZi87 L2dyZXN0b3JlIGxvYWQgZGVmL0YvZmFsc2UgbG9hZCBkZWYvVC90cnVlIGxv YWQgZGVmL04vbmV3cGF0aCBsb2FkDQpkZWYvRS9lbmQgbG9hZCBkZWYvQWMv YXJjIGxvYWQgZGVmL0FuL2FyY24gbG9hZCBkZWYvQS9hc2hvdyBsb2FkIGRl Zi9EDQovYXdpZHRoc2hvdyBsb2FkIGRlZi9DL2Nsb3NlcGF0aCBsb2FkIGRl Zi9PL2VvZmlsbCBsb2FkIGRlZi9JL2xpbmV0byBsb2FkIGRlZg0KLy1DL3Jj dXJ2ZXRvIGxvYWQgZGVmLy1NL3Jtb3ZldG8gbG9hZCBkZWYvK1Mvc2NhbGUg bG9hZCBkZWYvSmkvc2V0Zm9udCBsb2FkIGRlZg0KL0xjL3NldGxpbmVjYXAg bG9hZCBkZWYvTGovc2V0bGluZWpvaW4gbG9hZCBkZWYvTHcvc2V0bGluZXdp ZHRoIGxvYWQgZGVmL1Mvc2hvdw0KbG9hZCBkZWYvTEgvc2hvd3BhZ2UgbG9h ZCBkZWYvSy9zdHJva2UgbG9hZCBkZWYvVy93aWR0aHNob3cgbG9hZCBkZWYv YntiaW5kDQpkZWZ9YmluZCBkZWYvRGVmSWZfQntkdXAgbm90e3VzZXJkaWN0 L0RlZklmX3NhdmUgc2F2ZSBwdXR9aWYgdXNlcmRpY3QNCi9EZWZJZl9ib29s IDIgaW5kZXggcHV0fWIvRGVmSWZfRWx7aWYgdXNlcmRpY3QvRGVmSWZfYm9v bCBnZXQgbm90IGR1cHt1c2VyZGljdA0KL0RlZklmX3NhdmUgZ2V0IHJlc3Rv cmV9aWZ9Yi9EZWZJZl9Fe0RlZklmX0VsIHBvcH1iL3NlbGYgY3VycmVudGRp Y3QgZGVmDQovcmVpbml0aWFsaXple1svVGV4dEluaXQvR3JhcGhJbml0L1V0 aWxzSW5pdCBjb3VudHRvbWFya3tkdXAgd2hlcmV7c2VsZiBlcX0NCntmYWxz ZX1pZmVsc2V7Y3Z4IGV4ZWN9e3BvcH1pZmVsc2V9cmVwZWF0IGNsZWFydG9t YXJrfWIvaW5pdGlhbGl6ZXtiZWdpbg0KdXNlcmRpY3QgYmVnaW4vQURPX214 Um90IGV4Y2ggZGVmL1RleHRJbml0aWFsaXNlZD8gZmFsc2UgZGVmIGVuZCBy ZWluaXRpYWxpemV9Yg0KL3Rlcm1pbmF0ZXtwb3B7Y3VycmVudGRpY3Qgc2Vs ZiBlcXtleGl0fXtlbmR9aWZlbHNlfWxvb3AgZW5kfWIvZHNuYXB7ZHRyYW5z Zm9ybQ0Kcm91bmQgZXhjaCByb3VuZCBleGNoIGlkdHJhbnNmb3JtfWI8MDQ+ Y3Zue31kZWYvc2d7c2V0Z3JheX1iL3Njb3tzZXRyZ2Jjb2xvcn1iDQovc2dj b3t7c2d9e3Njb31pZmVsc2V9Yi9ycHs0IDIgcm9sbCBNIDEgaW5kZXggMCBy bHQgMCBleGNoIHJsdCBuZWcgMCBybHR9YiANCiUlRW5kUmVzb3VyY2UNCg0K JSVCZWdpblJlc291cmNlOiBmaWxlIEFkb2JlX1dpbk5UX1V0aWxzX0wxIDIu MCAwDQpMMj8gbm90IERlZklmX0J7L3Jme25ld3BhdGggcnAgZmlsbH1ifURl ZklmX0UgDQolJUVuZFJlc291cmNlDQoNCiUlQmVnaW5SZXNvdXJjZTogZmls ZSBBZG9iZV9XaW5OVF9VdGlsc19MMiAyLjAgMA0KTDI/IERlZklmX0J7L2Nv bHNwQS9EZXZpY2VHcmF5IGRlZi9jb2xzcEFCQy9EZXZpY2VSR0IgZGVmL3Nl dEFvckFCQ3t7Y29sc3BBfQ0Ke2NvbHNwQUJDfWlmZWxzZSBzZXRjb2xvcnNw YWNlfWIvcmYvcmVjdGZpbGwgbG9hZCBkZWYvVXRpbHNJbml0e2ZhbHNlDQpz ZXRnbG9iYWx9Yn1EZWZJZl9FIA0KJSVFbmRSZXNvdXJjZQ0KZW5kIGRlZgpb MS4wMDAgMCAwIDEuMDAwIDAgMF0gQWRvYmVfV2luTlRfRHJpdmVyX0dmeCBk dXAgL2luaXRpYWxpemUgZ2V0IGV4ZWMKQWRvYmVfV2luTlRfRHJpdmVyX0dm eCBiZWdpbgoNCiUlQmVnaW5SZXNvdXJjZTogZmlsZSBBZG9iZV9XaW5OVF9C V19JbWFnZXMgMi4wIDANCi9pdyAwIGRlZi9paCAwIGRlZi9pbV9zYXZlIDAg ZGVmL3NldHVwaW1hZ2Vwcm9jIDAgZGVmL3BvbGFyaXR5IDAgZGVmL3Ntb290 aGZsYWcNCjAgZGVmL215c3RyaW5nIDAgZGVmL2JwYyAwIGRlZi9zZXR1cDFh c2NpaXByb2N7W2N1cnJlbnRmaWxlIG15c3RyaW5nDQovcmVhZGhleHN0cmlu ZyBjdngvcG9wIGN2eF1jdnggYmluZH1iL3NldHVwMWJpbmFyeXByb2N7W2N1 cnJlbnRmaWxlIG15c3RyaW5nDQovcmVhZHN0cmluZyBjdngvcG9wIGN2eF1j dnggYmluZH1iL3NldHVwMmFzY2lpcHJvY3tjdXJyZW50ZmlsZS9BU0NJSTg1 RGVjb2RlDQpmaWx0ZXIvUnVuTGVuZ3RoRGVjb2RlIGZpbHRlcn1iL3NldHVw MmJpbmFyeXByb2N7Y3VycmVudGZpbGUvUnVuTGVuZ3RoRGVjb2RlDQpmaWx0 ZXJ9Yi9teWNvbG9yc3BhY2V7Y29sc3BBQkN9ZGVmL215aW1hZ2VkaWN0ey9t eWltYWdlZGljdCAxMCBkaWN0IGRlZg0KbXlpbWFnZWRpY3QgZHVwIGJlZ2lu L0ltYWdlVHlwZSAxIGRlZi9NdWx0aXBsZURhdGFTb3VyY2UgZmFsc2UgZGVm IGVuZH1iDQovaW1hZ2Vwcm9jYXJyYXlbL3NldHVwMWJpbmFyeXByb2Mvc2V0 dXAxYXNjaWlwcm9jL3NldHVwMmJpbmFyeXByb2MNCi9zZXR1cDJhc2NpaXBy b2NdZGVmL0wyUG9sYXJpdHl7e1sxIDBdfXtbMCAxXX1pZmVsc2V9Yi9iZWdp bmltYWdley9pbV9zYXZlIHNhdmUNCmRlZiBpbWFnZXByb2NhcnJheSBleGNo IGdldC9zZXR1cGltYWdlcHJvYyBleGNoIGxvYWQgZGVmIEwyUG9sYXJpdHkv cG9sYXJpdHkNCmV4Y2ggZGVmL3Ntb290aGZsYWcgZXhjaCBkZWYgdHJhbnNs YXRlL2R4IDIgaW5kZXggZGVmL2R5IDEgaW5kZXggYWJzIGRlZiBzY2FsZQ0K L215c3RyaW5nIGV4Y2ggc3RyaW5nIGRlZi9icGMgZXhjaCBkZWYvaWggZXhj aCBkZWYvaXcgZXhjaCBkZWZ9Yi9lbmRpbWFnZQ0Ke2ltX3NhdmUgcmVzdG9y ZX1iLzFiaXRtYXNraW1hZ2V7c2djbyBteWltYWdlZGljdCBkdXAgYmVnaW4v V2lkdGggaXcgZGVmL0hlaWdodA0KaWggZGVmL0RlY29kZSBwb2xhcml0eSBk ZWYvSW1hZ2VNYXRyaXhbaXcgMCAwIGloIDAgMF1kZWYvRGF0YVNvdXJjZQ0K c2V0dXBpbWFnZXByb2MgZGVmL0JpdHNQZXJDb21wb25lbnQgMSBkZWYvSW50 ZXJwb2xhdGUgc21vb3RoZmxhZyBkZWYgZW5kDQppbWFnZW1hc2t9Yi8xYml0 Y29weWltYWdle3NnY28gMCAwIDEgZHggZGl2IDEgZHkgZGl2IDEgMiBpbmRl eCBzdWIgMSAyIGluZGV4DQpzdWIgTDI/ezR9ezZ9aWZlbHNlIC0yIHJvbGwg cG9wIHBvcCByZiAxYml0bWFza2ltYWdlfWIvMWJpdGJ3Y29weWltYWdlezAg dHJ1ZSAxDQp0cnVlIDFiaXRjb3B5aW1hZ2V9YiANCiUlRW5kUmVzb3VyY2UN Cg0KJSVCZWdpblJlc291cmNlOiBmaWxlIEFkb2JlX1dpbk5UX0JXX0ltYWdl c19MMSAyLjAgMA0KTDI/IG5vdCBEZWZJZl9Cey9zZXR1cDJhc2NpaXByb2N7 Wy9MZXZlbDJJbWFnZXNFcnJvciBsb2FkIGFsb2FkIHBvcCB0cnVlDQpGYXRh bEVycm9ySWZ9Yi9zZXR1cDJiaW5hcnlwcm9jL3NldHVwMmFzY2lpcHJvYyBs b2FkIGRlZi9MMlBvbGFyaXR5e31kZWYNCi8xYml0bWFza2ltYWdle3NnY28g aXcgaWggcG9sYXJpdHlbaXcgMCAwIGloIDAgMF1zZXR1cGltYWdlcHJvYyBp bWFnZW1hc2t9Yn0NCkRlZklmX0UgDQolJUVuZFJlc291cmNlDQoNCiUlQmVn aW5SZXNvdXJjZTogZmlsZSBBZG9iZV9XaW5OVF9Db19JbWFnZXNfTDEgMi4w IDANCkwyPyBub3QgRGVmSWZfQnsvaXNkZWZpbmVke3doZXJlIGR1cHtleGNo IHBvcH1pZn1iL25jb2xvcnMgMSBkZWYvY29sb3JpbWFnZQ0Kd2hlcmV7cG9w IHRydWV9e2ZhbHNlfWlmZWxzZXsvbmNvbG9ycyAwIHN0YXR1c2RpY3QgYmVn aW4vcHJvY2Vzc2NvbG9ycyB3aGVyZQ0Ke3BvcCBwb3AgcHJvY2Vzc2NvbG9y c317L2RldmljZWluZm8gd2hlcmV7cG9wIGRldmljZWluZm8vQ29sb3JzIGtu b3due3BvcA0Ke2RldmljZWluZm8vQ29sb3JzIGdldH19aWZ9aWZ9aWZlbHNl IGVuZCBkZWYgbmNvbG9ycyAwIG5ley9jb2xvcmltYWdlIGlzZGVmaW5lZA0K L3NldGNvbG9ydHJhbnNmZXIgaXNkZWZpbmVkL2N1cnJlbnRjb2xvcnRyYW5z ZmVyIGlzZGVmaW5lZC9jdXJyZW50Y215a2NvbG9yDQppc2RlZmluZWQgYW5k IGFuZCBhbmQgbm90ey9uY29sb3JzIDAgZGVmfWlmfWlmfWlmIG5jb2xvcnMg ZHVwIDEgbmUgZXhjaCBkdXAgMw0KbmUgZXhjaCA0IG5lIGFuZCBhbmR7L25j b2xvcnMgMCBkZWZ9aWYgbmNvbG9ycyAxIGVxIERlZklmX0J7L2V4cGFuZGJ3 DQp7ZXhwYW5kZmFjdG9yIG11bCByb3VuZCBjdmkgYndjbHV0IGV4Y2ggZ2V0 IDI1NSBkaXZ9Yi9kb2NsdXRpbWFnZXtwb3AvYndjbHV0DQpleGNoIGRlZi9l eHBhbmRmYWN0b3IgMSBicGN7MiBtdWx9cmVwZWF0IDEgc3ViIGRlZlsvZXhw YW5kYncgbG9hZC9leGVjIGxvYWQgZHVwDQpjdXJyZW50dHJhbnNmZXIgZXhj aF1jdnggYmluZCBzZXR0cmFuc2ZlciBpdyBpaCBicGNbaXcgMCAwIGloIDAg MF0NCnNldHVwaW1hZ2Vwcm9jIGltYWdlfWJ9RGVmSWZfRSBuY29sb3JzIGR1 cCAzIGVxIGV4Y2ggNCBlcSBvciBEZWZJZl9Cey9udWxscHJvY3sNCnt9fWRl Zi9jb25jYXR1dGlsey9leGVjIGxvYWQgNyAtMSByb2xsL2V4ZWMgbG9hZH1i L2RlZnN1YmNsdXR7MSBhZGQgZ2V0aW50ZXJ2YWwNCmRlZn1iL3NwY29uY2F0 dHJhbnNmZXJ7L0RjbHV0IGV4Y2ggZGVmL0NjbHV0IGV4Y2ggZGVmL0JjbHV0 IGV4Y2ggZGVmL0FjbHV0IGV4Y2gNCmRlZi9uY29tcHV0ZSBleGNoIGxvYWQg ZGVmIGN1cnJlbnRjb2xvcnRyYW5zZmVyW3tBY2x1dCBuY29tcHV0ZX1jb25j YXR1dGlsXWN2eFsNCntCY2x1dCBuY29tcHV0ZX1jb25jYXR1dGlsXWN2eFt7 Q2NsdXQgbmNvbXB1dGV9Y29uY2F0dXRpbF1jdnhbe0RjbHV0IG5jb21wdXRl fQ0KY29uY2F0dXRpbF1jdnggc2V0Y29sb3J0cmFuc2Zlcn1iL3NldHVwcmdi Y2x1dHN7L2JpdDN4IHJnYmNsdXQgbGVuZ3RoIDMgc3ViIGRlZg0KL2JpdDF4 IGJpdDN4IDMgaWRpdiBkZWYvcmNsdXQgcmdiY2x1dCBkZWYvZ2NsdXQgcmNs dXQgMSBiaXQzeCBkZWZzdWJjbHV0L2JjbHV0DQpyY2x1dCAyIGJpdDN4IGRl ZnN1YmNsdXR9Yn1EZWZJZl9FIG5jb2xvcnMgMyBlcSBEZWZJZl9Cey8zY29t cHV0ZXtleGNoIGJpdDN4DQptdWwgcm91bmQgY3ZpIGdldCAyNTUgZGl2fWIv ZG9jbHV0aW1hZ2V7L3JnYmNsdXQgZXhjaCBkZWYgcG9wIHNldHVwcmdiY2x1 dHMNCi8zY29tcHV0ZSByY2x1dCBnY2x1dCBiY2x1dCBkdXAgc3Bjb25jYXR0 cmFuc2ZlciBpdyBpaCBicGNbaXcgMCAwIGloIDAgMF0NCltzZXR1cGltYWdl cHJvYy9leGVjIGxvYWQvZHVwIGxvYWQgZHVwXWN2eCBudWxscHJvYyBudWxs cHJvYyB0cnVlIDMgY29sb3JpbWFnZX0NCmJ9RGVmSWZfRSBuY29sb3JzIDQg ZXEgRGVmSWZfQnsvZnRvaW50ezEgZXhjaCBzdWIgMjU1IG11bCByb3VuZCBj dml9Yi9zdHVmZmNsdXQNCntjbXlraW5kZXggMyAtMSByb2xsIHB1dH1iLzRj b21wdXRle2V4Y2ggYml0NHggbXVsIHJvdW5kIGN2aSBnZXQgMjU1IGRpdn1i DQovaW52YWxpZGNvbG9ydGFibGU/IHRydWUgZGVmL2NvbXB1dGVjbXlrY2x1 dHtzZXR1cHJnYmNsdXRzL2JpdDR4IHJnYmNsdXQgbGVuZ3RoDQozIGlkaXYg NCBtdWwgNCBzdWIgZGVmL2NteWtjbHV0IGJpdDR4IDQgYWRkIHN0cmluZyBk ZWYvY2NsdXQgY215a2NsdXQgZGVmL21jbHV0DQpjY2x1dCAxIGJpdDR4IGRl ZnN1YmNsdXQveWNsdXQgY2NsdXQgMiBiaXQ0eCBkZWZzdWJjbHV0L2tjbHV0 IGNjbHV0IDMgYml0NHgNCmRlZnN1YmNsdXQvY215a2luZGV4IDAgZGVmIDAg MSBiaXQxeHtkdXAvY215a2luZGV4IGV4Y2ggYml0MXggZXhjaCBzdWIgNCBt dWwNCmRlZiAzIG11bCBkdXAgcmNsdXQgZXhjaCBnZXQgMjU1IGRpdiBleGNo IGR1cCBnY2x1dCBleGNoIGdldCAyNTUgZGl2IGV4Y2ggYmNsdXQNCmV4Y2gg Z2V0IDI1NSBkaXYgc2V0cmdiY29sb3IgY3VycmVudGNteWtjb2xvciBmdG9p bnQga2NsdXQgc3R1ZmZjbHV0IGZ0b2ludA0KeWNsdXQgc3R1ZmZjbHV0IGZ0 b2ludCBtY2x1dCBzdHVmZmNsdXQgZnRvaW50IGNjbHV0IHN0dWZmY2x1dH1m b3J9Yi9kb2NsdXRpbWFnZQ0Key9yZ2JjbHV0IGV4Y2ggZGVmIHBvcCBpbnZh bGlkY29sb3J0YWJsZT97Y29tcHV0ZWNteWtjbHV0fWlmLzRjb21wdXRlIGNj bHV0DQptY2x1dCB5Y2x1dCBrY2x1dCBzcGNvbmNhdHRyYW5zZmVyIGl3IGlo IGJwY1tpdyAwIDAgaWggMCAwXVtzZXR1cGltYWdlcHJvYy9leGVjDQpsb2Fk L2R1cCBsb2FkIGR1cCBkdXBdY3Z4IG51bGxwcm9jIG51bGxwcm9jIG51bGxw cm9jIHRydWUgNCBjb2xvcmltYWdlfWJ9DQpEZWZJZl9FIG5jb2xvcnMgMCBl cSBEZWZJZl9Cey9sb29rdXBhbmRzdG9yZXszIG11bCAzIGdldGludGVydmFs IHB1dGludGVydmFsDQpleGNoIDMgYWRkIGV4Y2ggMyBjb3B5fWIvOGxvb2t1 cC9sb29rdXBhbmRzdG9yZSBsb2FkIGRlZi80bG9va3Vwey9ieXRlIDEgaW5k ZXgNCmRlZiAtNCBiaXRzaGlmdCBsb29rdXBhbmRzdG9yZSBieXRlIDE1IGFu ZCBsb29rdXBhbmRzdG9yZX1iLzJsb29rdXB7L2J5dGUgMQ0KaW5kZXggZGVm IC02IGJpdHNoaWZ0IGxvb2t1cGFuZHN0b3JlIGJ5dGUgLTQgYml0c2hpZnQg MyBhbmQgbG9va3VwYW5kc3RvcmUgYnl0ZQ0KLTIgYml0c2hpZnQgMyBhbmQg bG9va3VwYW5kc3RvcmUgYnl0ZSAzIGFuZCBsb29rdXBhbmRzdG9yZX1iLzFs b29rdXB7L2J5dGUgZXhjaA0KZGVmIC03IDEgMHtieXRlIGV4Y2ggYml0c2hp ZnQgMSBhbmQgbG9va3VwYW5kc3RvcmV9YmluZCBmb3J9Yi9jb2xvcmV4cGFu ZA0Ke215c3RyaW5nZXhwIDAgcmdiY2x1dCAzIGNvcHkgNyAtMSByb2xsL215 bG9va3VwIGxvYWQgZm9yYWxsIHBvcCBwb3AgcG9wIHBvcA0KcG9wfWIvY3Jl YXRlZXhwYW5kc3Ryey9teXN0cmluZ2V4cCBleGNoIG15c3RyaW5nIGxlbmd0 aCBtdWwgc3RyaW5nIGRlZn1iDQovZG9jbHV0aW1hZ2V7L3JnYmNsdXQgZXhj aCBkZWYgcG9wL215bG9va3VwIGJwYyA4IGVxezMgY3JlYXRlZXhwYW5kc3Ry Lzhsb29rdXB9DQp7YnBjIDQgZXF7NiBjcmVhdGVleHBhbmRzdHIvNGxvb2t1 cH17YnBjIDIgZXF7MTIgY3JlYXRlZXhwYW5kc3RyLzJsb29rdXB9ezI0DQpj cmVhdGVleHBhbmRzdHIvMWxvb2t1cH1pZmVsc2V9aWZlbHNlfWlmZWxzZSBs b2FkIGRlZiBpdyBpaCA4W2l3IDAgMCBpaCAwIDBdDQpbc2V0dXBpbWFnZXBy b2MvZXhlYyBsb2FkL2NvbG9yZXhwYW5kIGxvYWQvZXhlYyBsb2FkXWN2eCBm YWxzZSAzIGNvbG9yaW1hZ2V9Yn0NCkRlZklmX0UvY29sb3JpbWFnZSB3aGVy ZXtwb3AgdHJ1ZX17ZmFsc2V9aWZlbHNlIERlZklmX0J7L2RvMjRpbWFnZXtp dyBpaCA4W2l3IDANCjAgaWggMCAwXXNldHVwaW1hZ2Vwcm9jIGZhbHNlIDMg Y29sb3JpbWFnZX1ifURlZklmX0Vsey9yZ2J0b2dyYXl7L3N0ciBleGNoIGRl Zg0KL2xlbiBzdHIgbGVuZ3RoIGRlZi9zbWxlbiBsZW4gMyBpZGl2IGRlZi9y c3RyIHN0ciBkZWYvZ3N0ciBzdHIgMSBsZW4gMSBzdWINCmdldGludGVydmFs IGRlZi9ic3RyIHN0ciAyIGxlbiAyIHN1YiBnZXRpbnRlcnZhbCBkZWYgc3Ry IGR1cCAwIDEgc21sZW4gMSBzdWINCntkdXAgMyBtdWwgcnN0ciAxIGluZGV4 IGdldCAuMyBtdWwgZ3N0ciAyIGluZGV4IGdldCAuNTkgbXVsIGFkZCBic3Ry IDMgLTEgcm9sbA0KZ2V0IC4xMSBtdWwgYWRkIHJvdW5kIGN2aSBwdXQgZHVw fWZvciBwb3AgMCBzbWxlbiBnZXRpbnRlcnZhbH1iL2RvMjRpbWFnZXtpdyBp aA0KOFtpdyAwIDAgaWggMCAwXVtzZXR1cGltYWdlcHJvYy9leGVjIGxvYWQv cmdidG9ncmF5IGxvYWQvZXhlYyBsb2FkXWN2eCBiaW5kDQppbWFnZX1ifURl ZklmX0UvZG9OaW1hZ2V7YnBjIDI0IGVxe2RvMjRpbWFnZX17aXcgaWggYnBj W2l3IDAgMCBpaCAwIDBdDQpzZXR1cGltYWdlcHJvYyBpbWFnZX1pZmVsc2V9 Yn1EZWZJZl9FIA0KJSVFbmRSZXNvdXJjZQ0KDQolJUJlZ2luUmVzb3VyY2U6 IGZpbGUgQWRvYmVfV2luTlRfQ29fSW1hZ2VzX0wyIDIuMCAwDQpMMj8gRGVm SWZfQnsvZG9jbHV0aW1hZ2V7L3JnYmNsdXQgZXhjaCBkZWYgcG9wL2hpdmFs IDEgYnBjezIgbXVsfXJlcGVhdCAxIHN1Yg0KZGVmWy9JbmRleGVkIGNvbHNw QUJDIGhpdmFsIHJnYmNsdXRdc2V0Y29sb3JzcGFjZSBteWltYWdlZGljdCBk dXAgYmVnaW4vV2lkdGgNCml3IGRlZi9IZWlnaHQgaWggZGVmL0RlY29kZVsw IGhpdmFsXWRlZi9JbWFnZU1hdHJpeFtpdyAwIDAgaWggMCAwXWRlZg0KL0Rh dGFTb3VyY2Ugc2V0dXBpbWFnZXByb2MgZGVmL0JpdHNQZXJDb21wb25lbnQg YnBjIGRlZi9JbnRlcnBvbGF0ZSBzbW9vdGhmbGFnDQpkZWYgZW5kIGltYWdl fWIvZG9OaW1hZ2V7YnBjIDI0IGVxe2NvbHNwQUJDfXtjb2xzcEF9aWZlbHNl IHNldGNvbG9yc3BhY2UNCm15aW1hZ2VkaWN0IGR1cCBiZWdpbi9XaWR0aCBp dyBkZWYvSGVpZ2h0IGloIGRlZi9EZWNvZGUgYnBjIDI0IGVxe1swIDEgMCAx IDAgMV0NCn17WzAgMV19aWZlbHNlIGRlZi9JbWFnZU1hdHJpeFtpdyAwIDAg aWggMCAwXWRlZi9EYXRhU291cmNlIHNldHVwaW1hZ2Vwcm9jIGRlZg0KL0Jp dHNQZXJDb21wb25lbnQgYnBjIDI0IGVxezh9e2JwY31pZmVsc2UgZGVmL0lu dGVycG9sYXRlIHNtb290aGZsYWcgZGVmIGVuZA0KaW1hZ2V9Yn1EZWZJZl9F IA0KJSVFbmRSZXNvdXJjZQ0KZW5kIHJlaW5pdGlhbGl6ZQoxNiAxNSAyNCA0 OCA4MCA3NCAxNjI0IDQ0MCBmYWxzZSB0cnVlIDMgYmVnaW5pbWFnZQpkb05p bWFnZQokMzopKyE8MyQhcnI8JyFvKUtSKyEhKiQhITwzJCFycjwnISEhKiQh ITwzJCFycjw5KHJyPCchISEqJnQhITdoKktfdGNOS1MibVUhIyxBNCE8MyQh cnI8JyEhISokISE8MyQhcnI8MCVycjwnIXI7WyJTSnFTZi9LX2tgUUtTImwx SnFYKCYmSDtfMXJyPCchISEqJCEhPDMkIXJyPDAlcnI8JyFyO1puUEpxWCsn cXU/V3EhZWMvWXI7W0UvISEqJCEhPDMkIXJyPCchISEqJCEiOUFIJSE8OzNe Jkg7XzFycjwnISEhKiQhITwzJCFycjwnInM4O3JhCnJyUmsqS2AobE5zOEUh KUtFMiNQITwzJCFycjwnInM4O3A2YGwjZkxKcVNmL0tTNHIxS1MibDFKcVNm L0tTNHIxcXVALlkhPDwnISE8MychISEqJCEhPEUvdSEhcFReYGU4cXNLUyJt UyEjaWtwYGU4cXNLUyJqVyEvKEBQcnJFKiEhPDwnISEvKEBQISEqKiJyO1s1 Rl9vQEBdS1o6cExLUyJtViEjZ05CS1M0cjFLRS1aKnM4TiohcnJFKiEhPDwn IXM4TichS0UyKVFyO1w6IkpxU2YvS1M0cjFLUyJsMUpxU2YvS0UpI1AhPDwn IXM4TiohcnJFKiEKITw8JyEhLyg9UHJyYD8lISEqJmYhI1VAaHM4TiohcnJF KiEhPDwnIXM4TichcnI8JVAhPDMkNCE8MyQhcnI8JyEhISokISE8MyQhcnI8 JyFyVyFmOEtFLVoqczhOKiFyckUqISEhJVpQITwzJyEhISokISgnK0A3ITwz JCFycjwnISEhKiQhITwzJCFycjwnIXJXIVtkISEqJCFzOE4nIXJyPCVQITwz JCFycjwnISEmIj9QISEqJCEhPDMkIXJyPCchISEqJCEhPDMkIXJyPCchIS8o PyohISVaUCEvKEBQISEqJCEhPDMkIXJyPSM9cnI8JyEhISokIQohPDMkIXJy PCchISEqJCEhPDMkIXJyPCchclchSy8hPDMkIXJyPCchISEqJCEhPDMlTH4+ CmVuZGltYWdlCjAgZwooJCBfZW50cmllcyA6IHZlY3RvcikxNzA0IDUxNSBN UwoxNiAxNSAyNCA0OCA4MCA3NCAxNjI0IDYyOCBmYWxzZSB0cnVlIDMgYmVn aW5pbWFnZQpkb05pbWFnZQoqISQhPSE8MyQhcnI8JyEhISokISE8MyQhcnI8 JyEhISokISE8O3JzJUs/RC5ycjwnISEhKiQhITwzJDohPDMkIXJyPCchISEq JCEhPDMkIXJyPCchISEqJCEhPDt1dCI5L0IkS2AxcllycjwnISEhKiQhITwz JFAhPDMkIXJyPCchISEqJCEhPDMkIXJyPCchISEqJCFLRS1dKiE8PCchczhO KiEhISVaUHJyPCchISEqJCEnKi8lNCE8MyQhcnI8JyEhISokISE8MyQhczhF IThLYDsmUHJyRSohITw8JyFzOE4qISEhJVpQcnI8JyEhIyNBNCEhKiQhCiE8 MyQhcnI8JyEhISokISE8O3V0JnFnNzxyckUqISE8PCchczhOKiFyckUoUHJX ISEhISM+UzchISokISE8MyQhcnI8JyEhISokISE8MyQhczhEdXVLYDFyYHJy RSohITw8JyFzOE4qIXJyRSchIS8pbSdycjwnISEhKiQhITwzJCFycjwnISEh KiQhITwzJCFyckBdUEtFKSIqcnJFKiEhPDwnIXJyPCVQclchbzxycjwnISEh KiQhITwzJCFycjwnISEhKiQhITwzJCFycjwnIXI7WyJTISEqJCFzOEUhJUtF LVoqcnI9LEBycjwnISEhKiQhITwzJCEKcnI8JyEhISokISE8MyQhcnI8JyEh ISomdSEiPU1cIS8oPVBLRTIjUCE8MyRFITwzJCFycjwnISEhKiQhITwzJCFy cjwnISEhKiQhITwzJCFycjwnISEhKiQhS2AxclZycjwnISEhKiQhMCopIlAh PDMkIXJyPCchISEqJCEhPDMkIXJyPCchISEqJCEhPDMkIXJyPCchISEqJCEh PDMkIXJyPCchISYiP1AhISokISE8MyQhcnI8JyEhISokISE8MyQhcnI8JyEh ISokISE8MyQhcnI8JyEhISokISE8MyQhcnI9XFBycjwnISEhKiQhITwzJCFy cjwnIQohISokISE8MyQhcnI8JyEhISokISE8MyQhcnI8JyEhISokISE8MyRQ ITwzJCFycjwnISEhKiQhITwzJCFycjwnISEhKiQhITwzJCFycjwnISEhKiQh ITwzJCFycjwnISEhKiQhMCopIlAhPDMkIXJyPCchISEqJCEhPDMkIXJyPCch ISEqJCEhPDMkIXJyPCchISEqJCEhPDMkIXJyPCchIS5Zfj4KZW5kaW1hZ2UK KHVuaXF1ZUVudHJ5UmVxdWVzdFwoXCkpMTcwNCA3MDMgTVMKMTYgMTUgMjQg NDggODAgNzQgMTYyNCA3MjIgZmFsc2UgdHJ1ZSAzIGJlZ2luaW1hZ2UKZG9O aW1hZ2UKKiEkIT0hPDMkIXJyPCchISEqJCEhPDMkIXJyPCchISEqJCEhPDty cyVLP0QucnI8JyEhISokISE8MyQ6ITwzJCFycjwnISEhKiQhITwzJCFycjwn ISEhKiQhITw7dXQiOS9CJEtgMXJZcnI8JyEhISokISE8MyRQITwzJCFycjwn ISEhKiQhITwzJCFycjwnISEhKiQhS0UtXSohPDwnIXM4TiohISElWlBycjwn ISEhKiQhJyovJTQhPDMkIXJyPCchISEqJCEhPDMkIXM4RSE4S2A7JlByckUq ISE8PCchczhOKiEhISVaUHJyPCchISMjQTQhISokIQohPDMkIXJyPCchISEq JCEhPDt1dCZxZzc8cnJFKiEhPDwnIXM4TiohcnJFKFByVyEhISEjPlM3ISEq JCEhPDMkIXJyPCchISEqJCEhPDMkIXM4RHV1S2AxcmByckUqISE8PCchczhO KiFyckUnISEvKW0ncnI8JyEhISokISE8MyQhcnI8JyEhISokISE8MyQhcnJA XVBLRSkiKnJyRSohITw8JyFycjwlUHJXIW88cnI8JyEhISokISE8MyQhcnI8 JyEhISokISE8MyQhcnI8JyFyO1siUyEhKiQhczhFISVLRS1aKnJyPSxAcnI8 JyEhISokISE8MyQhCnJyPCchISEqJCEhPDMkIXJyPCchISEqJnUhIj1NXCEv KD1QS0UyI1AhPDMkRSE8MyQhcnI8JyEhISokISE8MyQhcnI8JyEhISokISE8 MyQhcnI8JyEhISokIUtgMXJWcnI8JyEhISokITAqKSJQITwzJCFycjwnISEh KiQhITwzJCFycjwnISEhKiQhITwzJCFycjwnISEhKiQhITwzJCFycjwnISEm Ij9QISEqJCEhPDMkIXJyPCchISEqJCEhPDMkIXJyPCchISEqJCEhPDMkIXJy PCchISEqJCEhPDMkIXJyPVxQcnI8JyEhISokISE8MyQhcnI8JyEKISEqJCEh PDMkIXJyPCchISEqJCEhPDMkIXJyPCchISEqJCEhPDMkUCE8MyQhcnI8JyEh ISokISE8MyQhcnI8JyEhISokISE8MyQhcnI8JyEhISokISE8MyQhcnI8JyEh ISokITAqKSJQITwzJCFycjwnISEhKiQhITwzJCFycjwnISEhKiQhITwzJCFy cjwnISEhKiQhITwzJCFycjwnISEuWX4+CmVuZGltYWdlCih1bnRpdGxlZFwo XCkpMTcwNCA3OTcgTVMKMC4xOTEgZwpuCjU5OSAzMjcgMTI1OCAyNzA2IEIK Y3AKZ3MKMC45NzcgZwplCmdyCkNNIDEuOTk2IDIgc2NhbGUKcwpTTQowIGcK KFJSTDNfRW50cnlJRCkxMjg2IDI4OTMgTVMKMC4xOTEgZwpuCjU5OSAxMTcg MTI1OCAyOTE2IEIKY3AKQ00gMS45OTYgMiBzY2FsZQpzClNNCm4KNTk5IDcx IDEyNTggMjk2MiBCCmNwCkNNIDEuOTk2IDIgc2NhbGUKcwpTTQowIGcKKDw8 RW50aXR5Pj4pMTM1NCAyODAzIE1TCjAuMTkxIGcKbgo3NjYgMzI3IDIyMzAg MjcwNiBCCmNwCmdzCjAuOTc3IGcKZQpncgpDTSAxLjk5NiAyIHNjYWxlCnMK U00KMCBnCihSUkwzX0VudHJ5UmVzdWx0cykyMjQ0IDI4OTMgTVMKMC4xOTEg ZwpuCjc2NiAxMTcgMjIzMCAyOTE2IEIKY3AKQ00gMS45OTYgMiBzY2FsZQpz ClNNCm4KNzY2IDcxIDIyMzAgMjk2MiBCCmNwCkNNIDEuOTk2IDIgc2NhbGUK cwpTTQowIGcKKDw8RW50aXR5Pj4pMjQxMCAyODAzIE1TCjAuMTkxIGcKbgoz NjcgMjk5IDE4NTQgMTIxNiBCCmNwCmdzCjAuOTc3IGcKZQpncgpDTSAxLjk5 NiAyIHNjYWxlCnMKU00KbgoxODEgMTY5IDIwNzUgMTEzMSBCCjEgZwpmClsx NDQgNDggXTAgc2QKbgoxODMgMTcxIDIwNzQgMTEzMCBCCmNwCnMKMCBnCm4K MTgzIDE3MSAyMDc0IDExMzAgQgpjcApzCls3NiAwIDAgLTc2IDAgMF0vSGVs dmV0aWNhIE1GCm4KMTY5IDg0IDIwOTMgMTE1MCBCCjEgZwpmCjAgZwooX1R5 LCApMjA5NCAxMjE4IE1TCm4KOTQgODQgMjA5MyAxMjM0IEIKMSBnCmYKMCBn CihfQSkyMDk0IDEzMDIgTVMKKHZlY3RvcikxOTM0IDEzNzAgTVMKW10wIHNk CjAuMTkxIGcKbgozNjcgMTE5IDE4NTQgMTM5NiBCCmNwCkNNIDEuOTk2IDIg c2NhbGUKcwpTTQpuCjM2NyA3NyAxODU0IDE0MzggQgpjcApDTSAxLjk5NiAy IHNjYWxlCnMKU00KMSBqCm4KMjAzOCAxMDE4IE0KMjAzOCA4MjQgTApDTSAx Ljk5NiAyIHNjYWxlCnMKU00KWzg0IDAgMCAtODQgMCAwXS9IZWx2ZXRpY2Eg TUYKbgo0OCA5NCAyMDk0IDgyNCBCCjEgZwpmCjAgZwooMSkyMDk0IDg5OSBN UwowLjE5MSBnCm4KMjAzOCA4MjQgTQoyMDY4IDg3OCBMCjIwMzggOTMyIEwK MjAwOCA4NzggTAoyMDM4IDgyNCBMCmNwCmdzCjAgZwplCmdyCkNNIDEuOTk2 IDIgc2NhbGUKcwpTTQpuCjIwMzggMTAxOCBNCjIwMzggMTIxNCBMCkNNIDEu OTk2IDIgc2NhbGUKcwpTTQpuCjQ4IDk0IDIwNTggMTAzNCBCCjEgZwpmCjAg ZwooMSkyMDU4IDExMDkgTVMKbgoyMDM4IDEyMTQgTQoyMDY4IDExNDIgTApD TSAxLjk5NiAyIHNjYWxlCnMKU00KbgoyMDM4IDEyMTQgTQoyMDA4IDExNDIg TApDTSAxLjk5NiAyIHNjYWxlCnMKU00Kbgo0OCA5NCAyMDk0IDgyNCBCCjEg ZwpmCjAgZwooMSkyMDk0IDg5OSBNUwpuCjMyOCA5NCAxNjMyIDEwOTggQgox IGcKZgowIGcKKC1fZW50cmllcykxNjMyIDExNzMgTVMKbgo0OCA5NCAyMDU4 IDEwMzQgQgoxIGcKZgowIGcKKDEpMjA1OCAxMTA5IE1TCjAgagowLjE5MSBn Cm4KODkxIDUxNSAxNTkyIDE4MTIgQgpjcApncwowLjk3NyBnCmUKZ3IKQ00g MS45OTYgMiBzY2FsZQpzClNNCjAgZwooUlJMM19FbnRyeSkxODA4IDE5MDkg TVMKMC4xOTEgZwpuCjg5MSAzOTUgMTU5MiAxOTMyIEIKY3AKQ00gMS45OTYg MiBzY2FsZQpzClNNCm4KODkxIDM0OSAxNTkyIDE5NzggQgpjcApDTSAxLjk5 NiAyIHNjYWxlCnMKU00KMTYgMTUgMjQgNDggODAgNzQgMTYxMCAyMDM4IGZh bHNlIHRydWUgMyBiZWdpbmltYWdlCmRvTmltYWdlCiohJCE9ITwzJCFycjwn ISEhKiQhITwzJCFycjwnISEhKiQhITw7cnMlSz9ELnJyPCchISEqJCEhPDMk OiE8MyQhcnI8JyEhISokISE8MyQhcnI8JyEhISokISE8O3V0IjkvQiRLYDFy WXJyPCchISEqJCEhPDMkUCE8MyQhcnI8JyEhISokISE8MyQhcnI8JyEhISok IUtFLV0qITw8JyFzOE4qISEhJVpQcnI8JyEhISokIScqLyU0ITwzJCFycjwn ISEhKiQhITwzJCFzOEUhOEtgOyZQcnJFKiEhPDwnIXM4TiohISElWlBycjwn ISEjI0E0ISEqJCEKITwzJCFycjwnISEhKiQhITw7dXQmcWc3PHJyRSohITw8 JyFzOE4qIXJyRShQclchISEhIz5TNyEhKiQhITwzJCFycjwnISEhKiQhITwz JCFzOER1dUtgMXJgcnJFKiEhPDwnIXM4TiohcnJFJyEhLyltJ3JyPCchISEq JCEhPDMkIXJyPCchISEqJCEhPDMkIXJyQF1QS0UpIipyckUqISE8PCchcnI8 JVByVyFvPHJyPCchISEqJCEhPDMkIXJyPCchISEqJCEhPDMkIXJyPCchcjtb IlMhISokIXM4RSElS0UtWipycj0sQHJyPCchISEqJCEhPDMkIQpycjwnISEh KiQhITwzJCFycjwnISEhKiZ1ISI9TVwhLyg9UEtFMiNQITwzJEUhPDMkIXJy PCchISEqJCEhPDMkIXJyPCchISEqJCEhPDMkIXJyPCchISEqJCFLYDFyVnJy PCchISEqJCEwKikiUCE8MyQhcnI8JyEhISokISE8MyQhcnI8JyEhISokISE8 MyQhcnI8JyEhISokISE8MyQhcnI8JyEhJiI/UCEhKiQhITwzJCFycjwnISEh KiQhITwzJCFycjwnISEhKiQhITwzJCFycjwnISEhKiQhITwzJCFycj1cUHJy PCchISEqJCEhPDMkIXJyPCchCiEhKiQhITwzJCFycjwnISEhKiQhITwzJCFy cjwnISEhKiQhITwzJFAhPDMkIXJyPCchISEqJCEhPDMkIXJyPCchISEqJCEh PDMkIXJyPCchISEqJCEhPDMkIXJyPCchISEqJCEwKikiUCE8MyQhcnI8JyEh ISokISE8MyQhcnI8JyEhISokISE8MyQhcnI8JyEhISokISE8MyQhcnI8JyEh Lll+PgplbmRpbWFnZQowIGcKKHJlZ2lvbkV4aXN0c1woXCkpMTY5MCAyMTEz IE1TCjE2IDE1IDI0IDQ4IDgwIDc0IDE2MTAgMjEzMiBmYWxzZSB0cnVlIDMg YmVnaW5pbWFnZQpkb05pbWFnZQoqISQhPSE8MyQhcnI8JyEhISokISE8MyQh cnI8JyEhISokISE8O3JzJUs/RC5ycjwnISEhKiQhITwzJDohPDMkIXJyPCch ISEqJCEhPDMkIXJyPCchISEqJCEhPDt1dCI5L0IkS2AxcllycjwnISEhKiQh ITwzJFAhPDMkIXJyPCchISEqJCEhPDMkIXJyPCchISEqJCFLRS1dKiE8PCch czhOKiEhISVaUHJyPCchISEqJCEnKi8lNCE8MyQhcnI8JyEhISokISE8MyQh czhFIThLYDsmUHJyRSohITw8JyFzOE4qISEhJVpQcnI8JyEhIyNBNCEhKiQh CiE8MyQhcnI8JyEhISokISE8O3V0JnFnNzxyckUqISE8PCchczhOKiFyckUo UHJXISEhISM+UzchISokISE8MyQhcnI8JyEhISokISE8MyQhczhEdXVLYDFy YHJyRSohITw8JyFzOE4qIXJyRSchIS8pbSdycjwnISEhKiQhITwzJCFycjwn ISEhKiQhITwzJCFyckBdUEtFKSIqcnJFKiEhPDwnIXJyPCVQclchbzxycjwn ISEhKiQhITwzJCFycjwnISEhKiQhITwzJCFycjwnIXI7WyJTISEqJCFzOEUh JUtFLVoqcnI9LEBycjwnISEhKiQhITwzJCEKcnI8JyEhISokISE8MyQhcnI8 JyEhISomdSEiPU1cIS8oPVBLRTIjUCE8MyRFITwzJCFycjwnISEhKiQhITwz JCFycjwnISEhKiQhITwzJCFycjwnISEhKiQhS2AxclZycjwnISEhKiQhMCop IlAhPDMkIXJyPCchISEqJCEhPDMkIXJyPCchISEqJCEhPDMkIXJyPCchISEq JCEhPDMkIXJyPCchISYiP1AhISokISE8MyQhcnI8JyEhISokISE8MyQhcnI8 JyEhISokISE8MyQhcnI8JyEhISokISE8MyQhcnI9XFBycjwnISEhKiQhITwz JCFycjwnIQohISokISE8MyQhcnI8JyEhISokISE8MyQhcnI8JyEhISokISE8 MyRQITwzJCFycjwnISEhKiQhITwzJCFycjwnISEhKiQhITwzJCFycjwnISEh KiQhITwzJCFycjwnISEhKiQhMCopIlAhPDMkIXJyPCchISEqJCEhPDMkIXJy PCchISEqJCEhPDMkIXJyPCchISEqJCEhPDMkIXJyPCchIS5Zfj4KZW5kaW1h Z2UKKHNldFJlZ2lvblwoXCkpMTY5MCAyMjA3IE1TCjE2IDE1IDI0IDQ4IDgw IDc0IDE2MTAgMjIyNiBmYWxzZSB0cnVlIDMgYmVnaW5pbWFnZQpkb05pbWFn ZQoqISQhPSE8MyQhcnI8JyEhISokISE8MyQhcnI8JyEhISokISE8O3JzJUs/ RC5ycjwnISEhKiQhITwzJDohPDMkIXJyPCchISEqJCEhPDMkIXJyPCchISEq JCEhPDt1dCI5L0IkS2AxcllycjwnISEhKiQhITwzJFAhPDMkIXJyPCchISEq JCEhPDMkIXJyPCchISEqJCFLRS1dKiE8PCchczhOKiEhISVaUHJyPCchISEq JCEnKi8lNCE8MyQhcnI8JyEhISokISE8MyQhczhFIThLYDsmUHJyRSohITw8 JyFzOE4qISEhJVpQcnI8JyEhIyNBNCEhKiQhCiE8MyQhcnI8JyEhISokISE8 O3V0JnFnNzxyckUqISE8PCchczhOKiFyckUoUHJXISEhISM+UzchISokISE8 MyQhcnI8JyEhISokISE8MyQhczhEdXVLYDFyYHJyRSohITw8JyFzOE4qIXJy RSchIS8pbSdycjwnISEhKiQhITwzJCFycjwnISEhKiQhITwzJCFyckBdUEtF KSIqcnJFKiEhPDwnIXJyPCVQclchbzxycjwnISEhKiQhITwzJCFycjwnISEh KiQhITwzJCFycjwnIXI7WyJTISEqJCFzOEUhJUtFLVoqcnI9LEBycjwnISEh KiQhITwzJCEKcnI8JyEhISokISE8MyQhcnI8JyEhISomdSEiPU1cIS8oPVBL RTIjUCE8MyRFITwzJCFycjwnISEhKiQhITwzJCFycjwnISEhKiQhITwzJCFy cjwnISEhKiQhS2AxclZycjwnISEhKiQhMCopIlAhPDMkIXJyPCchISEqJCEh PDMkIXJyPCchISEqJCEhPDMkIXJyPCchISEqJCEhPDMkIXJyPCchISYiP1Ah ISokISE8MyQhcnI8JyEhISokISE8MyQhcnI8JyEhISokISE8MyQhcnI8JyEh ISokISE8MyQhcnI9XFBycjwnISEhKiQhITwzJCFycjwnIQohISokISE8MyQh cnI8JyEhISokISE8MyQhcnI8JyEhISokISE8MyRQITwzJCFycjwnISEhKiQh ITwzJCFycjwnISEhKiQhITwzJCFycjwnISEhKiQhITwzJCFycjwnISEhKiQh MCopIlAhPDMkIXJyPCchISEqJCEhPDMkIXJyPCchISEqJCEhPDMkIXJyPCch ISEqJCEhPDMkIXJyPCchIS5Zfj4KZW5kaW1hZ2UKKGFkZEludGVyZXN0ZWRU cmlnZ2VyXChcKSkxNjkwIDIzMDEgTVMKMSBqCjAuMTkxIGcKbgoxNzY4IDI1 MTYgTQoxODgyIDIzMjggTApDTSAxLjk5NiAyIHNjYWxlCnMKU00Kbgo0OCA5 NCAxOTI4IDIzNDYgQgoxIGcKZgowIGcKKDEpMTkyOCAyNDIxIE1TCjAuMTkx IGcKbgoxODgyIDIzMjggTQoxODgwIDIzOTAgTAoxODI2IDI0MjAgTAoxODI4 IDIzNTggTAoxODgyIDIzMjggTApjcApncwowIGcKZQpncgpDTSAxLjk5NiAy IHNjYWxlCnMKU00KbgoxNzY4IDI1MTYgTQoxNjU0IDI3MDQgTApDTSAxLjk5 NiAyIHNjYWxlCnMKU00Kbgo0OCA5NCAxNzQ2IDI2MDAgQgoxIGcKZgowIGcK KDEpMTc0NiAyNjc1IE1TCm4KMTY1NCAyNzA0IE0KMTcxOCAyNjU4IEwKQ00g MS45OTYgMiBzY2FsZQpzClNNCm4KMTY1NCAyNzA0IE0KMTY2NiAyNjI2IEwK Q00gMS45OTYgMiBzY2FsZQpzClNNCm4KNDggOTQgMTkyOCAyMzQ2IEIKMSBn CmYKMCBnCigxKTE5MjggMjQyMSBNUwpuCjE2MCA5NCAxNDcyIDI1NzggQgox IGcKZgowIGcKKC1fSUQpMTQ3MiAyNjUzIE1TCm4KNDggOTQgMTc0NiAyNjAw IEIKMSBnCmYKMCBnCigxKTE3NDYgMjY3NSBNUwowLjE5MSBnCm4KMjM1OCAy NTE2IE0KMjIyNCAyMzI4IEwKQ00gMS45OTYgMiBzY2FsZQpzClNNCm4KNDgg OTQgMjMxMiAyMzQ4IEIKMSBnCmYKMCBnCigxKTIzMTIgMjQyMyBNUwowLjE5 MSBnCm4KMjIyNCAyMzI4IE0KMjI4MCAyMzU0IEwKMjI4NiAyNDE2IEwKMjIz MiAyMzkwIEwKMjIyNCAyMzI4IEwKY3AKZ3MKMCBnCmUKZ3IKQ00gMS45OTYg MiBzY2FsZQpzClNNCm4KMjM1OCAyNTE2IE0KMjQ5NCAyNzA0IEwKQ00gMS45 OTYgMiBzY2FsZQpzClNNCm4KNDcgOTQgMjUxMiAyNTg4IEIKMSBnCmYKMCBn CigxKTI1MTIgMjY2MyBNUwpuCjI0OTQgMjcwNCBNCjI0NzYgMjYyOCBMCkNN IDEuOTk2IDIgc2NhbGUKcwpTTQpuCjI0OTQgMjcwNCBNCjI0MjggMjY2NCBM CkNNIDEuOTk2IDIgc2NhbGUKcwpTTQpuCjQ4IDk0IDIzMTIgMjM0OCBCCjEg ZwpmCjAgZwooMSkyMzEyIDI0MjMgTVMKbgozMjQgOTQgMjA3OCAyNTkwIEIK MSBnCmYKMCBnCigtX3Jlc3VsdHMpMjA3OCAyNjY1IE1TCm4KNDcgOTQgMjUx MiAyNTg4IEIKMSBnCmYKMCBnCigxKTI1MTIgMjY2MyBNUwowLjE5MSBnCm4K MjAzOCAxNjYyIE0KMjAzOCAxNTE2IEwKQ00gMS45OTYgMiBzY2FsZQpzClNN Cm4KNDggOTQgMjA5MiAxNTQyIEIKMSBnCmYKMCBnCigxKTIwOTIgMTYxNyBN UwowLjE5MSBnCm4KMjAzOCAxNTE2IE0KMjA2OCAxNTcwIEwKMjAzOCAxNjI0 IEwKMjAwOCAxNTcwIEwKMjAzOCAxNTE2IEwKY3AKZ3MKMSBnCmUKZ3IKQ00g MS45OTYgMiBzY2FsZQpzClNNCm4KMjAzOCAxNjYyIE0KMjAzOCAxODEwIEwK Q00gMS45OTYgMiBzY2FsZQpzClNNCm4KMTI2IDk0IDIwODYgMTY5NCBCCjEg ZwpmCjAgZwooMC4uKikyMDg2IDE3NjkgTVMKbgoyMDM4IDE4MTAgTQoyMDY4 IDE3MzggTApDTSAxLjk5NiAyIHNjYWxlCnMKU00KbgoyMDM4IDE4MTAgTQoy MDA4IDE3MzggTApDTSAxLjk5NiAyIHNjYWxlCnMKU00Kbgo0OCA5NCAyMDky IDE1NDIgQgoxIGcKZgowIGcKKDEpMjA5MiAxNjE3IE1TCm4KMTI2IDk0IDIw ODYgMTY5NCBCCjEgZwpmCjAgZwooMC4uKikyMDg2IDE3NjkgTVMKc2hvd3Bh Z2UKQWRvYmVfV2luTlRfRHJpdmVyX0dmeCBkdXAgL3Rlcm1pbmF0ZSBnZXQg ZXhlYwpQYWdlU1YgcmVzdG9yZQolJVRyYWlsZXIKJSVEb2N1bWVudE5lZWRl ZEZvbnRzOgolJSsgSGVsdmV0aWNhCiUlRG9jdW1lbnRTdXBwbGllZEZvbnRz OgplbmQKJSVQYWdlczogMQolJUVPRgoE --0-1789315892-918563186=:5379 Content-Type: APPLICATION/PDF; name="RRL3_main_view.pdf" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="RRL3_main_view.pdf" JVBERi0xLjENCiXi48/TDQoxIDAgb2JqDQo8PA0KL1R5cGUgL1hPYmplY3QN Ci9TdWJ0eXBlIC9JbWFnZQ0KL05hbWUgL0ltMQ0KL1dpZHRoIDE2DQovSGVp Z2h0IDE1DQovQml0c1BlckNvbXBvbmVudCA4DQovQ29sb3JTcGFjZSAyIDAg Ug0KL0xlbmd0aCAxMTANCi9GaWx0ZXIgL0xaV0RlY29kZQ0KPj4NCnN0cmVh bQ0KgAAgQAAMFAMDhEIAICAYDAUHhMDhcPicQiMLAMNjERgUGj0WhUNkUNh4 AAkKAoClUrh4EAwHiUpikylwGA0ngkplMTBE2n0nicsA8+mwEmEEj01nwHnE RA89otHjkmodMqcIBAEptXgVSgUBDQplbmRzdHJlYW0NCmVuZG9iag0KMyAw IG9iag0KPDwNCi9UeXBlIC9YT2JqZWN0DQovU3VidHlwZSAvSW1hZ2UNCi9O YW1lIC9JbTINCi9XaWR0aCAxNg0KL0hlaWdodCAxNQ0KL0JpdHNQZXJDb21w b25lbnQgOA0KL0NvbG9yU3BhY2UgNCAwIFINCi9MZW5ndGggNzANCi9GaWx0 ZXIgL0xaV0RlY29kZQ0KPj4NCnN0cmVhbQ0KgAAgUDggBgkHg4BAQDhEIAgC iAFhsDAsQi0SiYBh8WhcTAAFhUcjENAkViMGjwBAYCjUeigFkcuAEMmU1m03 nE5AEBANCmVuZHN0cmVhbQ0KZW5kb2JqDQo1IDAgb2JqDQo8PA0KL1R5cGUg L1hPYmplY3QNCi9TdWJ0eXBlIC9JbWFnZQ0KL05hbWUgL0ltMw0KL1dpZHRo IDE2DQovSGVpZ2h0IDE1DQovQml0c1BlckNvbXBvbmVudCA4DQovQ29sb3JT cGFjZSA0IDAgUg0KL0xlbmd0aCA3MA0KL0ZpbHRlciAvTFpXRGVjb2RlDQo+ Pg0Kc3RyZWFtDQqAACBQOCAGCQeDgEBAOEQgCAKIAWGwMCxCLRKJgGHxaFxM AAWFRyMQ0CRWIwaPAEBgKNR6KAWRy4AQyZTWbTecTkAQEA0KZW5kc3RyZWFt DQplbmRvYmoNCjYgMCBvYmoNCjw8DQovVHlwZSAvWE9iamVjdA0KL1N1YnR5 cGUgL0ltYWdlDQovTmFtZSAvSW00DQovV2lkdGggMTYNCi9IZWlnaHQgMTUN Ci9CaXRzUGVyQ29tcG9uZW50IDgNCi9Db2xvclNwYWNlIDQgMCBSDQovTGVu Z3RoIDcwDQovRmlsdGVyIC9MWldEZWNvZGUNCj4+DQpzdHJlYW0NCoAAIFA4 IAYJB4OAQEA4RCAIAogBYbAwLEItEomAYfFoXEwABYVHIxDQJFYjBo8AQGAo 1HooBZHLgBDJlNZtN5xOQBAQDQplbmRzdHJlYW0NCmVuZG9iag0KNyAwIG9i ag0KPDwNCi9UeXBlIC9YT2JqZWN0DQovU3VidHlwZSAvSW1hZ2UNCi9OYW1l IC9JbTUNCi9XaWR0aCAxNg0KL0hlaWdodCAxNQ0KL0JpdHNQZXJDb21wb25l bnQgOA0KL0NvbG9yU3BhY2UgNCAwIFINCi9MZW5ndGggNzANCi9GaWx0ZXIg L0xaV0RlY29kZQ0KPj4NCnN0cmVhbQ0KgAAgUDggBgkHg4BAQDhEIAgCiAFh sDAsQi0SiYBh8WhcTAAFhUcjENAkViMGjwBAYCjUeigFkcuAEMmU1m03nE5A EBANCmVuZHN0cmVhbQ0KZW5kb2JqDQo4IDAgb2JqDQo8PA0KL1R5cGUgL1hP YmplY3QNCi9TdWJ0eXBlIC9JbWFnZQ0KL05hbWUgL0ltNg0KL1dpZHRoIDE2 DQovSGVpZ2h0IDE1DQovQml0c1BlckNvbXBvbmVudCA4DQovQ29sb3JTcGFj ZSA0IDAgUg0KL0xlbmd0aCA3MA0KL0ZpbHRlciAvTFpXRGVjb2RlDQo+Pg0K c3RyZWFtDQqAACBQOCAGCQeDgEBAOEQgCAKIAWGwMCxCLRKJgGHxaFxMAAWF RyMQ0CRWIwaPAEBgKNR6KAWRy4AQyZTWbTecTkAQEA0KZW5kc3RyZWFtDQpl bmRvYmoNCjEwIDAgb2JqDQo8PA0KL0xlbmd0aCAyMTUzDQovRmlsdGVyIC9M WldEZWNvZGUNCj4+DQpzdHJlYW0NCoAMBcORuNxAZwaCoEMRyMRAR4TDiUIB gIDVFBcMhoIDuIBjFSaIC2XYqZISQiwIBeRynDjOcxARSxERAaRBCRkMBoLh oNRANxyNRcMBnHqILhqNhALRsMRcOBAcjLJxVJypCReRodDioZojAhhUIrFY /Q6hGhmLhnRRuOLSMxyICobYTFYRCrkY4SKCkUiYMxSVDVCSLVwVOZ3PZ+OI ENqLH7TSaWNBvPKjU8POp5Phvjqfj6PkhaM8bl4SU4ScYSORdSrGIBxT7OMB trYdBYEM4cY7oCheSTbDiIb4SUatX7NFOVZbCIBkMdrz5+N4Xcbndbkd72JB AXzKbjocjSZZgOhAdjKYzobzlgcGCsLqdXreVFdiONntabP8oLhunzeKw4AZ BA4biuOBTmLE5awLO6CMtu/rHLk3oUDqNw0jiOoyiK8A5DyKQyw08g6C4FAu BS9zCMM1QFNY1zlPu/LbJ+GbasoEEAt84CiwMBTjAUITDQU+qjOS57otvGy1 J864FQs8A0joNgyjJE0URU+DDIEgiDLu6AZNauIahgyoZIMG6nPwpa4Iyjap KpBEiNfIjoNqGCfBoHCdrdCjsLuvi/BmL8OvCPIkiJLL4wSG0whsuM9TDMqf zUqAWhinadNNRlHUgzqkM5SqltiGsCTgBTUSDIcGyLOobp26QaKC1qiycFAe B5QspDyHwfUVLaBoKg6cKAtSizJMyDIagcCNG1iNU2ISq1U5DmzpVgZBwpwY IdPU+Vq3q7L2vq/0JD0QPIOo2DoOdf2I1i1hBSKh2Upwc2bTChzezEz3gorK NqGqfWXe9RqRUzMVTIVqwWslWNJLl/1nCdbVxXQ6V5XzBRWutgy8nAZ1ghwb BxO6DBpTKNtGoU11PaSaLuGQbIEG6i0e6KDOe/1mpyjKoVOr0EofjoYwIjot hjMyoKEzoQJIECTMPmcaZutS450HKlBbntS03VKKohqTG5HrOrOde2ta5hDT pxRqnrjR60hzq6BWypciaBBDWaLIu9wJmS024EGSZZcE/r2L4qDyFgQXdoWY 7cHG4Lcgatqdu1L1ZvNqRcF2+NfvznM9wQbP+/0m3DYcni+IMs63z08KKFqB clHAqCIvb0PU9nHOqh2w7qjej6fqIZZDCHBhsxOT5Tu9YZ/fnjukGwatYGl/ +aFtn33tmhIunCkoyuLqNZPrehl8IZfGtfPIcNnupdtvAyUtIYodpmtftn1N 6DhcEqsWukd0ZtyNPtT8XhQAMXHPoOi+t+pDnzvVbeT9mStAQPvMO+l8bPQY k+gw+hTsFD9FFg/BpGsD4LkJDEtOBj4ifgwfKUWCMDXBslLU+5+Dqn0GxUfC 8ypDQQP4bu5d6BCX+qrOTAE5sO0xODBybGICTlxJPgUxtLR2GwwtfVDU2pug QQRfK3AHJOygwpgzDRkkXYIPghCo+MkHocuQfnCeA0QlLxEf4nKACDIBRzBv AV+0B4pgoiqe9Rb8TMmVBqmgGDdSiptRtEN/bm3/Jzj5EtMpSCDKPcu4aBBe wWneQ8eNdsVpDw6BrDx8cmYgR2f03aSkSFrSXLPKmJqj4oFcdTAl3rHnVO+a GXh75mUwrCKaTtgRRjasFKYmpaK05Kx7YckdbMtwYJhijLtcaglzKGgXNc/0 m5GueJ8R+ZazT+vcmJOGIMY4LTmWYZNUSp1UotRekVGRzjNA5WOW1UCOTem/ DaRtHyQJoxJlo2eZE/TYvXgOCgqQZw0hvDcEUPAaQ5rsSuimUyLD5owPsbKf UZFjulIyQZHVAifUFj1QiacS18g1pKZWDtDw5hlDoiGiVFKNuOnsfQ18+TEE DWOwIgZcaUnAKVSxzklqXoOoXEGowOCDK2DCGQMgSTwBlKlRlKoVDxBnDPVy ntHSaTDBk8aCdMiwEGfODORRBmBKOhJHEnD1yhpjTITyuR/n8x4liwxVq2K8 QwiCDQpztptRUgXXCTVUq6RfZAZVeINSeueLjB80hTyfWWKc9WMzxltpjVkU Ouph7HSLshBaDEKycVqclEGzak3zllOksgpEOFUMwte5ezpDKjxBr9JKWBmI j2CiUWdnT6IgllbnIJ1UhHezBOe3V+8mQaxrMO0mtYMXA2nuq8i3F2bJXbKc 9S5ptaqRmVTIgtFeapECRxK6wFxqWyzqec6wtpLE1VsXdKszjyIn4LVXKtM7 1n3EiKAq47/6XJGOaDHAlcLmlpYpf+UKiHHXuuXb81lz76STvtU2aWELlW+u alw61/5CscIVZh35OJ3Q9rYvS8qZ4eP3VLayuxh3JOerlXt41wmmx3xFEa+7 DcTHOx+0mw8nboS8wDjhGlc4LPnBwUKytpbyQfhsniw6kiDQfWLaqyxQiGWh n8fvKyE7WwsxmmO2dbiEm6W3deRVur2uqN0/XA1iVjmtZVK/BeDanZLz7kC5 qYaHRSuji2K5eGw52KHni3N5TSH3t/COM2lHBXju0aRwKY2iw3vZbzHze8gy OyJX/I+DMk2DSPk2uViCMyekHpCU7kLRxBZ1mkGc+cjXFyRiTB6RGZa9uymH NOjlAShq6updmG8+Xe0UqXQFwnlYKjzsa/GiNrZO2WTzXGj5ekMxjGeFxjkw zJhnuuvak4MZ7chMWTYNJl2duHsPQusbkui3s4Ox0ZdnF710kOVEaN450gzG FwdeLQQljRY6QMJY28Qsy+DhVbYzWu3VFvdk/938gXyUDU7UlJE+UabFNJHs 0L4vrsWg+39kNuzAU01nLeCpPIEC4FV04swmmOf4uMYIJqNLTQ7iW6+S9FjZ LetXSsesy4C8rfOrduWBwdzRbDbpjcDdQ4exmAb3c25VNXlsHXPcw1fobEvN eUuDuBzq//Pef4BICA0KZW5kc3RyZWFtDQplbmRvYmoNCjExIDAgb2JqDQo8 PA0KL1Byb2NTZXQgWy9QREYgL1RleHQgL0ltYWdlQyAvSW1hZ2VJXQ0KL0Zv bnQgPDwNCi9GMSAxMiAwIFINCj4+DQovWE9iamVjdCA8PA0KL0ltMSAxIDAg Ug0KL0ltMiAzIDAgUg0KL0ltMyA1IDAgUg0KL0ltNCA2IDAgUg0KL0ltNSA3 IDAgUg0KL0ltNiA4IDAgUg0KPj4NCi9FeHRHU3RhdGUgPDwNCi9HUzEgMTMg MCBSDQo+Pg0KL0NvbG9yU3BhY2UgPDwNCi9DUzEgMiAwIFINCi9DUzIgNCAw IFINCj4+DQo+Pg0KZW5kb2JqDQoyIDAgb2JqDQpbL0luZGV4ZWQgL0Rldmlj ZVJHQiAxNSAxNSAwIFJdDQplbmRvYmoNCjE1IDAgb2JqDQo8PA0KL0ZpbHRl ciAvQVNDSUk4NURlY29kZQ0KL0xlbmd0aCA0NA0KPj4NCnN0cmVhbQ0KITwz JCEhISVcKEtgRClQISElXGxfbztdVnJyPCchS0UtWip6enp6en4+DQplbmRz dHJlYW0NCmVuZG9iag0KNCAwIG9iag0KWy9JbmRleGVkIC9EZXZpY2VSR0Ig NyAxNiAwIFJdDQplbmRvYmoNCjE2IDAgb2JqDQo8PA0KL0ZpbHRlciAvQVND SUk4NURlY29kZQ0KL0xlbmd0aCAzMA0KPj4NCnN0cmVhbQ0KITwzJCEhISok IXMrQ0BQS0UtWiohLyg9UHp+Pg0KZW5kc3RyZWFtDQplbmRvYmoNCjE3IDAg b2JqDQo8PA0KL1R5cGUgL0hhbGZ0b25lDQovSGFsZnRvbmVUeXBlIDENCi9I YWxmdG9uZU5hbWUgKERlZmF1bHQpDQovRnJlcXVlbmN5IDYwDQovQW5nbGUg NDUNCi9TcG90RnVuY3Rpb24gL1JvdW5kDQo+Pg0KZW5kb2JqDQoxMyAwIG9i ag0KPDwNCi9UeXBlIC9FeHRHU3RhdGUNCi9TQSBmYWxzZQ0KL09QIGZhbHNl DQovSFQgL0RlZmF1bHQNCj4+DQplbmRvYmoNCjEyIDAgb2JqDQo8PA0KL1R5 cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UeXBlMQ0KL05hbWUgL0YxDQovQmFzZUZv bnQgL0hlbHZldGljYQ0KPj4NCmVuZG9iag0KOSAwIG9iag0KPDwNCi9UeXBl IC9QYWdlDQovUGFyZW50IDE0IDAgUg0KL1Jlc291cmNlcyAxMSAwIFINCi9D b250ZW50cyAxMCAwIFINCj4+DQplbmRvYmoNCjE0IDAgb2JqDQo8PA0KL1R5 cGUgL1BhZ2VzDQovS2lkcyBbOSAwIFJdDQovQ291bnQgMQ0KL01lZGlhQm94 IFswIDAgNTk1IDg0Ml0NCj4+DQplbmRvYmoNCjE4IDAgb2JqDQo8PA0KL1R5 cGUgL0NhdGFsb2cNCi9QYWdlcyAxNCAwIFINCj4+DQplbmRvYmoNCjE5IDAg b2JqDQo8PA0KL0NyZWF0aW9uRGF0ZSAoRDoxOTk5MDIwOTExNTcyNCkNCi9Q cm9kdWNlciAoXDM3NlwzNzdcMDAwQVwwMDBjXDAwMHJcMDAwb1wwMDBiXDAw MGFcMDAwdFwwMDAgXDAwMERcMDAwaVwwMDBzXDAwMHRcMDAwaVwwMDBsXDAw MGxcMDAwZVwwMDByXDAwMCBcMDAwM1wwMDAuXDAwMDBcMDAwMVwwMDAgXDAw MGZcMDAwb1wwMDByXDAwMCBcMDAwV1wwMDBpXDAwMG5cMDAwZFwwMDBvXDAw MHdcMDAwcykNCi9DcmVhdG9yIChXaW5kb3dzIE5UIDQuMCkNCi9UaXRsZSAo Um9zZSBEaWFncmFtXChzXCkpDQo+Pg0KZW5kb2JqDQp4cmVmDQowIDIwDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMTcgMDAwMDAgbg0KMDAwMDAw NDA3MCAwMDAwMCBuDQowMDAwMDAwMzEyIDAwMDAwIG4NCjAwMDAwMDQyNDUg MDAwMDAgbg0KMDAwMDAwMDU2NiAwMDAwMCBuDQowMDAwMDAwODIwIDAwMDAw IG4NCjAwMDAwMDEwNzQgMDAwMDAgbg0KMDAwMDAwMTMyOCAwMDAwMCBuDQow MDAwMDA0NzA3IDAwMDAwIG4NCjAwMDAwMDE1ODIgMDAwMDAgbg0KMDAwMDAw MzgxNCAwMDAwMCBuDQowMDAwMDA0NjE4IDAwMDAwIG4NCjAwMDAwMDQ1Mzgg MDAwMDAgbg0KMDAwMDAwNDc5OCAwMDAwMCBuDQowMDAwMDA0MTIwIDAwMDAw IG4NCjAwMDAwMDQyOTQgMDAwMDAgbg0KMDAwMDAwNDQwNSAwMDAwMCBuDQow MDAwMDA0ODg4IDAwMDAwIG4NCjAwMDAwMDQ5NDUgMDAwMDAgbg0KdHJhaWxl cg0KPDwNCi9TaXplIDIwDQovUm9vdCAxOCAwIFINCi9JbmZvIDE5IDAgUg0K L0lEIFs8Y2M0MDhkMDY3ZDAxODliMWZmMGJkNjliODVkZjdmZjk+PGNjNDA4 ZDA2N2QwMTg5YjFmZjBiZDY5Yjg1ZGY3ZmY5Pl0NCj4+DQpzdGFydHhyZWYN CjUyNTINCiUlRU9GDQo= --0-1789315892-918563186=:5379 Content-Type: APPLICATION/PostScript; name="RRL3_single_entry_creation.ps" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="RRL3_single_entry_creation.ps" JSFQUy1BZG9iZS0zLjAKJSVUaXRsZTogUm9zZSBEaWFncmFtKHMpCiUlQ3Jl YXRvcjogV2luZG93cyBOVCA0LjAKJSVDcmVhdGlvbkRhdGU6IDExOjU5IDIv OS8xOTk5CiUlUGFnZXM6IChhdGVuZCkKJSVCb3VuZGluZ0JveDogMTEgMTUg NTgyIDgzMQolJUxhbmd1YWdlTGV2ZWw6IDIKJSVEb2N1bWVudE5lZWRlZEZv bnRzOiAoYXRlbmQpCiUlRG9jdW1lbnRTdXBwbGllZEZvbnRzOiAoYXRlbmQp CiUlRW5kQ29tbWVudHMKJSVCZWdpblByb2xvZwoNCiUlQmVnaW5SZXNvdXJj ZTogcHJvY3NldCBOVFBTT2N0OTUNCi9OVFBTT2N0OTUgMTAwIGRpY3QgZHVw IGJlZ2luL2Jke2JpbmQgZGVmfWJpbmQgZGVmL2xke2xvYWQgZGVmfWJkL2Vk e2V4Y2ggZGVmfQ0KYmQvYXtjdXJyZW50cG9pbnR9YmQvYy9jdXJ2ZXRvIGxk L2QvZHVwIGxkL2UvZW9maWxsIGxkL2YvZmlsbCBsZC90ci90cmFuc2xhdGUN CmxkL2dyL2dyZXN0b3JlIGxkL2dzL2dzYXZlIGxkL2ovc2V0bGluZWpvaW4g bGQvTC9saW5ldG8gbGQvTS9tb3ZldG8gbGQvbg0KL25ld3BhdGggbGQvY3Av Y2xvc2VwYXRoIGxkL3JtL3Jtb3ZldG8gbGQvc2wvc2V0bGluZXdpZHRoIGxk L3NkL3NldGRhc2ggbGQvZw0KL3NldGdyYXkgbGQvci9zZXRyZ2Jjb2xvciBs ZC9zL3N0cm9rZSBsZC90L3Nob3cgbGQvYXcvYXdpZHRoc2hvdyBsZC9pbQ0K L2ltYWdlbWFzayBsZC9NU3ttb3ZldG8gc2hvd31iZC9TRntmaW5kZm9udCBl eGNoIHNjYWxlZm9udCBzZXRmb250fWJkL1NNe2NtdHgNCnNldG1hdHJpeH1i ZC9NRntmaW5kZm9udCBleGNoIG1ha2Vmb250IHNldGZvbnR9YmQvQ017L2Nt dHggbWF0cml4IGN1cnJlbnRtYXRyaXgNCmRlZn1iZC9Ce00gZXhjaCBkdXAg MCBybHQgZXhjaCAwIGV4Y2ggcmx0IG5lZyAwIHJsdH1iZC9DQntCIGNwIGVv Y2xpcH1iZC9FQXsxDQppbmRleCAwL0cwIHB1dCA0IHN0cmluZyAxIDEgNCAt MSByb2xsezMgY29weSBuZWcgZXhjaCBjdnMgZHVwIDAgNzEgcHV0IGN2biAz IC0xDQpyb2xsIGV4Y2ggcHV0fWZvciBwb3B9YmQvcmx0L3JsaW5ldG8gbGQv TDI/L2xhbmd1YWdlbGV2ZWwgd2hlcmV7cG9wDQpsYW5ndWFnZWxldmVsIDIg Z2V9e2ZhbHNlfWlmZWxzZSBkZWYgZW5kIGRlZiANCiUlRW5kUmVzb3VyY2UN CiUlRW5kUHJvbG9nCiUlQmVnaW5TZXR1cApbezAKL2xhbmd1YWdlbGV2ZWwg d2hlcmV7cG9wIGxhbmd1YWdlbGV2ZWwgMiBnZX17ZmFsc2V9aWZlbHNlCnsx IGRpY3QgZHVwL0pvYlRpbWVvdXQgNCAtMSByb2xsIHB1dCBzZXR1c2VycGFy YW1zfQp7c3RhdHVzZGljdC9zZXRqb2J0aW1lb3V0IGdldCBleGVjfWlmZWxz ZQp9c3RvcHBlZCBjbGVhcnRvbWFyawpbezMwMAovbGFuZ3VhZ2VsZXZlbCB3 aGVyZXtwb3AgbGFuZ3VhZ2VsZXZlbCAyIGdlfXtmYWxzZX1pZmVsc2UKezEg ZGljdCBkdXAvV2FpdFRpbWVvdXQgNCAtMSByb2xsIHB1dCBzZXR1c2VycGFy YW1zfQp7c3RhdHVzZGljdC93YWl0dGltZW91dCAzIC0xIHJvbGwgcHV0fWlm ZWxzZQp9c3RvcHBlZCBjbGVhcnRvbWFyawovI2NvcGllcyAxIGRlZgpbewol JUJlZ2luRmVhdHVyZTogKlNtb290aGluZyBGYWxzZQoNCiAgMiBkaWN0IGR1 cCAvUG9zdFJlbmRlcmluZ0VuaGFuY2UgZmFsc2UgcHV0IHNldHBhZ2VkZXZp Y2UNCgolJUVuZEZlYXR1cmUKfSBzdG9wcGVkIGNsZWFydG9tYXJrClt7CiUl QmVnaW5GZWF0dXJlOiAqQml0c1BlclBpeGVsIE5vbmUKDQogIDIgZGljdCBk dXAgL1ByZVJlbmRlcmluZ0VuaGFuY2UgZmFsc2UgcHV0IHNldHBhZ2VkZXZp Y2UNCgolJUVuZEZlYXR1cmUKfSBzdG9wcGVkIGNsZWFydG9tYXJrClt7CiUl QmVnaW5GZWF0dXJlOiAqUGFnZVNpemUgQTQKDQogICAyIGRpY3QgZHVwIC9Q YWdlU2l6ZSBbNTk1IDg0Ml0gcHV0IGR1cCAvSW1hZ2luZ0JCb3ggbnVsbCBw dXQgc2V0cGFnZWRldmljZQolJUVuZEZlYXR1cmUKfSBzdG9wcGVkIGNsZWFy dG9tYXJrClt7CiUlQmVnaW5GZWF0dXJlOiAqVHJheVN3aXRjaCBGYWxzZQox IGRpY3QgZHVwIC9UcmF5U3dpdGNoIGZhbHNlIHB1dCBzZXRwYWdlZGV2aWNl CiUlRW5kRmVhdHVyZQp9IHN0b3BwZWQgY2xlYXJ0b21hcmsKW3sKJSVCZWdp bkZlYXR1cmU6ICpWTU9wdGlvbiA4TWVnCgolJUVuZEZlYXR1cmUKfSBzdG9w cGVkIGNsZWFydG9tYXJrClt7CiUlQmVnaW5GZWF0dXJlOiAqT3B0aW9uYWxD YXNzZXR0ZTEgRmFsc2UKCiUlRW5kRmVhdHVyZQp9IHN0b3BwZWQgY2xlYXJ0 b21hcmsKW3sKJSVCZWdpbkZlYXR1cmU6ICpPcHRpb25hbEVudmVsb3BlRmVl ZGVyIEZhbHNlCgolJUVuZEZlYXR1cmUKfSBzdG9wcGVkIGNsZWFydG9tYXJr CiUlRW5kU2V0dXAKTlRQU09jdDk1IGJlZ2luCiUlUGFnZTogMSAxCk5UUFNP Y3Q5NSAvUGFnZVNWIHNhdmUgcHV0CjExLjY4IDgzMS45NjEgdHJhbnNsYXRl IDcyIDYwMCBkaXYgZHVwIG5lZyBzY2FsZQowIDAgdHJhbnNmb3JtIC4yNSBh ZGQgcm91bmQgLjI1IHN1YiBleGNoIC4yNSBhZGQgcm91bmQgLjI1IHN1YiBl eGNoIGl0cmFuc2Zvcm0gdHJhbnNsYXRlCjEgc2V0bGluZWNhcAoxIHNsCjAu MTkxIGcKbgo1OTkgMjE1IDEwMzQgNDkwIEIKY3AKZ3MKMC45NzcgZwplCmdy CkNNIDEuOTk2IDIgc2NhbGUKcwpTTQolJUluY2x1ZGVGb250OiBIZWx2ZXRp Y2EKWzg0IDAgMCAtODQgMCAwXS9IZWx2ZXRpY2EgTUYKMCBnCiggOiBSZWdp b25Jbml0KTExMTAgNTc5IE1TCm4KNDQ4IDUgMTExMCA1ODggQgpmCihNb2R1 bGUpMTE5NiA2NzMgTVMKbgoyNzUgNSAxMTk2IDY4MiBCCmYKWzE0NCA0OCBd MCBzZAoxIGcKbgoxMzM0IDc4NiBNCjEzMzQgMjEzMiBMCnMKMCBnCm4KMTMz NCA3ODYgTQoxMzM0IDIxMzIgTApzCltdMCBzZAowLjE5MSBnCm4KNTkgOTEx IDEzMDQgODU0IEIKY3AKZ3MKMSBnCmUKZ3IKQ00gMS45OTYgMiBzY2FsZQpz ClNNCm4KNTk4IDIyMyAyNTA2IDQ4NiBCCmNwCmdzCjAuOTc3IGcKZQpncgpD TSAxLjk5NiAyIHNjYWxlCnMKU00KMCBnCih0aGVSUkwzIDogUlJMMykyNDk4 IDU3OSBNUwpuCjYxNyA1IDI0OTggNTg4IEIKZgpbMTQ0IDQ4IF0wIHNkCjEg ZwpuCjI4MDUgNzg2IE0KMjgwNSAyMTMyIEwKcwowIGcKbgoyODA1IDc4NiBN CjI4MDUgMjEzMiBMCnMKW10wIHNkCjAuMTkxIGcKbgo1OSAxMTkgMjc3NSA4 ODYgQgpjcApncwoxIGcKZQpncgpDTSAxLjk5NiAyIHNjYWxlCnMKU00Kbgo2 MzEgMjIzIDMzODUgNDg2IEIKY3AKZ3MKMC45NzcgZwplCmdyCkNNIDEuOTk2 IDIgc2NhbGUKcwpTTQowIGcKKFJlcXVlc3RlZEVudHJ5IDogKTMzNjUgNTc5 IE1TCm4KNjcxIDUgMzM2NSA1ODggQgpmCihSUkwzX0VudHJ5KTM0NzMgNjcz IE1TCm4KNDU3IDUgMzQ3MyA2ODIgQgpmClsxNDQgNDggXTAgc2QKMSBnCm4K MzcwMSA3ODYgTQozNzAxIDIxMzIgTApzCjAgZwpuCjM3MDEgNzg2IE0KMzcw MSAyMTMyIEwKcwpbXTAgc2QKMC4xOTEgZwpuCjU5IDExOSAzNjcxIDExMTAg QgpjcApncwoxIGcKZQpncgpDTSAxLjk5NiAyIHNjYWxlCnMKU00Kbgo1OSAx MTkgMzY3MSAxMzM0IEIKY3AKZ3MKMSBnCmUKZ3IKQ00gMS45OTYgMiBzY2Fs ZQpzClNNCm4KNTkgMTE5IDM2NzEgMTUyNiBCCmNwCmdzCjEgZwplCmdyCkNN IDEuOTk2IDIgc2NhbGUKcwpTTQoxIGoKbgoxMzY2IDg4NiBNCjI3NzMgODg2 IEwKQ00gMS45OTYgMiBzY2FsZQpzClNNCjMgc2wKbgoyNzczIDg4NiBNCjI3 MDEgOTE2IEwKQ00gMS45OTYgMiBzY2FsZQpzClNNCm4KMjc3MyA4ODYgTQoy NzAxIDg1NiBMCkNNIDEuOTk2IDIgc2NhbGUKcwpTTQpuCjEzNjEgOTQgMTM5 MCA3ODAgQgoxIGcKZgowIGcKKHVuaXF1ZUVudHJ5UmVxdWVzdFwoUlJMM19F bnRyeUlEXCkpMTM5MCA4NTUgTVMKMSBzbAowLjE5MSBnCm4KMTM2NiAxMzM0 IE0KMzY2OSAxMzM0IEwKQ00gMS45OTYgMiBzY2FsZQpzClNNCjMgc2wKbgoz NjY5IDEzMzQgTQozNTk3IDEzNjQgTApDTSAxLjk5NiAyIHNjYWxlCnMKU00K bgozNjY5IDEzMzQgTQozNTk3IDEzMDQgTApDTSAxLjk5NiAyIHNjYWxlCnMK U00Kbgo1NDAgOTQgMTQ0NiAxMjAyIEIKMSBnCmYKMCBnCihyZWdpb25FeGlz dHNcKCBcKSkxNDQ2IDEyNzcgTVMKMSBzbAowLjE5MSBnCm4KMTM2NiAxNTI2 IE0KMzY2OSAxNTI2IEwKQ00gMS45OTYgMiBzY2FsZQpzClNNCjMgc2wKbgoz NjY5IDE1MjYgTQozNTk3IDE1NTYgTApDTSAxLjk5NiAyIHNjYWxlCnMKU00K bgozNjY5IDE1MjYgTQozNTk3IDE0OTYgTApDTSAxLjk5NiAyIHNjYWxlCnMK U00KbgoxMDMwIDk0IDE0MzAgMTM3MiBCCjEgZwpmCjAgZwooc2V0UmVnaW9u XChUcmFja2luZ1JlZ2lvblwpKTE0MzAgMTQ0NyBNUwoxIHNsCjAuMTkxIGcK bgoxMzY2IDExMTAgTQozNjY5IDExMTAgTApDTSAxLjk5NiAyIHNjYWxlCnMK U00KMyBzbApuCjM2NjkgMTExMCBNCjM1OTcgMTE0MCBMCkNNIDEuOTk2IDIg c2NhbGUKcwpTTQpuCjM2NjkgMTExMCBNCjM1OTcgMTA4MCBMCkNNIDEuOTk2 IDIgc2NhbGUKcwpTTQpuCjEyODUgOTQgMTQyNCAxMDEyIEIKMSBnCmYKMCBn CihhZGRJbnRlcmVzdGVkVHJpZ2dlclwoTDNUcmlnZ2VySURcKSkxNDI0IDEw ODcgTVMKc2hvd3BhZ2UKUGFnZVNWIHJlc3RvcmUKJSVUcmFpbGVyCiUlRG9j dW1lbnROZWVkZWRGb250czoKJSUrIEhlbHZldGljYQolJURvY3VtZW50U3Vw cGxpZWRGb250czoKZW5kCiUlUGFnZXM6IDEKJSVFT0YKBA== --0-1789315892-918563186=:5379 Content-Type: APPLICATION/PDF; name="RRL3_single_entry_creation.pdf" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="RRL3_single_entry_creation.pdf" JVBERi0xLjENCiXi48/TDQoyIDAgb2JqDQo8PA0KL0xlbmd0aCAxMTgwDQov RmlsdGVyIC9MWldEZWNvZGUNCj4+DQpzdHJlYW0NCoAMBcORuNxAZwaCoEMR yMRAR4TDiUIBgIDVFBcMhoIDuIBjFSaIC2XYqZISQiwIBeRynDjOcxARSxER AaRBERmNRcOIdBRmLoYIBuMZ2OBALRlOqMcjLJxVJypCReRodDioZojAhhRo rFY+Lq3HhoNIGM6ENhkLhrVjbCYrCIUICoY7dcjvCRQIB0ICkZTOaTebiSbj SdBSVDVCSLUQUMbHZbPRBpZhrPxuNqPAsxTITWAUQsZX7DXY9WqMMRrOqTQr XGbMVLaChQTTeZDqbDLh8SCsXEdTGRrrIXwRnZhbmhBnAVnodEIVQBlHJEMR vGaNOsuIJIIJNjaHO56M+qNoNsepRJ4IBrl6BwTZCSnded5/BQvELvIIPN3/ T6xs9oQPeBT4sag63KAhqHwOjTpJGkqIhsHCMp6GQcrUnqwKMFqPwsGbouUI SnuegiDLgGYYrSGjgp8/CDO+7KkP+7MQRE0CswyikctEo0TskHKzrSta5Nit 68DoNAyikKQmLMvclSY3TFMZHoXBpH7LskswbrIGCNuO/Dkqa5aaOchboo6L bqOs9QXOy7buhmGkJOK+zxvKhM4zmyj2NRAL4PlPE5BdOgbvu/LYzzQc9v/P sBQIl0DoY5sFo3NE30CslCqEpMWqFHENrIGSlzFEMDxJAwFBpNQcy1QtOhu7 DoxjNrN1JGrQtNHKvVzVSdMrIELyGuq4BQvo4jqMo5joMoyCKNw6DkPK9BBK LeMZXq1S0G0shAHCBBrWTkOUz0bMbXLSR2EAaVFKsrtaGTXtjYslhmL9nWgP Nqt7VN2Ss4UABqsgcS9cUxOZBTnxRBs1VFNk3QfVLfhxFdDTviKlOC/0AUdQ GLp3ik7P0hMVYw9U+PdP8CrghcEzKjNKpFS+IrS1YbBzCQbyvT7HTXGmR3A4 AQPIokEuqsNQZ7W2f5o4IbUEHEXZ3UNRqcmiLojWD8RXTlD0xdtNp0/OOOeo cfo7r1/BvrmLOLku1LSGCDQFOKybTteRAVtuP03CwZbllLqQlX9CznH4Yhsn 8PKOGKiYbcaoRu0cdVzwNs75QcfthYa8DqwljjLe9o2NZFlC5ecmXtZ9oiSI guBTfTGIFBmzu9sOmu/BLYxVuCHaGgaHbGgWyulpawd73CHd0ydBoMG0I0H4 Hihh4+ieTkflvFoWsyFsdIMbiegwi6tYaFgXF8bqkxs/XEcXRynwZqG+cODz S42Ipi/sCIo8DTZQ5umBA652ClHiO1a0+VCTUG8O7eNAgnbf0BoHeG7SBj04 HQKeU4l5qKiMwQgq71p7FixwaaE0AGkEFHqoBiDhxJZnnHVJyR5eCYENvoTC Z1yC5n2uTRxCuFsJU5v0SIqgFAcwyh0L6/kNzpgqByDCGMNYaQ3BniSYCJbr zEJSgI7Q6jtmhM3Taj93TQILM2Zwj94KbSgwUjI72MDOYFvYeaDknRQUBQfi /GeOMJAbgwLSDONDgIVA4LStsoRXzUkeYCRl87SYcPrciVyHhYYVyFJ69MtU QnNmyDCGQMhg1llMWUsyJoaQzhnDKHJ0yTJSynlS6yAUWVrEJICADQplbmRz dHJlYW0NCmVuZG9iag0KMyAwIG9iag0KPDwNCi9Qcm9jU2V0IFsvUERGIC9U ZXh0IF0NCi9Gb250IDw8DQovRjEgNCAwIFINCj4+DQovRXh0R1N0YXRlIDw8 DQovR1MxIDUgMCBSDQo+Pg0KPj4NCmVuZG9iag0KNyAwIG9iag0KPDwNCi9U eXBlIC9IYWxmdG9uZQ0KL0hhbGZ0b25lVHlwZSAxDQovSGFsZnRvbmVOYW1l IChEZWZhdWx0KQ0KL0ZyZXF1ZW5jeSA2MA0KL0FuZ2xlIDQ1DQovU3BvdEZ1 bmN0aW9uIC9Sb3VuZA0KPj4NCmVuZG9iag0KNSAwIG9iag0KPDwNCi9UeXBl IC9FeHRHU3RhdGUNCi9TQSBmYWxzZQ0KL09QIGZhbHNlDQovSFQgL0RlZmF1 bHQNCj4+DQplbmRvYmoNCjQgMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1 YnR5cGUgL1R5cGUxDQovTmFtZSAvRjENCi9CYXNlRm9udCAvSGVsdmV0aWNh DQo+Pg0KZW5kb2JqDQoxIDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJl bnQgNiAwIFINCi9SZXNvdXJjZXMgMyAwIFINCi9Db250ZW50cyAyIDAgUg0K Pj4NCmVuZG9iag0KNiAwIG9iag0KPDwNCi9UeXBlIC9QYWdlcw0KL0tpZHMg WzEgMCBSXQ0KL0NvdW50IDENCi9NZWRpYUJveCBbMCAwIDU5NSA4NDJdDQo+ Pg0KZW5kb2JqDQo4IDAgb2JqDQo8PA0KL1R5cGUgL0NhdGFsb2cNCi9QYWdl cyA2IDAgUg0KPj4NCmVuZG9iag0KOSAwIG9iag0KPDwNCi9DcmVhdGlvbkRh dGUgKEQ6MTk5OTAyMDkxMTU5NTYpDQovUHJvZHVjZXIgKFwzNzZcMzc3XDAw MEFcMDAwY1wwMDByXDAwMG9cMDAwYlwwMDBhXDAwMHRcMDAwIFwwMDBEXDAw MGlcMDAwc1wwMDB0XDAwMGlcMDAwbFwwMDBsXDAwMGVcMDAwclwwMDAgXDAw MDNcMDAwLlwwMDAwXDAwMDFcMDAwIFwwMDBmXDAwMG9cMDAwclwwMDAgXDAw MFdcMDAwaVwwMDBuXDAwMGRcMDAwb1wwMDB3XDAwMHMpDQovQ3JlYXRvciAo V2luZG93cyBOVCA0LjApDQovVGl0bGUgKFJvc2UgRGlhZ3JhbVwoc1wpKQ0K Pj4NCmVuZG9iag0KeHJlZg0KMCAxMA0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAxNjc5IDAwMDAwIG4NCjAwMDAwMDAwMTcgMDAwMDAgbg0KMDAwMDAw MTI3NSAwMDAwMCBuDQowMDAwMDAxNTkxIDAwMDAwIG4NCjAwMDAwMDE1MTIg MDAwMDAgbg0KMDAwMDAwMTc2NyAwMDAwMCBuDQowMDAwMDAxMzgwIDAwMDAw IG4NCjAwMDAwMDE4NTYgMDAwMDAgbg0KMDAwMDAwMTkxMSAwMDAwMCBuDQp0 cmFpbGVyDQo8PA0KL1NpemUgMTANCi9Sb290IDggMCBSDQovSW5mbyA5IDAg Ug0KL0lEIFs8OGE3MjcwZTI5Y2ZkNzJkYWJlNWRlMDNkZmNkNmM2MTI+PDhh NzI3MGUyOWNmZDcyZGFiZTVkZTAzZGZjZDZjNjEyPl0NCj4+DQpzdGFydHhy ZWYNCjIyMTcNCiUlRU9GDQo= --0-1789315892-918563186=:5379-- From reichold@al1.physics.ox.ac.uk Tue Feb 9 12:50:28 1999 +0000 Date: Tue, 9 Feb 1999 12:50:28 +0000 (GMT) From: "Armin Reichold (LHC)" To: jbk@fnal.gov, kennedy@fnal.gov, "ELIZABETH S. SEXTON KENNEDY" , "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Mat Martin , t.hessing1@physics.ox.ac.uk, Todd Huffman , "David S. Waters" , Christopher Henry Green , Kevin McFarland , Alfred Lee , snider@al1.physics.ox.ac.uk, Joseph Boudreau Subject: Use of cloneable's a'la Lee in L3 trigger code containers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 28 Dear experts, I would like to consult all of you concerning your opinion on a decision that we (Oxford and the L3 tracking people) have to make very soon. It is about the RRL3 (Results and Regions (Banks) for Level 3 triggers, see http://b0urpc01.fnal.gov/~ksmcf/Results_and_Regions.ps for details. I have little experience in design questions and would like to get an overview of what limitations or problems, advatages and blessing our proposed design choice would inflict on us. The problem I would like to ask you about is the following: For each L3 trigger region (this is a simplification) RRL3 will store and administer many different objects such as the region itself, the triggers that requested them, the silicon clusters, any tracks found, L2 objects (calo clusters or muon stubs etc.). The class of these objects, how many of them and in which mixture is not per se predictable and will vary from trigger to trigger and from event to event. The container that is supposed to hold all of them thus has the difficult task of conaining apples, pears, cows and cars which is not easy for a container. We hope to solve this problem by making all of the classes that we would like to store derive from a possibly modified version of Al Lees' cloneable class (see TrackingUtils/GenericC++Examples/clonable and vectorc directories with good readme files for details) which would allow the container (a vectorc = vector of cloneables) to do what we wish (or at least we think so). However, a lot of classes would have to derive from cloneable and thus this choice may affect more people then just the L3 crowd. We need your opinions in such a decision before we can seek agreement for our proposal and make it part of the official code. We would be very gratefull if you could help us a little by commenting on this. Maybe you could cc your answers to all recipients of this mail as to encourage a little bit of discussion. Cheers Armin ************************************************* * Dr. Armin Reichold | private: * * Research Officer | 17 Frys Hill * * University of Oxford | Oxford * * Particle & Nuclear Phys. Lab. | OX4 5GW * * 1 Keble Road | UK * * Oxford OX1 3RH * * UK * * Room 612 * * * * Tel.: +44-(0)1865-273358...(office) * * Tel.: +44-(0)1865-434856...(private) * * Fax.: +44-(0)1865-273418...(office) * * E-Mail: a.reichold1@physics.ox.ac.uk * ************************************************* From reichold@al1.physics.ox.ac.uk Tue Feb 9 13:39:01 1999 +0000 Date: Tue, 9 Feb 1999 13:39:01 +0000 (GMT) From: "Armin Reichold (LHC)" To: Frederick Snider Subject: Use of cloneable's a'la Lee in L3 trigger code containers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 29 ---------- Forwarded message ---------- Date: Tue, 9 Feb 1999 12:50:28 +0000 (GMT) From: "Armin Reichold (LHC)" To: jbk@fnal.gov, kennedy@fnal.gov, ELIZABETH S. SEXTON KENNEDY , "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Mat Martin , t.hessing1@physics.ox.ac.uk, Todd Huffman , David S. Waters , Christopher Henry Green , Kevin McFarland , Alfred Lee , snider@al1.physics.ox.ac.uk, Joseph Boudreau Subject: Use of cloneable's a'la Lee in L3 trigger code containers Dear experts, I would like to consult all of you concerning your opinion on a decision that we (Oxford and the L3 tracking people) have to make very soon. It is about the RRL3 (Results and Regions (Banks) for Level 3 triggers, see http://b0urpc01.fnal.gov/~ksmcf/Results_and_Regions.ps for details. I have little experience in design questions and would like to get an overview of what limitations or problems, advatages and blessing our proposed design choice would inflict on us. The problem I would like to ask you about is the following: For each L3 trigger region (this is a simplification) RRL3 will store and administer many different objects such as the region itself, the triggers that requested them, the silicon clusters, any tracks found, L2 objects (calo clusters or muon stubs etc.). The class of these objects, how many of them and in which mixture is not per se predictable and will vary from trigger to trigger and from event to event. The container that is supposed to hold all of them thus has the difficult task of conaining apples, pears, cows and cars which is not easy for a container. We hope to solve this problem by making all of the classes that we would like to store derive from a possibly modified version of Al Lees' cloneable class (see TrackingUtils/GenericC++Examples/clonable and vectorc directories with good readme files for details) which would allow the container (a vectorc = vector of cloneables) to do what we wish (or at least we think so). However, a lot of classes would have to derive from cloneable and thus this choice may affect more people then just the L3 crowd. We need your opinions in such a decision before we can seek agreement for our proposal and make it part of the official code. We would be very gratefull if you could help us a little by commenting on this. Maybe you could cc your answers to all recipients of this mail as to encourage a little bit of discussion. Cheers Armin ************************************************* * Dr. Armin Reichold | private: * * Research Officer | 17 Frys Hill * * University of Oxford | Oxford * * Particle & Nuclear Phys. Lab. | OX4 5GW * * 1 Keble Road | UK * * Oxford OX1 3RH * * UK * * Room 612 * * * * Tel.: +44-(0)1865-273358...(office) * * Tel.: +44-(0)1865-434856...(private) * * Fax.: +44-(0)1865-273418...(office) * * E-Mail: a.reichold1@physics.ox.ac.uk * ************************************************* From reichold@al1.physics.ox.ac.uk Wed Feb 10 08:36:01 1999 +0000 Date: Wed, 10 Feb 1999 08:36:00 +0000 (GMT) From: "Armin Reichold (LHC)" To: Liz Sexton-Kennedy cc: "David S. Waters" , "\"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Todd Huffman Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers In-Reply-To: <199902091737.LAA11462@b0nd18.fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 30 Hi Liz, thanks for your quick reply. Since you would rather not discuss this via e-mail I'll only send this last one to you and don't cc it to the others. I'll try to video link to the next EDM meeting or if that is bed-time my side of the Atlantic I'll try to convince David Waters to attend. Can you remind me when and where they are? Please allow me just these few clarifications > > For each L3 trigger region (this is a simplification) RRL3 will store > > and administer many different objects such as the region itself, the > > triggers that requested them, the silicon clusters, any tracks found, L2 > > objects (calo clusters or muon stubs etc.). > > All of these objects sound to me like EVENT! objects, I don't think > RRL3 should be admistering it. Banks are supposed to be some of the dumbest > objects in the system not the smartest. This is just one of the problems > I have with the proposal you all outlined in your CDF note. You are right that they all are event, and they are dumb banks in your sense of bank and they will be stored in the same way that all event lifetime things will be stored like (persistable?, storable?) RRL3 is realy not a bank in the sense that it actually stores things. It stores relations to things (I ought have made that more clear in the note) So I see it as an organiser for L3 trigger path results. With the two main purposes of a) providing the relation between L3-tracking regions and their results b) enabling trigger paths to reuse work that has been done identically before by other paths Please let me or some of our group currently at FNAL know what the other problems you see with the proposal are. We have not felt any objections against the proposal yet and I am allready in the middle of designing the thing, so please comment soon/ > Yes of course this is the classic heterogenious collection class > problem and in order to solve it you have to involve everyone writing > reconstruction software. The right place for these discussions is at the > EDM meetings. I do not think it will be possible to discuss this via e-mail. sorry to not have spotted a classical problem, as I said we all have very limited experience in OO-design and thus still think we found something great and new now and then. Cheers Armin From reichold@al1.physics.ox.ac.uk Wed Feb 10 09:23:18 1999 +0000 Date: Wed, 10 Feb 1999 09:23:17 +0000 (GMT) From: "Armin Reichold (LHC)" To: Marjorie Shapiro cc: Liz Sexton-Kennedy , "Armin Reichold (LHC)" , jbk@fnal.gov, kennedy@fnal.gov, shapiro@cdfsga.fnal.gov, "ELIZABETH S. SEXTON KENNEDY" , "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Mat Martin , t.hessing1@physics.ox.ac.uk, Todd Huffman , "David S. Waters" , Christopher Henry Green , Kevin McFarland , Alfred Lee , snider@al1.physics.ox.ac.uk, Joseph Boudreau , rs@fnal.gov Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 31 Dear Marjorie, I am glad that both Liz and you have responded quickly to my mail. Thanks! Let me try and clarify some - as I see them - misunderstandings about RRL3. On Tue, 9 Feb 1999, Marjorie Shapiro wrote: > 1) The RRL3 bank seems to be serving several different purposesat once: > a) Control of Level 3 flow > b) Specification of parameters needed by algorithms > c) Storage of processing history on a) In the sense of AC++ RRL3 does not control the flow of the execution of modules in the various trigger paths of L3. Every module will still run in every path. The task of a modul is somehow different though. In our proposal every module allways loops over all "regions" it is supposed to process. If it finds that region has allready been processed by itself, the loop iteration will simply ignore it. So we are controlling intra module execution not inter module flow which as I understand is not part of AC++. Is that correct? on b) RRL3 must not specify parameters needed by algorithms! If I am thinking of the point you are addressing then RRL3 only writes down the prameters with which a certain region has been processed such as to allow its processing status to be determined accurately. Remember that this is only done if it can not be avoided at all, i.e. if different trigger were to be allowed to demand say clustering with different parameters (which I would object to) then this parameter would be stored with the results obtained. on c) This is its main task really. and it does not even store the processing results realy. It only groups them by region though storing "links" to them. The results themselves are all supposed to be stored as ordinary dumb banks. > It seems to me it would be a real advantage to separate these functions > rather than lumping them together. Moreover, some of these functions > can probably be more appropriately addressed in a more general context > (see items 2-4 below) RRL3 is a combined name for several classes indeed. Thus the functionality is allready ment to be split. The class stucture behind it is however not yet worked out. > 2) One of the main purposes of AC++ is to provide flow control for the > modules. I haven't yet understood why this control is not adequate for > Level 3. But if there is a problem, I would rather augment AC++ than > introduce a Level-3 specific mechanism for flow control. What > deficiencies in AC++ are you trying to solve with the RRL3 bank and its > associated infrastructure? As I tried to say in the beginning, RRL3 is not trying to control flow on the module level but on the "loop over regions in the module"-level. This may sound a bit pedantic but it may indicate the this loop should be moved out of the modules into AC++ in which case a, say clusering module would run in a AC++ controlled loop over all regions and thus AC++ would be in control. > > 3) One of the most important features the physics groups have demanded is > that we be able to keep track of and reproduce exactly the processing done > in Level 3 and production. This means we cannot allow any hysteresis to > creep into the system. I believe this means we cannot allow modules to > overwrite numbers in banks that were created by earlier modules. I > therefore have a real problem with the clearing of status words in RRL3 > every path. The clearing of status words in this case I think does not present the potential for histeresis. It is the "deactivation" of all entries in the beginning of each trigger path. This actually makes sure that there is no hysteresis in the system. Every path starts from scratch in the sense that it will only "activate" those regions that are of interest for this trigger and then only ever look into those regions during reconstruction. I must admit that the sentecte on page 7 of the RRL3 note that describes this not only has a typo in it but is also very confusing. So in summary the resetting of this status bit is there to avoid hysteresis. The other "status" parts are all dealing with the sotrage of processing hitory > Wouldn't it make more sense for each path to create its own RRL3? I don't think it would. The nature of RRL3 is, to say it once more, not that of bank. It is a register that orders banks. The main point of this register is that is provides a pool for everyone to announce results for a certain region and to be able to tell everyone whether a certain result is allready available or rather whether a certain request has allready been fullfilled. > > 4) Since Level 3 many need to use any reconstruction object, Level 3 > really cannot require that the objects it uses be derived from a Level 3 > specific base class. It seems to me that what you really are asking for > is that the EDM provide a general collection class that allows you to make > lists (or vectors) of persistable objects and tag them by a unique key > (for example the trigger name or the path name or the module instance). > I believe this is a reasonable request to make to Rob K. We need this > functionality in many, many places in the system. I could not agree more with this. You have correctly summarised what an RRL3_Entry is supposed to do. It has an Identifier and a Container. I only suggested "our own" aproach because I was not aware that this may be something that would be popular outside L3-regional tracking. We "want" it very urgently though, so this was driving us maybe a bit more than the others. > > We really should setup a meeting (with video) to discuss these questions > as part of the EDM group. I'll ask Rob Kennedy to contact Armin about > scheduling this. I am happy to hear this. Cheers Armin From reichold@al1.physics.ox.ac.uk Wed Feb 10 09:31:12 1999 +0000 Date: Wed, 10 Feb 1999 09:31:11 +0000 (GMT) From: "Armin Reichold (LHC)" To: Frederick Snider Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 32 Dear Marjorie, I am glad that both Liz and you have responded quickly to my mail. Thanks! Let me try and clarify some - as I see them - misunderstandings about RRL3. On Tue, 9 Feb 1999, Marjorie Shapiro wrote: > 1) The RRL3 bank seems to be serving several different purposesat once: > a) Control of Level 3 flow > b) Specification of parameters needed by algorithms > c) Storage of processing history on a) In the sense of AC++ RRL3 does not control the flow of the execution of modules in the various trigger paths of L3. Every module will still run in every path. The task of a modul is somehow different though. In our proposal every module allways loops over all "regions" it is supposed to process. If it finds that region has allready been processed by itself, the loop iteration will simply ignore it. So we are controlling intra module execution not inter module flow which as I understand is not part of AC++. Is that correct? on b) RRL3 must not specify parameters needed by algorithms! If I am thinking of the point you are addressing then RRL3 only writes down the prameters with which a certain region has been processed such as to allow its processing status to be determined accurately. Remember that this is only done if it can not be avoided at all, i.e. if different trigger were to be allowed to demand say clustering with different parameters (which I would object to) then this parameter would be stored with the results obtained. on c) This is its main task really. and it does not even store the processing results realy. It only groups them by region though storing "links" to them. The results themselves are all supposed to be stored as ordinary dumb banks. > It seems to me it would be a real advantage to separate these functions > rather than lumping them together. Moreover, some of these functions > can probably be more appropriately addressed in a more general context > (see items 2-4 below) RRL3 is a combined name for several classes indeed. Thus the functionality is allready ment to be split. The class stucture behind it is however not yet worked out. > 2) One of the main purposes of AC++ is to provide flow control for the > modules. I haven't yet understood why this control is not adequate for > Level 3. But if there is a problem, I would rather augment AC++ than > introduce a Level-3 specific mechanism for flow control. What > deficiencies in AC++ are you trying to solve with the RRL3 bank and its > associated infrastructure? As I tried to say in the beginning, RRL3 is not trying to control flow on the module level but on the "loop over regions in the module"-level. This may sound a bit pedantic but it may indicate the this loop should be moved out of the modules into AC++ in which case a, say clusering module would run in a AC++ controlled loop over all regions and thus AC++ would be in control. > > 3) One of the most important features the physics groups have demanded is > that we be able to keep track of and reproduce exactly the processing done > in Level 3 and production. This means we cannot allow any hysteresis to > creep into the system. I believe this means we cannot allow modules to > overwrite numbers in banks that were created by earlier modules. I > therefore have a real problem with the clearing of status words in RRL3 > every path. The clearing of status words in this case I think does not present the potential for histeresis. It is the "deactivation" of all entries in the beginning of each trigger path. This actually makes sure that there is no hysteresis in the system. Every path starts from scratch in the sense that it will only "activate" those regions that are of interest for this trigger and then only ever look into those regions during reconstruction. I must admit that the sentecte on page 7 of the RRL3 note that describes this not only has a typo in it but is also very confusing. So in summary the resetting of this status bit is there to avoid hysteresis. The other "status" parts are all dealing with the sotrage of processing hitory > Wouldn't it make more sense for each path to create its own RRL3? I don't think it would. The nature of RRL3 is, to say it once more, not that of bank. It is a register that orders banks. The main point of this register is that is provides a pool for everyone to announce results for a certain region and to be able to tell everyone whether a certain result is allready available or rather whether a certain request has allready been fullfilled. > > 4) Since Level 3 many need to use any reconstruction object, Level 3 > really cannot require that the objects it uses be derived from a Level 3 > specific base class. It seems to me that what you really are asking for > is that the EDM provide a general collection class that allows you to make > lists (or vectors) of persistable objects and tag them by a unique key > (for example the trigger name or the path name or the module instance). > I believe this is a reasonable request to make to Rob K. We need this > functionality in many, many places in the system. I could not agree more with this. You have correctly summarised what an RRL3_Entry is supposed to do. It has an Identifier and a Container. I only suggested "our own" aproach because I was not aware that this may be something that would be popular outside L3-regional tracking. We "want" it very urgently though, so this was driving us maybe a bit more than the others. > > We really should setup a meeting (with video) to discuss these questions > as part of the EDM group. I'll ask Rob Kennedy to contact Armin about > scheduling this. I am happy to hear this. Cheers Armin From reichold@al1.physics.ox.ac.uk Wed Feb 10 11:33:11 1999 +0000 Date: Wed, 10 Feb 1999 11:33:11 +0000 (GMT) From: "Armin Reichold (LHC)" To: Mat Martin Subject: Re: Lee's clonable class (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 33 ---------- Forwarded message ---------- Date: Fri, 5 Feb 1999 16:02:04 -0500 (EST) From: Alfred Lee To: "Armin Reichold (LHC)" Cc: "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Mat Martin , t.hessing1@physics.ox.ac.uk, Todd Huffman , David S. Waters , Christopher Henry Green , Kirsten Tollefson , Kevin McFarland Subject: Re: Lee's clonable class Dear Armin, The clonable (and related VectorC vector of clonables - class) live in the TrackingUtils/GenericC++Examples/clonable and vectorc directories. The purpose of these classes are simple: provide a generic interface which allows copy construction of of a class that is otherwise specified only by an abstract interface. The VectorC class allows the same copy semantics as the STL vector class (copies are added to the vector, not pointers to objects whose memory is controlled elsewhere), for classes that obey the clonable interface (they don't actually have to inherit from it to work). This allows sets of different objects that obey that inherit from the same clonable interface to be stored in the the VectorC list. I don't believe either of these classes is used anywhere in the code directly. The interface does lack a "downcasting" function, e.g., whoAreYou() that returns a string with the name of the concrete class behind the interface may be useful. This is easily added, however, it probably isn't needed. If RTTI is enabled (which I think is the CDF default), then one can just attempt safe dynamic casting of an object in a set to see if it is the type you need, rather than getting a string and then deciding to cast based on that. As I mention in the comments, there is nothing magical about the clone class; it is a fairly straight forward implementation of the general idea of "virtual constructors" as is described in Stroustrup (15.6.2 of 3rd edition of "The C++ Language"). It may well be a good idiom for the collection class you want. If you look at mytest.cc in the vectorc directory, you may get some idea how it could work. All that is missing from the example is a line like Asub * pHeresOne = dynamic_cast(&supervector[1]) if (!pHeresOne) { cout << "Dynamic cast to Asub failed" << endl; } to show how dynamic_casting would work (dynamic_cast returns 0 if the cast fails). I hope this helps. Cheers, Al On Fri, 5 Feb 1999, Armin Reichold (LHC) wrote: > Hi Al, > I hope you still have a little bit of time left to look at a C++ problem > these days, if not - don't worry - just let me know and ignore the > following. > I have, by accident bumped into your clonable class in the example area. > It seems rather old (from g++ days) and I wonder whether you have given up > on this completely or if it is currently used in CDF code anywhere. > > We, oxford L3 group, may have an application for this but I am not realy > sure that I understand what this realy does. So may I try to tell you what > problem I had in mind for the application and you could tell me if your > clonable would be good basis for solving it? > > We are about to design a class which is supposed to collect and organise > the results obtained during regional tracking for L3. This will require > storing references to a lot of different classes which all can form parts > of the reconstruction chain (clusters, COT tracks, calo-showers, > track-sets, etc.) and we would like to avoid having to hardwire all > combinations of these objects that should be stored togehter. We would > much rather like to have a very lightweight base class that that all these > objects could inherit from and thus we store them by their base class > types. However, since they are very different beasts we would need to be > able to turn them into what they realy are when we manipulate the data > they contain. Or at least they should tell us what they realy are so we > can cast them or copy them or god nows what. Your cloneable classes seem > to provide a lot of this functionality (if I undertand them correctly) > > Could you advise us a little bit on that? > > Cheers Armin > > ************************************************* > * Dr. Armin Reichold | private: * > * Research Officer | 17 Frys Hill * > * University of Oxford | Oxford * > * Particle & Nuclear Phys. Lab. | OX4 5GW * > * 1 Keble Road | UK * > * Oxford OX1 3RH * > * UK * > * Room 612 * > * * > * Tel.: +44-(0)1865-273358...(office) * > * Tel.: +44-(0)1865-434856...(private) * > * Fax.: +44-(0)1865-273418...(office) * > * E-Mail: a.reichold1@physics.ox.ac.uk * > ************************************************* > > From reichold@al1.physics.ox.ac.uk Thu Feb 11 12:45:46 1999 +0000 Date: Thu, 11 Feb 1999 12:45:46 +0000 (GMT) From: "Armin Reichold (LHC)" To: Jim Kowalkowski cc: "Armin Reichold (LHC)" , Marjorie Shapiro , Liz Sexton-Kennedy , kennedy@fnal.gov, shapiro@cdfsga.fnal.gov, "ELIZABETH S. SEXTON KENNEDY" , "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Mat Martin , t.hessing1@physics.ox.ac.uk, Todd Huffman , "David S. Waters" , Christopher Henry Green , Kevin McFarland , Alfred Lee , Joseph Boudreau , Frederick Snider Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers In-Reply-To: <36C1ABF0.DA3FF1AA@fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 34 Dear Jim, thank you very much for your interest in this subject and please excuse my late answere. I was teaching optics and quantum mechanics all day yesterday. I will try and answere your questions below. > Armin Reichold (LHC) wrote: > > on a) > > In the sense of AC++ RRL3 does not control the flow of the execution of > > modules in the various trigger paths of L3. Every module will still run in > > every path. The task of a modul is somehow different though. In our > > proposal every module allways loops over all "regions" it is supposed to > > process. If it finds that region has allready been processed by itself, > > the loop iteration will simply ignore it. So we are controlling intra > > module execution not inter module flow which as I understand is not part > > of AC++. Is that correct? > > I'm still trying to get a handle on the problem. Does this mean that > paths contains large AC++ modules, such that if I peek inside > one, I see a bunch on sub-modules (not AC++ ones, but similar > concept)? If so, then does the large AC++ module coordinate the > flow of event data to the sub-modules based on information inside > the RRL3 object? I'll try and explain this with an example. A bulk standard AC++ clustering module for the silicon detector data will, when asked to run first, eat the SIXD and ISLD banks and spit out a cluster data. If after that, it is asked to run again in the same event, it just won't, because the framework provides a hook that stops identical modules from beeing run twice if that is desired. The event data (the ISLD and SIXD banks) needed for this module are not controlled by anything, they just come in during creation of the event. (I hope I understood this corretly) A regional clusterig module is different to the above. Allthough it acts on the same event data (ISLD and SIXD) it will only process fractions of them. These fractions are specified by regions which have been created specifically for one trigger path (many paths may create the same regions though) and are given to the clustering module by RRL3 in the form of a list iterator. This iterator is another piece of event information needed by the clustering module. On top of that there is a history of which regions have allready been processed during the event. RRL3 uses this history to make the iterator mask the list of regions for the module so that only unprocessed ones will be actually iterated over. As far as we can see now, all trigger paths are going to have identical (in the AC++ sense they are the same instantiation of a module) regional clustering modules. We want to avoid parameters for the clustering code. However we still want to run them every time they are called in every path. So if you wish you do see a "bunch of IDENTICAL" submodules in the "big" regional clustering modules in the form of iteration steps and repeated clustering inside the resultant regions. > > > As I tried to say in the beginning, RRL3 is not trying to control flow on > > the module level but on the "loop over regions in the module"-level. This > > may sound a bit pedantic but it may indicate the this loop should be moved > > out of the modules into AC++ in which case a, say clusering module would > > run in a AC++ controlled loop over all regions and thus AC++ would be in > > control. > > Are you indicating that you would like the > "loop over regions in the module"-level submodules to become full AC++ > modules? I only mentioned this alternative because Marjorie may have good reasons for wanting this kind of control inside AC++. Personally I think that a loop over L3 trigger regions would be too specific to become a mechanism of AC++. I would not like the "loop over regions in the module"-level submodules to become full AC++ modules as there is now way of telling beforehand how many of them we would have per path and what regions they have. > > > > Wouldn't it make more sense for each path to create its own RRL3? > > I don't think it would. The nature of RRL3 is, to say it once more, not > > that of bank. It is a register that orders banks. The main point of this > > register is that is provides a pool for everyone to announce results for a > > certain region and to be able to tell everyone whether a certain result is > > allready available or rather whether a certain request has allready been > > fullfilled. > > This sounds a lot like issues that the EDM group is dealing with increating > transient objects that can be stored in the AC++ event > object. The RRL3 object, in the context you describe above, > appears to me to be supporting state machine concepts that > are relevant to level 3. I guess I think of AC++ as a sort-of > data flow architecture (the event flows through a series of > modules in the simplest case). Level 3 seems more like a > real state machine, and most state machines really need support > for a global scoreboard/register/status objects. This is all > based on my limited knowledge of the system. I hope I'm > not rambling too much here needlessly. In a way you are right, Level-3-regional-silicon-tracking is a state machine but: - it is only a very small part of Level-3, though an important one. - it is only a state machine with respect to the processing of regions. If all regional tracking modules in a gievn trigger path had and outside loop over regions around all of them, then - inside the loop - things would look like a data flow architecture. So there is only this tiny little pertubation of the state controlled region loop which brakes the data folow architecture paradigm. We think we can accomodate this via RRL3 and as far as RRL3 is concerned we can keep that nicely separated from the rest of the offline with the one possible exception of the heterogeneous container. > > > > > > > 4) Since Level 3 many need to use any reconstruction object, Level 3 > > > really cannot require that the objects it uses be derived from a Level 3 > > > specific base class. It seems to me that what you really are asking for > > > is that the EDM provide a general collection class that allows you to make > > > lists (or vectors) of persistable objects and tag them by a unique key > > > (for example the trigger name or the path name or the module instance). > > > I believe this is a reasonable request to make to Rob K. We need this > > > functionality in many, many places in the system. > > I could not agree more with this. You have correctly summarised what an > > RRL3_Entry is supposed to do. It has an Identifier and a Container. I only > > suggested "our own" aproach because I was not aware that this may be > > something that would be popular outside L3-regional tracking. We "want" it > > very urgently though, so this was driving us maybe a bit more than the > > others. > > It seems to me that organization of the keys, the container, and thesearch > methods are very important here if high performance is crucial. > Especially if level 3 modules are going to bang on this general > collection object a lot.Jim I agree, the logical makeup of the key is simple. It is just the ID of the type of region combined with the ID of object that seeded the region. How to translate this into an efficient key, I don't know yet. I know very little about the efficiency problems involved with this and I would be very happy if you could keep an open ear for my questions and advise us on efficiency problems. cheers Armin From reichold@al1.physics.ox.ac.uk Thu Feb 11 15:19:59 1999 +0000 Date: Thu, 11 Feb 1999 15:19:58 +0000 (GMT) From: "Armin Reichold (LHC)" To: Jim Kowalkowski cc: "Armin Reichold (LHC)" , kennedy@fnal.gov, "ELIZABETH S. SEXTON KENNEDY" , "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Mat Martin , t.hessing1@physics.ox.ac.uk, Todd Huffman , "David S. Waters" , Christopher Henry Green , Kevin McFarland , Alfred Lee , snider@al1.physics.ox.ac.uk, Joseph Boudreau Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers In-Reply-To: <36C1BBE7.5F848B33@fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 35 Hi Jim, here are a few more questions about heterogeneous container problems you mentioned > Just a few notes on technical issues concerning heterogeneous containers. > If you get bored reading it before you reach (5), then skip to (5) and > look at it briefly. > > As Al Lee's example shows, it is very easy to create container of > dissimilar objects by using a base class where all things are derived from > and stored in something like this: > vector hetero_container; > > There is a couple of problems associated with this: > > ------------------- > 1) As you said, everyone must have this base class visable and > present in their code - this is understood well enough. I hope it is, how bad a problem is this really. We would -in the worst case- simply create Level3 versions of the classes we needed which did nothing more but: class L3_CDF_TrackSet public: CDF_TrackSet, clonable } } we only need to do this for a few classes that we want to group inside RRL3. > 2) In the simplest case, one would fill the container with three > different things like this assuming the Cow, Pig, Horse are all > derived from BasicObject): > > hetero_container.push_back(new Cow); > hetero_container.push_back(new Pig); > hetero_container.push_back(new Horse); > > When is time to clean up the container, the owner of it must loop > through all the stuff inside it and do a "delete" on each item. > > vector::iterator iter = hetero_container.begin() > while(iter!=hetero_container.end()) delete *iter; > > If the heap is used in this fashion, there will be a performance > penalty. The heap is known not to be fast. Also, using the > heap in this fashion could cause memory fragmentation > leading to degradation in performance (presuming the process > runs for a long time). I was not aware of these performance problems at all. Is this a realy big drawback? We are currently relying a lot on pointers to heap stored in stl containers for look up tables to navigate with regions in the detector. They are singletons and live forever, thus fragmentation is probably not a problem, but what about the performance and why is the heap slow (for a laymen please) > We can fix this situation by using object instance pools, where > we manage freelists of commonly used objects such as Cows, > Pigs, and Horses. Now the code becomes (assuming a simple > templated solution to the pool problem): > > hetero_container.push_back(Factory::make()); > hetero_container.push_back(Factory::make()); > hetero_container.push_back(Factory::make()); > > and the clean up becomes: > > vector::iterator iter = hetero_container.begin() > while(iter!=hetero_container.end()) FactoryAdmin::destroy(*iter); > > Factories can help out a lot in these cases. I prefer using factories over > cloning - if cloning would be used to create new instances of object > only. Factories can be set up in many ways - where a simple > call like > BasicObject* obj1 = Factory::make("COW"); > BasicObject* obj2 = Factory::make("PIG"); > > Notice that this code is not coupled at compile time to the > class Cow or Pig. Setting this up is a bit more difficult and > in the case above, does require a string look-up to create the > correct object. But this still assumes that COW and PIG both inherit from basic object? So if COWs where CDF_Tracks and PIGs were ClusterData then both of them would have to inherit from basic object, say RRL3able and basic object must provide a mytype() function which would allow us to find out if we actually got a Track or Cluster Data. In how far, other than the actuall object sitting on the stack since they are created in the factory without operator new, does this differ from the situation in which BasicObject is replaced with clonable? > > -------------------- > 3) From the messages and notes I've been reading, it seems > likely that access to the things in the vector will be through a > key - probably involving strings: > > map hetero_container; > > Now we introduced more potential performance problems. > > a) Is can be expensive to put an item into a map, remember that > it is a complex tree structure that maintains the relationships between > Keys and BasicObjects. > > b) Searching is good, but not great for applications that require > maximum performance and will be looking in here a lot. Seaching > requires a Key comparison, and if key is a string, then this is not > fast. I agree that a map, in particular with a string key, would be slow. We have had exactly this problem before with the region LUTs and went to a vector with a more or less dense uint key. We actually had to waste some space in the vector since we could not make the key completely dense, i.e. some keys we not used but the space was allready allocated. > > c) Cleanup of the map is expensive. I don't understand why? > > d) The pointers in the map are subject to the same problems as the > vector. You mean they are pointes to heap? > > How can performance be improved? Use factories/pools for > creating/destroying objects instead of the heap. Fix the location or > slot where a particular Key and associated object will be stored > at the beginning of the job. Add a method called "int getSlotID(Key)". > This method can be called by modules during job initialization and the > slot id recorded can be recorded. If the module needs to use or > access the object associated with the key, the slot_id can be used > instead. Of couse the slot_id would be implemented as a direct > index into an array of BasicObject pointers. This would be the > fastest way to get at the object. But how can I do this if I don;t know: a) what keys I am going to get in any event, since I can't predict all seed objects and region type combinations b) how many keys a module should reserve If I understand you correctly you want to anticipate all keys that I could ever have and then translate it into a slotID at the beginning of the run? A clustring module only gets its keys which describes what data to read or where to store its results, at the beginning of each event. I am confused here. How should I apply this? > > ----------------- > 4) Finding based on type of object. Many times users want to > find an object in the hetero_container above by type, such as > "give_me_the_first_object_of_type" > This is going to be slow and if this is part of the required access > pattern needed, then special things must be done if > performance is critical. I'll assume this is not important. I am afraid that this is important. Again an example: The track finding module will need cluster data on its input. it is going to loop through our hetero container and will do exactly what you fear, it will do a loop over all regional cluster banks like. for (RRL3::heteroContainer::Iterator ClusterIter, ClusterIter.isValid(), ++ClusterIter) This is actually the main access mode for read. Other modules would do the same thing just not with clusters but with tracks or with strip-ADC values etc. > 5) There is an alternative to using a Base class for all objects > stored in the container. Do this (by no means is this a complete > implementation): > > // support class > class AnyObject > { > AnyObject(); > ~virtual AnyObject(); > ... > } So this is just something with a virtual constructor typically gets made in a factory? It replaces the base class that in the old solution we would have to derive from? I'll try and annotate this to show what I do and what I don't understand about it. > > // support class - wrapper for object > template class SpecificObject : AnyObject > { > SpecificObject(T* d):obj(d) { } did you not mean: SpecificObject(T* d):_myd(d) { } > ... > static T* get(AnyObject x); > static void put(AnyObject x, T*); why are these static functions? And what are they needed for? > > T* _myd; so Specific object contains a pointer to T, > } > > // utility to extract stuff > template > int find(map& h, Key k, T*& d) > { > map::iterator iter = h.find(k); > if(iter==h.end()) return error message - not found > > if( (d=dynamic_cast(iter->second)) == 0) > { > // not the correct type, return an error! > } > else return success > } > // utility to put stuff in > template > int insert(map& h, Key k, T* d) > { > // check if key inside container already > h[k]=new SpecificObject(d); > } > > // ----------------------example user application---------------- > // collection of anything with key > map hetero_container; > > insert(hetero_container,"MYCOW",new Cow); > insert(hetero_container,"MYPIG",new Pig); > insert(hetero_container,"MYHORSE", new Horse); > > Cow* cow; > find(hetero_container,"MYCOW",cow); // pull out MYCOW > Pig* pig; > find(hetero_container,"MYPIG",pig); // pull out MYPIG > > Notice that the Cow, Pig, and Horse do not need to be > derived from anything. To be honest, I don't know how this works at all. Can I give you a phone call? Cheers Armin > > ------------------------- > > There are just a couple of items to keep in mind, you may be > using some of them already. It is all I can think of at the current > time. I'm not yet sure which, if any, > apply to the problems you are solving. > > Jim > > -- > Jim Kowalkowski - jbk@fnal.gov > D0: 630/840-2215 - 5th floor of the D0 assembly building > CDF: 630/840-6457 - 169F in the CDF trailers > http://www-cdf.fnal.gov/internal/people/links/JamesKowalkowski/my.html > http://www-d0.fnal.gov/~jbk/index.html > > > From reichold@al1.physics.ox.ac.uk Thu Feb 11 15:24:49 1999 +0000 Date: Thu, 11 Feb 1999 15:24:48 +0000 (GMT) From: "Armin Reichold (LHC)" To: Robert Kennedy cc: "Armin Reichold (LHC)" , Marjorie Shapiro , Liz Sexton-Kennedy , jbk@fnal.gov, kennedy@fnal.gov, "ELIZABETH S. SEXTON KENNEDY" , "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Mat Martin , t.hessing1@physics.ox.ac.uk, Todd Huffman , "David S. Waters" , Christopher Henry Green , Kevin McFarland , Alfred Lee , snider@al1.physics.ox.ac.uk, Joseph Boudreau , rs@fnal.gov Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers In-Reply-To: <199902101830.MAA13770@cdfsga.fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 36 Hi Rob, thanks for trying to organise the meeting. My constraints are: - Next tuesday morning (4 am your time) I fly to Geneva, returning effectively thursday morning. - Friday I am teaching troughout the overlap between your and my waking ours any other time is fine. cheers Armin ************************************************* * Dr. Armin Reichold | private: * * Research Officer | 17 Frys Hill * * University of Oxford | Oxford * * Particle & Nuclear Phys. Lab. | OX4 5GW * * 1 Keble Road | UK * * Oxford OX1 3RH * * UK * * Room 612 * * * * Tel.: +44-(0)1865-273358...(office) * * Tel.: +44-(0)1865-434856...(private) * * Fax.: +44-(0)1865-273418...(office) * * E-Mail: a.reichold1@physics.ox.ac.uk * ************************************************* On Wed, 10 Feb 1999, Robert Kennedy wrote: > > > We really should setup a meeting (with video) to discuss these questions > > > as part of the EDM group. I'll ask Rob Kennedy to contact Armin about > > > scheduling this. > > I am happy to hear this. > > Hello, > > It sounds like we should meet as soon as reasonably possible, no later than Tuesday. Monday is a holiday in US for many, so that's out. I know that we can get the B0 new meeting room with video Tuesday (worst case) at 9:30-10:30 and 11:30-12:30+, but will have to look into other days/times once we reach some consensus. > > I personally would like another day to go over again the RRL3 note and the subsequent e-mail to try to identify the Collection class support that would be desirable in this domain... and compare it to CDFTrackCollection specs. Is Thursday or Friday a good day for folks? Suggested time? > > Thanks, > Rob K. > > > From reichold@al1.physics.ox.ac.uk Thu Feb 11 15:51:21 1999 +0000 Date: Thu, 11 Feb 1999 15:51:21 +0000 (GMT) From: "Armin Reichold (LHC)" To: Robert Kennedy cc: "Armin Reichold (LHC)" , Marjorie Shapiro , jbk@fnal.gov, kennedy@fnal.gov, "ELIZABETH S. SEXTON KENNEDY" , "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Mat Martin , t.hessing1@physics.ox.ac.uk, Todd Huffman , "David S. Waters" , Christopher Henry Green , Kevin McFarland , Alfred Lee , Joseph Boudreau , rs@fnal.gov Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers In-Reply-To: <199902101906.NAA13267@cdfsga.fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 37 Dear Rob, also to you thanks for updating us on the status of the EDM w.r.t. our RRL3 problems. Here are my comments > > The clearing of status words in this case I think does not present the > > potential for histeresis. It is the "deactivation" of all entries in the > > beginning of each trigger path. This actually makes sure that there is no > > hysteresis in the system. Every path starts from scratch in the sense that > > it will only "activate" those regions that are of interest for this > > trigger and then only ever look into those regions during reconstruction. > > I must admit that the sentecte on page 7 of the RRL3 note that describes > > this not only has a typo in it but is also very confusing. > > So in summary the resetting of this status bit is there to avoid > > hysteresis. The other "status" parts are all dealing with the sotrage of > > processing hitory > Hello, The EDM proposal (and it is still just an icompletely written proposal "in committee") states that once any object is stored, the stored form of the object is read-only. I have two questions here: 1. Stored referes to the status of the object after a call to write persistent? 2. read-only last only until the next event when a new RRL3 is constructed? This would exclude the alternative of "resetting" RRL3 every event and we really have to create a new one. But only if RRL3 is seen as a bank which ends up beeing written. It may be that only a small fraction of RRL3 stored associations get written. This is one of a few policies to avoid the hysteresis we are concerned about. We have not done this in the past (YBOS banks were read-write scratchpads wherever they are), and will have some work to do in order to adapt existing code to this approach. Nevertheless, this is the simplest approach we have come up with that is enforceable at run-time to insure that the processing history of each object in the event is well-understood. D0's Event Data Model uses this approach too. I would be invaluable, for me at least, to see the grand concept RRL3 broken down into component parts which we understand can obey this policy. I think this is exactly our next job. We have to brake RRL3 down into its classes and associated banks and then show that we can comply to this policy. In some cases we have to rethink our objects to accomplish this, since the obvious transient object classes are not restricted by this read-only policy. Nevertheless this may help our discussions since we will be able to identify and separate the grand RRL3 abstraction and the storable representation... at least at the design concept level. So RRL3 will be first broken down into the part of it which needs to be stored in the event history and thus has to comply to the rules of read only after first write persistent. And the part which is the transient scratchpad organiser that should just be reset every event. A simple example is a circular list. The transient form is fine, but a direct translation of that to the storable form is impossible since the policy prevents circular link (persistent pointer) chains. The adaptation of the circular list is to store the list node data as objects and then store a list summary object which contains links to all the list nodes. Or just store the list in a storable STL vector of list nodes. Most of the actual data that will be arranged into RRL3 allready exists (or will very soon) in storable form. I.e. the TrackSets or ClusterData. Some don't yet have a bank representation like the regions themselves or the L3 trigger path identifiers. These will get one soon. The biggest problem will be the storable form of the "link", i.e. the information that a certain L3-trigger Id and a certain cluster data are associated or linked to a region and a seed. The transient form of this is the RRL3_Entry which has this heterogeneous container I keep hoping for. It stores pointers or references. The persistant version of it is not clear to me. Somehow I must be able to find a unique identifier for any object that was linked into an entry and made persistent. Also soted with the object is the ID of the module and its parameter set. I am not sure I undertand fully what you mean here. Do you say that if a module wants to write a bank it has to store a list of all its parameters with the bank? Yes, there is some overhead for translating the transient and storable formats ... formats of what? The bank or the module parameter list that is attached to the bank? ... (which can be minimized with some technology), but now there is no chance that another module will come along and "secretly" change a few numbers in the list. If you want to change a number in it, you have to make your own copy, store that copy with a different object ID (bank number) and module/parameter set ID. From discussions so far, we understand that the EDM will need to support a few collection classes !! so that others can re-use the transforms from/to transient collections to/from stored collections. Yes, a collection suitable of transiently holding all sorts of storable objects which, when made persitent itself, will not store the objects it contains but will store some form of the links to them. I must say that I feel very much that I am out of touch with the ideas and vocabulary behind the EDM. I realy need to attend some of your meetings to catch up and if I can't come maybe you can fill your knowledge into one of Oxford Group so I can be breast fed from them. Cheers Armin From reichold@al1.physics.ox.ac.uk Thu Feb 11 15:58:29 1999 +0000 Date: Thu, 11 Feb 1999 15:58:28 +0000 (GMT) From: "Armin Reichold (LHC)" To: Jim Kowalkowski Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers In-Reply-To: <36C2EEEC.CBC29C66@fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 38 Hi Jim, I tried to answere to your long e-mail. I was still quite confused about the example you gave with the anyObject and specificObject classes. I guess I need to discuss them with you on the phone some time. Unfortunately I don't seem to be able to get my head above water (work) in the last few days. I'll try and ring you when shore comes in sight. Cheers Armin ************************************************* * Dr. Armin Reichold | private: * * Research Officer | 17 Frys Hill * * University of Oxford | Oxford * * Particle & Nuclear Phys. Lab. | OX4 5GW * * 1 Keble Road | UK * * Oxford OX1 3RH * * UK * * Room 612 * * * * Tel.: +44-(0)1865-273358...(office) * * Tel.: +44-(0)1865-434856...(private) * * Fax.: +44-(0)1865-273418...(office) * * E-Mail: a.reichold1@physics.ox.ac.uk * ************************************************* On Thu, 11 Feb 1999, Jim Kowalkowski wrote: > Armin, > > Did you find my long email about containers useful? > Is this the sort of thing you were looking for? > Do you need further information? > > Jim > > Armin Reichold (LHC) wrote: > > > > It seems to me that organization of the keys, the container, and thesearch > > > methods are very important here if high performance is crucial. > > > Especially if level 3 modules are going to bang on this general > > > collection object a lot.Jim > > I agree, the logical makeup of the key is simple. It is just the ID of the > > type of region combined with the ID of object that seeded the region. How > > to translate this into an efficient key, I don't know yet. I know very > > little about the efficiency problems involved with this and I would be > > very happy if you could keep an open ear for my questions and advise us on > > efficiency problems. > > > > -- > Jim Kowalkowski - jbk@fnal.gov > D0: 630/840-2215 - 5th floor of the D0 assembly building > CDF: 630/840-6457 - 169F in the CDF trailers > http://www-cdf.fnal.gov/internal/people/links/JamesKowalkowski/my.html > http://www-d0.fnal.gov/~jbk/index.html > > > From reichold@al1.physics.ox.ac.uk Thu Feb 11 17:06:54 1999 +0000 Date: Thu, 11 Feb 1999 17:06:54 +0000 (GMT) From: "Armin Reichold (LHC)" To: Robert Kennedy cc: "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Todd Huffman , "David S. Waters" Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers In-Reply-To: <199902111636.KAA14916@cdfsga.fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 39 Hi Rob, your explanations helped a lot allready. Unfortunately I can not link up to the EDM meeting as I am at CERN on that day. I have asked the other group members currently at FNAL to come to the meeting. I know I may be asking a lot from a working group of experts but I would like to aks you to explain things SIMPLY and in laymen words on tuesday to whoever of us may be there. None of us is an expert on these design issues and none of us has a lot of experience with this kind of high level frameworky stuff, however we realy want to understand it (and by the looks of it we realy have to) - so please be patient. Cheers Armin ************************************************* * Dr. Armin Reichold | private: * * Research Officer | 17 Frys Hill * * University of Oxford | Oxford * * Particle & Nuclear Phys. Lab. | OX4 5GW * * 1 Keble Road | UK * * Oxford OX1 3RH * * UK * * Room 612 * * * * Tel.: +44-(0)1865-273358...(office) * * Tel.: +44-(0)1865-434856...(private) * * Fax.: +44-(0)1865-273418...(office) * * E-Mail: a.reichold1@physics.ox.ac.uk * ************************************************* From reichold@al1.physics.ox.ac.uk Thu Feb 11 18:25:27 1999 +0000 Date: Thu, 11 Feb 1999 18:25:27 +0000 (GMT) From: "Armin Reichold (LHC)" To: Mat Martin Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 40 ************************************************* * Dr. Armin Reichold | private: * * Research Officer | 17 Frys Hill * * University of Oxford | Oxford * * Particle & Nuclear Phys. Lab. | OX4 5GW * * 1 Keble Road | UK * * Oxford OX1 3RH * * UK * * Room 612 * * * * Tel.: +44-(0)1865-273358...(office) * * Tel.: +44-(0)1865-434856...(private) * * Fax.: +44-(0)1865-273418...(office) * * E-Mail: a.reichold1@physics.ox.ac.uk * ************************************************* ---------- Forwarded message ---------- Date: Thu, 11 Feb 1999 11:10:44 -0600 From: Jim Kowalkowski To: "Armin Reichold (LHC)" Cc: Alfred Lee , Rob kennedy Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers Armin, I'm only sending this to you. If you want to forward it, that is fine, I'm just not sure if everyone wants to hear this or not. Here are responses to your questions. This is a difficult subject to discuss in detail using email. I have running code that is in use that illustrates everything that I talk about. If fact, every performance critical application I've even done uses many of these techiques, esspecially management of object pools so the default new/delete memory manager does not get used once the program reaches a stable state. Jim Armin Reichold (LHC) wrote: > Hi Jim, > here are a few more questions about heterogeneous container problems you > mentioned > > > > As Al Lee's example shows, it is very easy to create container of > > dissimilar objects by using a base class where all things are derived from > > and stored in something like this: > > vector hetero_container; > > > > There is a couple of problems associated with this: > > > > ------------------- > > 1) As you said, everyone must have this base class visable and > > present in their code - this is understood well enough. > I hope it is, how bad a problem is this really. We would -in the worst > case- simply create Level3 versions of the classes we needed which did > nothing more but: > > class L3_CDF_TrackSet > public: CDF_TrackSet, clonable > } > } > > we only need to do this for a few classes that we want to group inside > RRL3. It's not that bad, it just causes coupling that many people might not like. > > If the heap is used in this fashion, there will be a performance > > penalty. The heap is known not to be fast. Also, using the > > heap in this fashion could cause memory fragmentation > > leading to degradation in performance (presuming the process > > runs for a long time). > I was not aware of these performance problems at all. Is this a realy big > drawback? We are currently relying a lot on pointers to heap stored in stl > containers for look up tables to navigate with regions in the detector. > They are singletons and live forever, thus fragmentation is probably not a > problem, but what about the performance and why is the heap slow (for a > laymen please) Using the heap is of essential and fine. The performance problems Iam speaking of occur when you continually make use of default new and delete in an application as it's running - for example, building up a large heterogeneous container using default new, and clearing it using default delete for each of the events processed. It's the calls to malloc/free within default new/delete that are expensive, not using the memory on the heap - it's aquiring the memory from the heap manager that is costly. Also, the heap manager is made to work for the general case, which means fragmentation should be a concern. > > call like > > BasicObject* obj1 = Factory::make("COW"); > > BasicObject* obj2 = Factory::make("PIG"); > > > > Notice that this code is not coupled at compile time to the > > class Cow or Pig. Setting this up is a bit more difficult and > > in the case above, does require a string look-up to create the > > correct object. > > But this still assumes that COW and PIG both inherit from basic object? In this example yes. In general, the factory or pool manager would returnan object of the specific type. > So if COWs where CDF_Tracks and PIGs were ClusterData then both of them > would have to inherit from basic object, say RRL3able and basic object > must provide a mytype() function which would allow us to find out if we > actually got a Track or Cluster Data. In how far, other than the actuall > object sitting on the stack since they are created in the factory without > operator new, does this differ from the situation in which BasicObject is > replced with clonable? Yes, in this method you would be required to register the name associatedwith the object in the factory so that it would know which thing it should create in a call to make().The difference is that the factory or pool manager creates and owns a poolof buffers that it uses to create new objects from - instead of going to the default heap manager. As objects are deleted by the user, they go back to a freelist held by the pool manager. Since all the buffers are the same size, it is very fast to get one off the free list for use in creating the requested instance. > > > > c) Cleanup of the map is expensive. > I don't understand why? Of course I am talking about the STL map here...The map I put in the example has pointers toobjects and instances of keys. To clean it up requires a call to default delete (the heap manager), running the destructors of the object (expensive because calls are through the virtual destructor mechanism, basically a pointer to a function), and the destructor of the key to be called (if it is not a primitive data type). This occurs for each item in the map. Not only that, but the map has a complex indexing hierarchy of pointers, nodes, and keys that must be dismantled piece by piece as the elements are removed during the cleanup process. The map is a complex data structure, it is made to give fast, predictable search times given an arbitrary key. This of course means it cannot possibly be optimal for a specific type of key or access pattern. A map is not just an indexed lookup, it is a tranversal of an index tree - I believe its perforance is O(nlogn) but I could be slightly off here. > > > > d) The pointers in the map are subject to the same problems as the > > vector. > You mean they are pointes to heap? Yes, but it's not the heap memory that is the problem, it's the callto default new/delete using the heap manager to aquire/return the memory to/from the heap. > > > > How can performance be improved? Use factories/pools for > > creating/destroying objects instead of the heap. Fix the location or > > slot where a particular Key and associated object will be stored > > at the beginning of the job. Add a method called "int getSlotID(Key)". > > This method can be called by modules during job initialization and the > > slot id recorded can be recorded. If the module needs to use or > > access the object associated with the key, the slot_id can be used > > instead. Of couse the slot_id would be implemented as a direct > > index into an array of BasicObject pointers. This would be the > > fastest way to get at the object. > But how can I do this if I don;t know: > a) what keys I am going to get in any event, since I can't predict all > seed objects and region type combinations > b) how many keys a module should reserve > If I understand you correctly you want to anticipate all keys that I could > ever have and then translate it into a slotID at the beginning of the run? > A clustring module only gets its keys which describes what data to > read or where to store its results, at the beginning of each event. I am > confused here. How should I apply this? This is of course just an idea here and a solution in some cases. To elaborate a bit, as each of the submodules (or modules) that will interact with the RRL3 object (for example) comes alive, it announces the key and perhaps the object it will be using (or creating). It does this by calling performing a registration procedure in a singleton utility class associated with the RRL3 object - SubModReco1: id1 = RRL3_Registry::instance()->IwillUse("KEY1"); id2 = RRL3_Registry::instance()->IwillUse("KEY2"); ... SubModReco2: id1 = RRL3_Registry::instance()->IwillUse("KEY2"); id2 = RRL3_Regsitry::instance()->IwillUse("KEY3"); Here Reco1/id2 and Reco2/id1 will be identical. When the real RRL3 objects comes to life, it builds the map up based on the information recorded in the RRL3_Registry object. It would not preclude other things from being added and manipulated, but it could be that it gives fast index lookup for preregistered things, whereas it would give map/key access for other things. There is a milliion different ways to design and implement such a system, this is just one limited example to illustrate it's usefulness (or uselessness?). > > > > ----------------- > > 4) Finding based on type of object. Many times users want to > > find an object in the hetero_container above by type, such as > > "give_me_the_first_object_of_type" > > This is going to be slow and if this is part of the required access > > pattern needed, then special things must be done if > > performance is critical. I'll assume this is not important. > I am afraid that this is important. Again an example: > The track finding module will need cluster data on its input. it is going > to loop through our hetero container and will do exactly what you fear, it > will do a loop over all regional cluster banks like. > for (RRL3::heteroContainer::Iterator ClusterIter, > ClusterIter.isValid(), > ++ClusterIter) > This is actually the main access mode for read. Other modules would do the > same thing just not with clusters but with tracks or with strip-ADC values > etc. The loop above is a good way to do it, but it does require tranversal of theentire list or map object, and a call to "dynamic_cast" for each item to determine the type. It would depend on the number of times it needs to be done and the structure of the associative array within the RRL3 object (map or vector or combination of both or many - example being one map for general access, and one vector for each type of object with pointers into the map - the EDM classes would probably manage objects put into the event like this). > > 5) There is an alternative to using a Base class for all objects > > stored in the container. Do this (by no means is this a complete > > implementation): > > > > // support class > > class AnyObject > > { > > AnyObject(); > > ~virtual AnyObject(); > > ... > > } > So this is just something with a virtual constructor typically gets made > in a factory? It replaces the base class that in the old solution we would > have to derive from? Is removes the need to have the object stored in the heterogeneouscontainer be derived from a common base class. Look at the sample insert() and find template function I put later in the example and the example user application code. > I'll try and annotate this to show what I do and what I don't understand > about it. > > > > // support class - wrapper for object > > template class SpecificObject : AnyObject > > { > > SpecificObject(T* d):obj(d) { } > did you not mean: > SpecificObject(T* d):_myd(d) { } > > > ... > > static T* get(AnyObject x); > > static void put(AnyObject x, T*); > why are these static functions? And what are they needed for? > > > > > T* _myd; > so Specific object contains a pointer to T, > > } Yes. The wrapper class SpecificObject just holds a pointer to thereal thing. The static methods can be used to hide the dynamic cast required to extract the AnyObject into the object that it holds. I was running out of type when typing in the previous message and realize that there is a few error in the example implementation (in other words it is really incomplete). I will put a corrected version at the end of this email. > To be honest, I don't know how this works at all. Can I give you a phone > call? Please look at my recoded example below. I actually use this code inanother application to remove coupling - the user does not actually know that the objects are stored in a heterogeneous container.Jim ------------------------------------------------------- class AnyObject { AnyObject() { } virtual ~AnyObject() { } } template class SpecificObject { SpecificObject(T* obj):_myobj(obj) { } ~SpecificObject() { } T* _myobj; static T* get(AnyObject* obj) { return dynamic_cast(obj->_myobj); } } typedef map HeteroMap; template int find(const HeteroMap& m, string key, T*& ret) { HeteroMap::iterator i = m.find(key); if(i==m.end()) return -1; // not found // fill users pointer with answer - use static get method here !!!!!!! ret=SpecificObject::get(i->second); if(ret==0) return -1; // error, not correct type return 0; } template int insert(HeteroMap& m, string key, T* obj) { // no checking in this example for duplicates!! m[key] = new SpecificObject(obj); return 0; } // remove function missing // example user application - Cow and Pig are derived from nothing HeteroMap my_map; int func(Cow* c, Pig* p) { // insertion insert(my_map, "MYCOW", c); insert(my_map, "MYPIG", p); // extraction Cow* ce; Pig* pe; find(my_map, "MYCOW", ce); find(my_map,"MYPIG",pe); find(my_map,"MYPIG,ce); // Error condition !!!!! ... } I hope I did not make any mistakes again - I'm running out of time again... -- Jim Kowalkowski - jbk@fnal.gov D0: 630/840-2215 - 5th floor of the D0 assembly building CDF: 630/840-6457 - 169F in the CDF trailers http://www-cdf.fnal.gov/internal/people/links/JamesKowalkowski/my.html http://www-d0.fnal.gov/~jbk/index.html From reichold@al1.physics.ox.ac.uk Thu Feb 11 18:31:19 1999 +0000 Date: Thu, 11 Feb 1999 18:31:18 +0000 (GMT) From: "Armin Reichold (LHC)" To: Jim Kowalkowski Subject: Re: Use of cloneable's a'la Lee in L3 trigger code containers In-Reply-To: <36C30F14.397BCA96@fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 41 Hi Jim, I am beginning to understand both the performance issues and the anyObject trick. I think there is one little bug in your example code, see below > ------------------------------------------------------- > class AnyObject > { > AnyObject() { } > virtual ~AnyObject() { } > } > > template class SpecificObject shoud this not be template class SpecificObject: public AnyObject > { > SpecificObject(T* obj):_myobj(obj) { } > ~SpecificObject() { } > > T* _myobj; > > static T* get(AnyObject* obj) > { > return dynamic_cast(obj->_myobj); > } > } > > typedef map HeteroMap; > > template int find(const HeteroMap& m, string key, T*& ret) > { > HeteroMap::iterator i = m.find(key); > if(i==m.end()) return -1; // not found > // fill users pointer with answer - use static get method here !!!!!!! > ret=SpecificObject::get(i->second); > if(ret==0) return -1; // error, not correct type > return 0; > } > template int insert(HeteroMap& m, string key, T* obj) > { > // no checking in this example for duplicates!! > m[key] = new SpecificObject(obj); > return 0; > } > > // remove function missing > > // example user application - Cow and Pig are derived from nothing > HeteroMap my_map; > int func(Cow* c, Pig* p) > { > // insertion > insert(my_map, "MYCOW", c); > insert(my_map, "MYPIG", p); > > // extraction > Cow* ce; > Pig* pe; > > find(my_map, "MYCOW", ce); > find(my_map,"MYPIG",pe); > find(my_map,"MYPIG,ce); // Error condition !!!!! > ... > } If SpecificObject was ment to inherit from anyObject than I think I understand how this works. This is really a nice and tricky bit of C++. Would have taken me years to make this up myself. Cheers Armin From reichold@al1.physics.ox.ac.uk Thu Feb 11 19:02:14 1999 +0000 Date: Thu, 11 Feb 1999 19:02:13 +0000 (GMT) From: "Armin Reichold (LHC)" To: Robert Kennedy cc: Marjorie Shapiro , jbk@fnal.gov, kennedy@fnal.gov, "ELIZABETH S. SEXTON KENNEDY" , "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Mat Martin , t.hessing1@physics.ox.ac.uk, Todd Huffman , "David S. Waters" , Christopher Henry Green , Kevin McFarland , Alfred Lee , Joseph Boudreau , Frederick Snider Subject: EDM and hetero containers In-Reply-To: <199902111636.KAA14916@cdfsga.fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 42 Dear All, as a point for the next EDM meeting, wich I can unfortunately not attend, I would like to raise the following: Besides the many unsolved implementation issues in the "concepts around RRL3" there is the definite need for: a) a completely non storable, transient hetero container called an RRL3_entry. This can hold storable objects (cluster data, tracks) and a few non storable objects (active flags, auxiliary information). b) a storable form of an RRL3_entry which, at the end of the event will take all the storable bits worth keeping in an RRL3_Entry and store them if they were not ment to be stored anyway due to the fact that are storables and someone else may have done a write persistent for them. Also store the collection of links to the storable objects that the original RRL3_Entry was. I would hope that a) and b) could be the same as there is little difference between them. I would also hope that we would not incur large translation penalties on either the write_persitent() of such an entry nor the creation and deletion of these things. Jim Kowalkowski has given me lots of usefull info about this and now I know that there are ways of hetero-storing things without making everyone inherit from something. The question we, the L3 regional people of the tribe of Oxford need to have answered soon is whether we should wait for such a container to be made available by the EDM group so that we have something which is professionally sound and used by others too, or if we should propose "our own" brand new Kowalkowski-container and have the EDM agree on it. I am asking this because the design of RRL3 would be build around this container and if we need to design the container as well the design is going to look different then if we took your container. (Unless by magic we came up with something as clever as the EDM people would have come up with and that I doubt) So could you discuss this a little bit between yourselves and then maybe come to a decision on tuesday next week? Cheers Armin ************************************************* * Dr. Armin Reichold | private: * * Research Officer | 17 Frys Hill * * University of Oxford | Oxford * * Particle & Nuclear Phys. Lab. | OX4 5GW * * 1 Keble Road | UK * * Oxford OX1 3RH * * UK * * Room 612 * * * * Tel.: +44-(0)1865-273358...(office) * * Tel.: +44-(0)1865-434856...(private) * * Fax.: +44-(0)1865-273418...(office) * * E-Mail: a.reichold1@physics.ox.ac.uk * ************************************************* From reichold@al1.physics.ox.ac.uk Tue Feb 16 09:51:54 1999 +0000 Date: Tue, 16 Feb 1999 09:51:53 +0000 (GMT) From: "Armin Reichold (LHC)" To: "Todd Huffman (CDF/ATLAS)" Subject: Re: EDM Meeting Tuesday 16-Feb 11:30 (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 43 No, I am not. Dave and Farrukh have to go to this meeting!!! I'll forward it to them too. Cheers Armin ************************************************* * Dr. Armin Reichold | private: * * Research Officer | 17 Frys Hill * * University of Oxford | Oxford * * Particle & Nuclear Phys. Lab. | OX4 5GW * * 1 Keble Road | UK * * Oxford OX1 3RH * * UK * * Room 612 * * * * Tel.: +44-(0)1865-273358...(office) * * Tel.: +44-(0)1865-434856...(private) * * Fax.: +44-(0)1865-273418...(office) * * E-Mail: a.reichold1@physics.ox.ac.uk * ************************************************* On Tue, 16 Feb 1999, Todd Huffman (CDF/ATLAS) wrote: > > Are you getting these notices? > > Cheers, > Todd > > ******************************* > ~ Dr. B. Todd Huffman ~ > ~ Particle and Nuclear Physics~ > ~ University of Oxford ~ > ~ Rm 631 ~ > ~ Keble Rd ~ > ~ Oxford OX1 3RH UK ~ > ~ ~ > ~ Phone: 44 - 1865 - 273402 ~ > ~ LMH: 44 - 1865 - 274307 ~ > ~ FAX: 44 - 1865 - 273418 ~ > ~ Home: 44 - 1865 - 450240 ~ > ******************************* > > ---------- Forwarded message ---------- > Date: Mon, 15 Feb 1999 15:01:30 CST > From: Robert Kennedy > To: kennedy@fnal.gov, pcalafiura@lbl.gov, greenc@fnal.gov, ehafen@fnal.gov, > t.huffman1@physics.ox.ac.uk, jbk@fnal.gov, leeiv@fnal.gov, > ksmcf@fnal.gov, murat@fnal.gov, rolli@fnal.gov, singh@fnal.gov, > tamburello@fnal.gov > Cc: dan@fnal.gov, buckley@fnal.gov, sexton@fnal.gov, shapiro@cdfsga.fnal.gov, > rs@fnal.gov > Subject: EDM Meeting Tuesday 16-Feb 11:30 > > Hello, > > We will have a meeting of the EDM-WG at 11:30 Feb 16 in new B0-2 vid-conf > room. So far, for the agenda, we have: > > 1) RRL3-related discussion: How to decompose the overall requirements into > EDM-compatible (and Infrastructure-components) components > > 2) Discussion of initial proposal with use-cases (sent in my previous e-mail) > a) How much of the CDFTrack/CDFTrackCollection Selection criteria can > we include in this. (NOT in proposal yet) > b) Proposal on how users create and maintain the methods > StorableObject::streamIn/Out() w/rootcint (NOT in proposal yet) > c) Are there other pieces missing, or points to be clarifed? > d) Are we willing to adapt to this? Do we need to perform surveys with a > proposal in hand in order to confidently answer this? > > 3) Discuss what to state as the EDM status at Wednesday offline meeting > > Thanks, > Rob (Just survived "Spring" skiing) K. > > > > From reichold@al1.physics.ox.ac.uk Tue Feb 16 09:57:20 1999 +0000 Date: Tue, 16 Feb 1999 09:57:20 +0000 (GMT) From: "Armin Reichold (LHC)" To: kennedy@cdfsga.fnal.gov cc: "David S. Waters" , "\"hud-hud-e-jAn\", Farrukh Azfar" Subject: please add me to the EDM distribution list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 44 Hi Rob, I just noticed that I did not get any of the mail from the EDM distribution list. In particular not the call for the meeting to discuss RRL3 relevant issues today. Can you please add me to the list? Cheers Armin ************************************************* * Dr. Armin Reichold | private: * * Research Officer | 17 Frys Hill * * University of Oxford | Oxford * * Particle & Nuclear Phys. Lab. | OX4 5GW * * 1 Keble Road | UK * * Oxford OX1 3RH * * UK * * Room 612 * * * * Tel.: +44-(0)1865-273358...(office) * * Tel.: +44-(0)1865-434856...(private) * * Fax.: +44-(0)1865-273418...(office) * * E-Mail: a.reichold1@physics.ox.ac.uk * ************************************************* From reichold@al1.physics.ox.ac.uk Wed Feb 17 13:11:38 1999 +0000 Date: Wed, 17 Feb 1999 13:11:38 +0000 (GMT) From: "Armin Reichold (LHC)" To: Chris Green Subject: Re: Discussion material: Regional bookkeeping and the EDM In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 45 Hi Chris, only read your message now. Could you provide me with a hint as to where I can find information that explains the concepts of hunks, tags, locking etc. that you are heavily using. I amnot at all familiar with these - in fact I have never ever heared the words before. Not even in real language. Therefore I am still very much in the dark as to what you ment in your mail and I'll try to comment when I understand more. Cheers Armin ************************************************* * Dr. Armin Reichold | private: * * Research Officer | 17 Frys Hill * * University of Oxford | Oxford * * Particle & Nuclear Phys. Lab. | OX4 5GW * * 1 Keble Road | UK * * Oxford OX1 3RH * * UK * * Room 612 * * * * Tel.: +44-(0)1865-273358...(office) * * Tel.: +44-(0)1865-434856...(private) * * Fax.: +44-(0)1865-273418...(office) * * E-Mail: a.reichold1@physics.ox.ac.uk * ************************************************* From reichold@al1.physics.ox.ac.uk Wed Feb 17 13:18:58 1999 +0000 Date: Wed, 17 Feb 1999 13:18:58 +0000 (GMT) From: "Armin Reichold (LHC)" To: Robert Kennedy cc: Stig Topp-Jorgensen Subject: Re: Follow-up on the RRL3/Infrastructure meeting Thursday In-Reply-To: <199902162202.QAA12621@cdfsga.fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 46 Hi Rob, thursday any time will be fine for me to join the meeting via video. Caveat: I need to check whether our end of the video is available on thursday but I guess it is. Cheers Arnmin ************************************************* * Dr. Armin Reichold | private: * * Research Officer | 17 Frys Hill * * University of Oxford | Oxford * * Particle & Nuclear Phys. Lab. | OX4 5GW * * 1 Keble Road | UK * * Oxford OX1 3RH * * UK * * Room 612 * * * * Tel.: +44-(0)1865-273358...(office) * * Tel.: +44-(0)1865-434856...(private) * * Fax.: +44-(0)1865-273418...(office) * * E-Mail: a.reichold1@physics.ox.ac.uk * ************************************************* On Tue, 16 Feb 1999, Robert Kennedy wrote: > Hello, > > Has anyone booked a room for the meeting on Thursday for the RRL3 - > Infrastructure discussion? Has a time been set? I thought Marge or I were > going to set things up at this end... but I do not recall or find e-mail > indicating a time being set or a room being found at FNAL. > > Thanks, > Rob K. > > > From reichold@al1.physics.ox.ac.uk Wed Feb 17 16:22:37 1999 +0000 Date: Wed, 17 Feb 1999 16:22:35 +0000 (GMT) From: "Armin Reichold (LHC)" To: Robert Kennedy cc: "Oxford CDF members -- \"hud-hud-e-jAn\", Farrukh Azfar" , Jim Loken , Louis Lyons , Mat Martin , "Peter B. Renton" , t.hessing1@physics.ox.ac.uk, Todd Huffman , "David S. Waters" , Christopher Henry Green , Kevin McFarland Subject: Re: Follow-up on the RRL3/Infrastructure meeting Thursday In-Reply-To: <199902162202.QAA12621@cdfsga.fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 47 Dear Robert, unforrtunately our video conferencing system is booked allready from 16.00 to 18.00 our time (10.00 to 12.00 your time) please try to find a different slot if possible. Not too late please. cheers Armin ************************************************* * Dr. Armin Reichold | private: * * Research Officer | 17 Frys Hill * * University of Oxford | Oxford * * Particle & Nuclear Phys. Lab. | OX4 5GW * * 1 Keble Road | UK * * Oxford OX1 3RH * * UK * * Room 612 * * * * Tel.: +44-(0)1865-273358...(office) * * Tel.: +44-(0)1865-434856...(private) * * Fax.: +44-(0)1865-273418...(office) * * E-Mail: a.reichold1@physics.ox.ac.uk * ************************************************* From reichold@al1.physics.ox.ac.uk Thu Feb 18 09:32:28 1999 +0000 Date: Thu, 18 Feb 1999 09:32:28 +0000 (GMT) From: "Armin Reichold (LHC)" To: Chris Green cc: CDF Event Data Model WG -- Liz Buckley-Geer , dan@fnal.gov, ehafen@fnal.gov, jbk@fnal.gov, kennedy@fnal.gov, Kevin McFarland , leeiv@fnal.gov, murat@fnal.gov, pcalafiura@lbl.gov, rolli@fnal.gov, rs@fnal.gov, sexton@fnal.gov, shapiro@cdfsga.fnal.gov, singh@fnal.gov, Todd Huffman , tamburello@fnal.gov, Joe Boudreau , Oxford CDF group -- Armin Reichold , Dr Farrukh Azfar , David Waters , Jim Loken Subject: Re: Discussion material: Regional bookkeeping and the EDM In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 48 Dear Chris, having read your auxiliary message I think I am now able to make some comments on you suggestions belwo. > >From CDF 4826, RRL3 contains `entries', which are uniquely identified by > two items of information: the seed object, and the region type. It also > holds or maintains access (links) to the following items of information: > > a) A list of reconstruction requests; > b) Reconstruction results, including: > what type of reconstruction has been done; > the region `object'; > a silicon strip set; > clustered data; > reconstructed tracks of various types; > (possibly) other high-level physics objects; > c) An `active flag', denoting whether a given region should be / is > being considered in the current trigger path; > d) Trigger identifiers, denoting which triggers are / have been > interested in each region. > > As can be seen, the information to be held has so far been defined only > in a very vague way. > > I see several technical issues related to RRL3 which are directly > related to the EDM and persistence: > > 1) How can the regional information above be accessed from all relevant > areas in the event quickly and efficiently? > > 2) How does one maintain the information and update it where required > whilst still holding on to the cherished concepts of reproducibility > and traceability at all stages? > > 3) How is the information kept in persistent storage bearing in mind the > above concerns? > > I do *not* intend to provide specific, code-design-level answers with > this mail as to the exact form of the transient representation of this > information. Several mails over the last week have focussed on this and > the frequently encountered problem of heterogeneous collections. I think > Jim's contribution was very useful, and the concept of factories for > reconstruction-level objects as used *all over* the code needs to be > considered very carefully. I guess with *all over* you want to say *not just in L3*? I think the performance advantages (avoiding the heap manager and fragmentation) that Jim mentioned are most relevant for L3. I would like to suggest that we definitely try to produce objects that come and go in large numbers through the life of a job via factories even if this is a solution that only L3 needs to take. However I think that the factories we use be at least stereotypical of factories *for everybody* and should thus be developed in close contact (maybe even by?) the EDM group. > In terms of its application to RRL3 though, I > think it will be possible to design a system which works within what the > EDM is currently evolving towards, and the EDM itself will probably > provide a common base class for all persistent or storable objects which > will have the properties needed for the efficient storage and treatment > of heterogeneous collections. This does not relate to the factories any more? > > I asked myself the following questions while reading through CDF 4826 > and considering it in the context of the EDM discussions: > > *) Is re-use of regional objects possible or even desirable? With reuse you are adressing the factory aproach I guess? > > *) What does the active flag signify and is it necessary? > > *) Does an `entry' need to know what triggers are interested in it, or > is it sufficient to organise the list of regions by trigger rather > than triggers by region? > > *) Path-killing: when? > why? > how does it affect entries and the reproducibility of > reconstruction results? > > I left the first question mostly open, although I personally believe > that at least the region objects (whatever they are) themselves should > be re-usable, even if tracks, electrons, etc, etc, are not. I agree!! > > After thinking about the matter for a while, I believe that the `active' > flag is *not* necessary. Regional reconstruction modules in a given path > should already know (via talk-to?) the class of seed object/region with > which they should be concerned, and be able to loop over them all in > sequence. Any concept of an `active' flag which is cleared by every path > (and therefore cannot easily have its history made persistent) causes > serious problems for any EDM scenario considered thus far, and I think > these problems can be worked around with talk-tos. Talk-to parameters > will be saved as AbsParmSets and therefore the history will persist as > desired. I agree with your solution for abolishing the active flag but I also want to know what it means to talk to every regional module in in every path in terms of overheads. Is this not a very slow process? Or does this not hurt us because it is only done at the beginning of the job? If so, does this mean that we have lots and lots of modules (a complete set of regional modules for every path) present whereas without this specialisation we would only need one set for all paths? I am not sure what this means for the performance or the workload on the framework. Maybe I misunderstood the concept completely wrong and you need to teach me even more. I do not fully understand why the active flag is so much in conflict with the EDM. I can see that it would violate the write-lock principle if it changes during an event, but why does it need to be part of the persistant representation of RRL3 data? It is truely meaningless after a certain path has finished and it is very easy to reconstruct which path was interested in which region-type/seed object because of the absParms. > My comments on the part below are trying to translate from EDM language to RRL3 language so I make sure that we mean the same thing. > So now I try to briefly describe one possible way of saving the required > bookkeeping data persistently (almost) within the current EDM. As far as > I can tell the only extended features required are ones which have > already been discussed: a `hunk ID'/key concept, write-locks on > individual hunks, and at least the concept of collections of different > types of key (possibly descending from a simple base class). > > Define a tag Q consisting of: > > a seed object identifier S (implementation not specified here); > a region-type R (implementation not specified here). So the tag is the new word for the RRL3_EntryId? > > Stored units (`hunks', cf RDK) thus consist here of units tagged by keys > of type Q. Individual units are locked after construction and are > therefore consistent with the EDM. A hunk will contain: > > its own unique unit identifier U; > a tag Q; > data D; > > where D can be: I would like to modify the above line to: > where D is a list like container of : > > a list of reconstruction requests (implementation not specified here); > a region object; > a list of one or more hunk IDs linking to other regional data > (SIXD/ISLD pairs, QSIC/QSIP pairs, track collections etc); and I'd like to modify the above 4 lines to: several unique unit identifiers U these unit identifiers point us to: a list of reconstruction requests a region object; any other regional result data (QSIC/QSIP pairs (I dont know what they are, cluster banks, track collections etc); Your hunk, so it seems to me, was not ment to be our RRL3_Entry but rather a way of attaching a tag Q to anything that could end up in the event record. To me this seems unnecessary since the data D does not need to know about the tag. Only an RRL3_entry needs to know what data (results) it contains. This is why I modified your proposal. Furterhmore I think you forgot a piece of data here, namely the part that stores how much of the recontruction request has allready been satisfied. (Or in other words the fact that the recontruction request is not so much a request as a status indicator). This, in the same way as the active flag, is changing during the event and I think it is needed. Please allow me an example: If a clustring module should run inside a region than it would of course be possible for future clustering modules to check if it has done so by checking if a link to cluster data exists in RRL3 for this region. However if the clustre module did not find clusters it will not make a cluster bank (this probably happens more often with tracking modules and track sets) and any future clustering module will just try again. So this part of RRL3 can not be "put into the event record" once and then write locked. But I do not know if it would need to be there anyway. We can reconstruct the temporal sequence of which module did satisfy which request at what time by simply reconstructing which modules where in the paths in which sequence (trigger table?) and what there parameters were. Then we run the job again and get the same answere as during L3. But maybe this is too simplistic? > > Identifiers and tags should therefore be very small as with a system > mainly concerned with bookkeeping such as RRL3, they actually make up a > significant part of the stored information. This is an important point in my view. > > I am not sure yet whether one actually needs to save information about > which triggers are interested in which regions, but there are three ways > of doing this: > > a) via saved talk-to parameters as described above (information is > diffuse and hard to collate); > > b) small units consisting only of tags (U,Q,T), where T uniquely > identifies the trigger (much space (and processing?) overhead); > > c) The RegionInitModule (see CDF-4826) writing out a unit (U,T,Q1...Qn) > for each trigger path; I think storing which trigger was interested in which region is only needed if someone wants to use this during analysis. It does not influence the way the L3 program would run. > > Finally, Armin mentioned the need for all regional reconstruction > modules to be able to loop over regions, and raised questions about > whether this functionality should be provided by the Framework. In > conjunction with this, I wonder whether the RRL3 system should be > constructed in a similar way to the geometry system: a `manager' module > which sets up objects (possibly singletons like CdfDetector) with > carefully managed functionality which can be accessed from the event > loop of any module to (say) iterate over all regions, sorted by tags > Q. This will require careful thought and much discussion with C++ and > Framework experts (Liz) and perhaps Joe as the other main implementor of > the geometry system, and I do not presume to short-circuit that process > here, merely to jump-start it. I only brought this idea up to show how "un-framwork-like" such a loop would be. I would like to agree with Kevin here that this loop is realy an intra module taks and very clearly recontsructable at any later time. In summary: - Sorry the comments are so long. - Factories are good. (should develop widely useable and fast ones) - unique identifiers U are our way to link persistant results into RRL3 - I either disagree about the concept of your hunk or I do not understand how I can build an RRL3 entry out of them. For example the RRL3 never needs to know about the SIXD/SILD banks. There is only ever one of them and it is not a results of the recontruction but an input to it. - The recontruction request needs to be called recontructin status and it changes during the event. - we have no way of linking changing objects into the RRL3 yet as they could not be hunks Cheers Armin