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