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...)
to the top of the L3 agenda. That meeting developed a lengthy list, mostly from Cathy's presentation, but with additions from Ed Frank, Al Eisner and Larry Gladney, and comments from others. What follows here is not meant as minutes for the meeting, but as an attempt to summarize the list.
  1. Engineering Needs (see also Appendix)
    1. Digi's from event store - this will greatly speed up doing multiple runs with different L3 algorithms or configuration.
    2. A functional TrgConfig - will eventually make it easier to avoid mistakes in setting up an L3 run (although initially it may make it harder).
    3. First version of a realistic user interface - will be facilitated by using TrgConfig. (Strawman runs should demonstrate and test this interface, as well as measuring performance.)
    4. A more online-like environment. (See Appendix.)
    5. Ability of a script to set multiple flags (for use in the "theta flinger", item g below), and eventually a way to implement two levels of prescaling based upon them.
  2. Realistic Input Configuration

    A full set of GLT lines should be defined, with realistic prescale factors, and improved Level 1 "Safe" (L1Safe) trigger definitions. L1Safe should satisfy understandibility and diagnosis requirements as well as the usual rate requirements. (Having a larger set of GLT lines, with outputs from their simulation in the event store, will also facilitate flexibility.) Participation of the L1 group will be helpful.

  3. Fiducials

    Code to implement fiducials for various types of events will have to be written. In the past, fiducials have been defined in TrgDC (in Fortran). TrgDC information will not be available in the event store, and the L3 job cannot directly invoke this simulation code. However, a StdHep object will be available in the event store. Defining fiducials based on MC truth information is a physics requirements issue, rather than a trigger issue, so it would best be done by someone from the physics group.

  4. Geometry

    It was clear in the Strawman runs that we did not understand the region below 350 mr; one symptom was the response of the Level 1 "2-prong" triggers (Open and Safe) to what we considered 1-prong Bhabha events. A possible cause is an inadequate GEANT material model in that region; spray from edge-effects is another concern. The primary L3 task is to look at the unexplained events, and correlate their appearance with the L1 response. The simulation side also needs further investigation.

  5. Bhabhas
    1. Better Bhabha generator. (Previous runs used Bhlumi output, which showed some exceedingly odd kinematic correlations in the phase space.)
    2. Better sorting of Bhabhas into various categories (one-prong vs. two- prong, radiative vs. non-radiative) based on the explicit needs of the EMC group. One option is to separately generate the different samples. The EMC group is already looking into more precisely defined requirements.
    3. Improved two-prong selection.
    4. Improved mechanism for keeping Bhabhas out of the physics samples. (The 2-prong Bhabha "veto" was not efficient enough, and a 1-prong Bhabha veto was not really implemented.)
    5. Separation of e+e- from 2-gamma final states.
    6. Algorithm to separate desired radiative Bhabhas (and 3-photon final state events).
    7. Implement theta-flinger (to allow polar-angle-dependent prescaling). This is part engineering (1e above) and part algorithm; the EMC group needs to define the latter.
  6. Algorithms

    Strawman is in large part a (lower-case) framework for the testing of L3 algorithms, so the list would not be complete without at least mentioning algorithm development. Some of this is already implicit in item 5. In addition, we have to evaluate various ways of meeting understandability requirements in L3. A prime example is an EMC-based (probably partially orthogonal) L3 algorithm to redundantly pick up charged-particle events.

  7. Other Mode Selections

    Physics (or topological?) modes which L3 might need to distinguish should be itemized. (Examples: the mu+mu- final state; and perhaps some other signature which would be sensitive to an initial PEP-II energy scan.) Then it would be useful to understand what it takes to distinguish them.

  8. Documentation on how to carry out the Strawman Runs Presently much of this is embodied in the L3Trigger tcl files. Giuliana Manzin is the new L3Trigger package coordinator.

APPENDIX: Strawman Mechanics

[Based upon information from Gregory Dubois-Felsmann, Ed Frank and Anders Ryd]

There will be at least three stages to doing a full L3 simulation run. The idea is that the last stage should be the same as L3 running on real data; and that if the earlier stages are planned with care, they will not have to be repeated often.

Stage 1:
Simulation, with Digi's stored in an event database. (For some cases, the event generator may run in a separate "Stage 0".) This stage requires the most care, because it includes L1 simulation. Thus, for example, any possibly-useful GLT lines should be defined. Any changes in L1 thresholds, etc., would imply a re-run. This stage is in effect the present SimApp, which includes background- mixing, generally at X1. So far, trials with X10 backgrounds have been exceedingly slow, but for applications geared toward L3 much of the time-consuming code (e.g., for the Ifr) could be turned off. (However, see note at end.)
Stage 2:
Database --> Tagged Containers (xtc). Doing this requires the event-building scaffolding, and the various Digi-to-TC convertors working within it. Not yet ready.
Stage 3:
The L3 run, starting from xtc's. They can either be passed by a shared-memory mechanism from Stage 2, or else saved as files and played back. This stage requires that the L3 code can work starting from tagged containers -- only partly true to date.
A complication: much of the L3 work done to date has utilized selective saving of events, to enhance samples of interest. It is unclear how/if this fits into the SimApp implementation of Stage 1.

Author: A. Eisner - EISNER@slac.stanford.edu
8/6/98