SLAC PEP-II
BABAR
SLAC<->RAL
Babar logo
HEPIC E,S & H Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Unwrap page!
Det. Search
Who's who?
Meetings
FAQ
Images
Archive
Systems
Performance
Intern. region
Vertex Tracker
Drift chamber
DIRC
Calorimeter
IFR
LST
Magnet
Electronics
Trigger
Operations
Run Coordination
Contact Experts
Shift Takers Info
Operations Manual
Electronic Logbook
Ops Hypernews
Shift Signup
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator
(More checks...)

Level 3 DRAFT Schedule & Work plan

[Terminology] [Reviews] [Schedule]

It would probably be very useful to the Level 3 effort to settle on a schedule for its work over the next couple of years, as a way of organizing ourselves and of defining points in time when we can check to make sure that we are doing reasonable things.

From conversations with several of the active members of the group, I have assembled the following draft proposal for the broad structure of such a plan. It is based on parallel construction with the other systems' schedules.

In particular, I would like to propose that we follow the

  1. Preliminary Design Requirements
  2. Conceptual Design
  3. Preliminary Design
  4. Final Design

planning structure that many of the other systems are following, perhaps with some twists appropriate to Level 3's specific situation.

I begin with an explanation of what the above terms might mean to Level 3. It should be noted that the trigger as a whole, of which Level 3 is a part not only in the logical but also in the administrative sense, is following a version of the structure above, although Level 3 has not recently been a focus of this sort of attention. It seems potentially beneficial to move toward considering Level 3 more in detail on its own terms.

The Electronics group has, over time, devised a very specific set of meanings for the above terms. I am not advocating that we follow them rigorously - our comparatively late start and the somewhat different nature of a software project militate against that - but I do think that they provide a useful starting point, so readers not already familiar with them might wish to take a look at the version being applied to the trigger as a whole:

/BFROOT/www/Detector/Trigger/95/pdrr-cdr-elex-review-materials

The charge to the recent online review (a sort of combined conceptual and preliminary design review) might also be interesting reading:

/BFROOT/www/Computing/Online/Reviews/Oct.96/Admin/Charge.to.Panel.txt

It should be said at the start that the schedule will not be useful if it is unreasonably burdensome or constraining, and that these concerns are ones which I would hope we will be able to take into account satisfactorily at the 9 January meeting.

1) Preliminary Design Requirements

The trigger's general requirements, together with the related OEP (Online Event Processing system) requirements, cover a lot of this ground in high-level terms: naming specific physics processes and setting the required efficiency and sigma(efficiency) for them, requiring very-low-deadtime operation under specified running conditions, and so on.

It would be useful, however, to construct a document which brought together all the Level 3-related requirements already established at higher levels, as well as the more detailed implied requirements which may be deduced from them. A useful exercise of this type would be the calculation of the total rate expected from physics processes, parameterized by, for instance, the mass cuts likely to be applied to two-photon events and a prescale factor for Bhabhas, and the determination therefrom of an actual background budget.

The requirements would also include interface requirements with other detector hardware and software systems, among them undoubtedly Level 1 and OEP. In addition, assembling a coherent set of requirements might reveal additional pieces of information needed about the expected performance of the Level 1 trigger.

The point here is not that these requirements and implied requirements are not already known, but that it would be useful, regardless of that, to collect them in one place and agree on the full set of requirements which our efforts will be designed to satisfy. Desiderata, as opposed to hard requirements, could also be included in the document.

It would not be my intention to do anything very much more time-consuming than collating the existing, somewhat more scattered requirements and possible adding a little connecting material along the lines of the background budget.

2) Conceptual Design

For Level 3, I envision the conceptual design as being a natural outgrowth of the current phase of algorithm research. It would draw from what we are learning and be a first model of how one might construct a full Level 3 trigger module out of them. This would include presenting evidence that the conceptual design's algorithms appear capable of meeting the physics efficiency and background rejection requirements. To be more specific, the conceptual design should probably include a discussion or demonstration of how each of the benchmark physics modes would be recognized (including two-photon events) and distinguished from all significant forms of background. There should also be plausible indications that the algorithms could be implemented in a form fast enough to meet the data rate and deadtime requirements, but such implementations would not be required to be demonstrated as part of the conceptual design.

The conceptual design should also include a set of preliminary interface specifications covering the relations with other systems. The principal issues here would be the design of the event data and OEP framework/module interfaces.

3) Preliminary Design

The preliminary design stage would basically consist of candidate implementations of the conceptual design's algorithm(s), using the real event data and OEP framework interfaces in the form they would be available in at that time. It should be possible to test them against the then version of the design requirements, and though the preliminary design' implementation need not meet all the requirements, it probably would be good to require it to meet the bulk of the efficiency and rejection requirements within some reasonable margin, with good quantitative progress on meeting the rate performance req's. It should show evidence of being well on the way to meeting other more detailed requirements, and a schedule for further testing and development should be provided.

Interface specifications and requirements on other systems should be in a near-final form with few changes expected. In particular, this is the moment when Level 3 will have to begin to provide significant quantitative performance input to the OEP/Online Farm group to assist in determining the required performance of the Farm hardware and framework.

3) Final Design

The final design, in my view, should be, in effect, a beta release of a realistic, fully function Level 3 trigger module (or modules), fitting in the then release of OEP and the rest of the online, and capable of meeting the great majority of its then-current design requirements. Further work before first beams, ideally, would be limited to fine tuning.

Full-scale performance measurements with conservative margin estimates would be needed at this point in order to support the final round of acquisition of online farm nodes.


Reviews

I have made an effort thus far to avoid using the term "review", although it generally appears together with the above technology. I realize and appreciate from my own experience that reviews can be distracting and time-consuming. Nevertheless, I would like to argue that a review process of suitably modest scale would be helpful to our effort in the long run.

Whether we adopt this approach or not should be a key topic for discussion at the 9 January meeting. I would contend that, used sparingly, reviews, especially with occasional outside participation, for instance from a CLEO physicist with experience in their Level 3 system, would be useful insurance against overlooking the obvious or an overly insular approach, help in keeping the rest of the BaBar collaboration informed of our progress and provide them opportunities to ensure that their interests (such as in unusual physics modes) are being represented, and, not incidentally, provide us with clearer milestones against which we can judge our own progress.

I would suggest at least two such formal reviews, though, associated with the conceptual and preliminary designs. The preliminary design requirements are largely derivative of others already reviewed, and I think the final design can be presented to the collaboration through BaBar notes and presentation(s) at a collaboration meeting at the appropriate time, without scheduling a separate review, assuming things have gone well. (If they have not, a review would be indicated, most likely.)

The goal would be to keep the reviews lightweight and short, preferably half days, at least for the CDR, but still to allow for sufficient questioning that a good "conversation" ensues.


Schedule

I'd like to propose the following dates for the four milestones above. I show a range of dates as well as my rough favorite, at least until we discuss this at our meeting.

Milestone Date (range)
Preliminary Design Req's presented Feb. 1997, before coll. mtg.
Conceptual Design Review early June 1997 (May - mid-July)
Preliminary Design Review December 1997 (Nov '97 - Jan '98)
Final Design presented July 1998 (May - July)

Comments are of course the whole point of this exercise, so have at it!

I am willing to do the work of assembling the Preliminary Design Requirements and publishing them after our group has had a chance to go over them. I think they would make a good keynote for a parallel session that I'm proposing we should have at next month's collaboration meeting, in which people in the group who've been making progress with algorithms would also be encouraged to present their work.

The period between now and June-July, then, would be one in which the focus would be to continue as we have been going the past few months, finding workable algorithms to cover all the principal challenges - not necessarily the final ones, and not necessarily in a high-throughput implementation or even working directly on data in standard format, but proofs of concept with at least the possibility of being made fast.

Before very much longer, though, we will have to transition, if not necessarily all at once, to writing code for the real system environment and beginning serious performance measurements. I think the CDR in the summer would serve as a useful opportunity for stock-taking as we begin that transition. The PDR would then cover a first full set of candidate implementations, and help to move us into a phase of getting the details right; the FDR would then cover our product, a putatively and demonstrably workable trigger (to the extent that we understand the anticipated environment).

As we decide on this schedule or another, we should also look at the linkages with the HER and LER commissioning projects, which will provide a couple of infusions of fresh information concerning the backgrounds, and with the online and Level 1 schedules.

We should also consider our internal schedule and work plan in more detail. I'd like to cover this at this week's meeting as time permits, or at the next one if necessary. The issues which seem to be of particularly high priority in the near future are developing a plan to go beyond our first round of candidate algorithms, if they prove to fall short, and of finding an interested party to take on all-neutral triggering as a project, but we also have some matters of interface definitions which will need attention in the next month or two.


Gregory P. Dubois-Felsmann
Last modified: Wed Jan 8 21:50:18 PST