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...)

Hyperlinks in the list point to documentation at the time of achievement of that milestone.

BaBar Level 3 Trigger Milestones

MS_Type is Milestone type.

MS_Type Activity Objective Date
Eng Establish the Milestones List Guide work 12/18/97
Eng Mixing production run Make large sample of
pre-mixed, pre-triggered
backgrounds. Needed for
following milestone
12/19/97
Eng Migrate all tools to
Framework, release 5.2.2
Part of physics zero-level
benchmark milestone
12/19/97
Eng Create filters, integrate
with all tools in a single
L3Master executable.
Part of physics zero-level
benchmark milestone
12/19/97
Phys Establish a zeroth-level
physics benchmark using
scripts formed from all
tools in a single L3Master
executable.
Provides a comparison
point for future physics
studies.
12/22/97
Eng Prototype of an input line
generator
Uses current L1 output lines
strictly to support
zero-level benchmark
study.
12/19/97
Eng List of deliverables (along
with dates) for what we will
need from other subsystems
in order to complete L3
Need to do this early
enough to impact other
schedules as well as
decide dates for our
own milestones
01/16/98
Eng At least one monitoring
tool per L3 tool.
It is enough to just define
a histogram and show an
example of a good run.
01/16/98
Phys Establish benchmark
background sample definitions
Define simulated background
samples that represent our
nominal and worst cases for
various backgrounds.
Rejection performance will
be defined relative to these
samples
01/23/98
Phys List the background sources
we have not considered and
assumptions about ones we
have.
Addresses one part of
concern from CDR.
end-Jan.
Eng Place all Level 3 code into
the standard release structure,
i.e. it must meet all OEP and
offline standards.
Prerequisite to supporting
L3 for outside consumers.
mid-Jan.
Phys Define useful quantities
for the DCH and SVT tools to
deliver for low-multiplicity
charged-track events.
Needed for studies of physics
selection algorithms (e.g.
for charged two-prongs)
List of background 'knobs'
is included here.
01/23/98
Phys Define useful quantities
for neutral-particle triggering.
Similar motivations as above.
Include the two-photon
pi+pi-pi0 benchmark process
List of background 'knobs'
is included here.
01/30/98
Phys Define useful quantities for
triggering on Bhabhas and
e+e- --> two photons
Similar motivations as above.
List of background 'knobs'
is included here.
01/30/98
Eng Support an OEP consumer
of L3 results (e.g. OEP
pre-scaler)
First attempt at delivering
a product. Test of frailty,
documentation, etc. Begins
process of pointed feedback
from external sources.
01/30/98
Eng Study physics acceptances
and BG acceptances for the
three tools independently,
but run via the integrated L3Master.
Establish correctness of
the integration.
01/30/98
Eng Get all L3 scripts and tools
fully integrated into
Framework
L3 code must meet all
"reasonable" tests for
maintainability for the
indefinite future
01/30/98
Eng Enumeration of configuration
data needed by each tool.
Begin determination of OEP
interaction.
01/30/98
Phys Breadboard design for
measuring acceptances and
performance parameters from
data
for the various tools.
Single milestone or several? late Jan.
Eng At least one tool plus
L3Master running under OEP.
Integration with OEP. 2/05/98
Phys Preliminary conclusions
concerning orthogonality
of triggers.
Improve understanding of
how trigger efficiencies
will be measured offline.
02/06/98
Phys Define useful quantities for
maintaining partial orthogonality
Needed early enough in
the physics algorithm
development process to
ensure some degree of
orthogonality in the final
system.
02/13/98
Eng Establish chain of MC data->
online format (TCs) -> OEP
-> L3Master + at least one
tool -> result delivered to
OEP.
Test OEP/L3 interface. This
may need to happen quite early
to guide OEP implementation.
The tool should receive con-
figuration and report errors
via OEP interface.
mid Feb.
Eng As above, but recompile and
execute in offline Framework.
Demonstrate that L3 runs
both online and offline as
per a requirement. May be
a no-op depending on how much
this is really an OEP-supported
capability.
02/15/98
Eng Implement 'knobs' into
the set of tools available,
develop new tools if needed.
Part of physics algorithm
development. Also necessary
for meaningful performance
benchmarks to occur.
02/15/98
Phys Define appropriate histograms
to help measure efficiency vs.
kinematic variables for the
benchmark physics processes.
Prepare for trigger algorithm
evaluation.
02/22/98
Phys Study the efficacy of various
filters using the available
knobs for charged triggers.
"Efficacy" is defined in
terms of background rejection,
signal efficiency, accuracy
of simulation and distance
from cliff-edges. Note that
this should be an iterative
process.
02/22/98
Eng Implement realistic monitoring
tools. Should be extensible
for addition of new items,
e.g., new histograms, but
a basic set should be available
for each tool, and the
monitoring methods use
OEP capabilities.
Needed for physics and performance
benchmarking studies.
02/30/98
Phys Define an appropriate set of
output lines for our physics
categories.
Deliverable must match our
stated requirements.
03/01/98
Phys Develop and study the efficacy
of various filters using the
full set of knobs for neutral
triggers, including EMC tools
and track-cluster matching.
"Efficacy" is defined as
in a previous item
justification.
03/13/98
Eng Establish chain of MC data->
TC's -> OEP -> L3Master plus
all tools.
Completion of OEP integration. 03/15/98
Eng Study the efficacy of a
partially orthogonal trigger
for charged-particle events
(e.g. using only EMC
information on one particle).
Develop a parallel effort (to
efficiency/rejection studies)
for tool development aimed at
maintaining orthogonality
where we can.
03/15/98
Eng Initial Benchmarks to measure
resource consumption for a
set of background and
physics processes.
Test stand will be needed,
e.g., on Sun, to use
Workshop to separate L3
consumption from OEP, etc.
mid-March
Phys Sort a mixed sample of
physics, background, etc.
Must know by this time what
is needed, in terms of event
classification, e.g., do we
to do more than Bhabhas? If
so, do a mock run.
mid-March
Phys Selection of Bhabhas
implemented. Acceptance and
contamination estimated.
Note: depends on requirements
which must be set by groups
other than Level 3.
initial target is
late March
Phys Demonstrate with working
software that L3 is meeting
the B Physics requirements
(A.1.1 through A1.1.3 of the
Trigger Requirements document)
with presently anticipated x10
background conditions, and
show that satisfactory progress
is being made toward meeting
all of the Physics Essential
Requirements (section IIIa of
that document).
For the PDR there needs to be
both a working system which
proves L3 can deliver the
primary physics of BABAR,
and also a detailed design
with enough supporting
evidence to show how we
intend to meet all the
physics requirements
(including those for
auxiliary events).
end of
March
Eng Run within an online
test stand of some kind.
Probably need much earlier
test at some level as soon
as OEP can run in a test
stand.
04/01/98
Eng Final benchmarks for
resource consumption.
Level 3 must be packaged to
run on several platforms and
delivering reliable resource
usage measurements.
04/10/98
Eng Further study of efficacy of
various filters using the
knobs for each trigger type
(e.g. charged two-prongs,
neutrals, etc.).
This process is iterative
and will certainly continue
past the PDR time-frame.
post PDR
Eng Develop configuration tools
for defining input lines in
conjunction with L1
configurations and for
validating them against a
set of rules.
This will be a part of L3
operation throughout physics
running.
post PDR
Eng Determination of rules for
validation of input line
definitions.
Needed as part of
overall validation of Level 3.
post PDR
Eng Final version input line
generator.
Incorporates what we learned
from previous two milestones
post PDR
Eng Digi production run. Create SVT and DCH digis
to facilitate algorithm
studies (produce from output
of the mixing run.)
post PDR

This page maintained by Larry Gladney (larryg@upenn5.hep.upenn.edu).
Last modified: Sunday Jan 25 14:48:42 EST 1998