BaBar Reconstruction Task List

1. For Mock Data Challenge 2
2. For Mock Data Challenge 2 prime
3. Preparation for 1998 Cosmic Commissioning
4. Preparation for 1999 PEP-II Data
5. Understanding the first 1999 PEP-II Data

In the words of the winged goddess of victory: "Just do it"

Recent Changes

• 27 May, 1998 -- Update MDC2prime (Bob)
• 26 May, 1998 -- Add checkmarks to MDC2, moved defered items to MDC2prime (Bob)
• 23 April, 1998 -- Add checkmarks to MDC2 (Bob)
• 14 April, 1998 -- Explicitly add MDC2 prime (Bob)
• 17 Mar, 1998 -- Add to EMC wish list (Bob)
• 20 Feb, 1998 -- Add info to cosmic phase (Bob)
• 27 Jan, 1998 -- Update MDC2 DCH (Bob)
• 23 Jan, 1998 -- Update MDC2 SVT, EMC, DRC (Bob)
• 21 Jan, 1998 -- Comm.reco.mtg update sim needs, cosmic prep, DRC graphics (Bob)

For Mock Data Challenge 2

In priority order, the emphasis of Mock Data Challenge 2 is:

1. Integration of the event store
2. Dealing with a realistic detector, including
   1. Detector calibration
   2. Detector imperfections
   3. Detector alignment
   4. Machine backgrounds
3. Increased physics functionality

Unfortunately, our limited manpower means that we will make much less progress on the first two of these than we would like. In particular, we would like to have a complete set of persistant event and calibration/alignment data, plus rudimentary calibration and alignment code. This would give us a good foundation on which to build the detailed algorithms needed for the cosmic running. Unfortunately, we're going to have to settle for less, and try to make up the difference before cosmics.

In the absence of the manpower to do this, we have to set more limited goals for MDC2, and attempt to make this up in later stages.

As we complete MDC2 preparations, we have started to mark items with icons. Unlabelled items are still being worked on.

• Done as planned
• Partially done, partially not done
• Not done as planned, deferred to later

Common & general

• Rationalize _all_ Digis to common form, at least the persistant parts, and make them consistent with hardware expectations. Have a written digi standard for MC association, etc.
• Physics 'filtering' support has to become 'tagging' support using the database
• Add physics modules to the standard reconstruction jobs. They will provide modules for creating various event summary objects, and to do tagging.
• Do production bug testing on all four supported architectures to the 50K event level (status: two not done, MDC2 will be run on Sun and OSF only)
• Split the offline executables into "simulation" and "reconstruction" jobs. The "reco" executable must be available in a version that does not use DbiEvent large common blocks
• Have merged/mixed backgrounds as normal part of development. Specifically, have X1, X3 and X10 MC samples available in the event store, and have at least X1 being routinely used for development. (status: only X1 will be available at first)
• Prompt reco "data stream calibrations" need to be defined, and must be compatible with defined capabilities in prompt reco
• Output (text and histograms) must be compatible with production group, OEP and Prompt Reco standards (status: we have draft standards, histos are acceptable, but we have not migrated the majority of the text output)
• If defined during January, unified support for PID "likelihoods" may be added as a goal; see specific system items. (status: definition finally complete in May, will write common code for MDC2 prime. Some systems are providing likelihood information in MDC2)

Desired items that will not be available for MDC2, unless additional manpower appears:

• Improved system-level documentation
• Dynamic linking, particularly of needed modules
• A complete set of regression tests (limited improvement is expected)
• A sweep through the code to reduce the level of spurious output, while increasing the debugging output available
• An interactive browser for event data, particularly one that works with the event store (perhaps integrated to the event display, but a lightweight standalone program would be more useful
• AppActions for debugging support, including checksumming the event, checking the malloc heap for problems, and resetting the cout formatting
• Detailed work on optimizing various aspects of the code for memory and CPU performance (status: some done, much more needed)
• Significant work on compressing data for the event store

Tracking

• alignment - relative alignment of SVT and DCH will be implemented, including code to find that alignment and diagnostic plots
• At least one bunch-finding algorithm will be implemented.
• The classes for distributing the results of the bunch finding will be implemented
• non-uniform B field will be in the MC production, and tracking finding and fitting will be done using it. Corrections may _not_ be perfect as of the start of MDC2, so some resolutions may still be degraded. But code for corrections will be present.
• Updated interface for kinematic fitting (status: this will not happen for MDC2)

• Small improvements in pattern recognition (status: some done, much more needed)
• kink-finding, which might require some changes in the way analysis is done
• Consistent, accurate, precise vertex fitting.

SVT

• SvtMakeClusters <--> SvtHitReco swap
• Removal of support for old SvtSim/SvtReco numbering convention
• Detailed use of defect info in clustering, including assignment of errors
• Migration of SvtElectronics ganging/bonding info to layout file
• Conditions database/Objectivity: Persistent classes for ganging/bonding info, defect info
• Quantification of degradation due to 'realistic effects'
  Several things, some already started: performance in presence of machine background, performance with more realistic inefficiencies (as well as the electronics simulation changes above). Here one could also look at the efficiencies from the point of view of physics (reconstruction of slow pions for example), but this is not guaranteed for MDC2. (status: efficiency and BField work done, but not the machine backgrounds)
• Alignment
  • DetectorModel used for all geometry, allowing alignment
  • Demonstrate ability to find global alignment constants, at least to coarse accuracy
• Calibrations:
  • At least one SvtElectronics class, perhaps to handle ganging bonding, will be stored to and retrieved from the conditions database
  • The SvtElectronics electronics calibrations will be integrated into the reconstruction
• Svt part of GraDisplay
  • SVT display updates integrated into GraDisplay application
  • Display geometry
  • Display HitsOnTracks
• Likelihoods
  SvtPidInfo will provide Gaussian likelihood information
• SVT datastream calibrations for global alignment will be shown to be consistent with prompt reco capabilities and calibration classes.

Longer term projects; work on these will continue, but it is not planned that they will be done on the MDC2 timescale.

• Optimizing SVT-only track finding in the presence of various levels of backgrounds
• Adding SVT hits to DCH tracks
  Although this was on Pete's SVT wishlist, it could also go on tracking or DCH lists, or the physics wishlist. Perhaps some very limited capability could be done for MDC2, but there will be no need for this in cosmic running
• New trackfinder
  --> Gerry has pointed out in the past that this might be rewritten, but it is a big project and might take a while to get it up and running. Maybe we could at least get a 'requirements' type document together. Maybe some numbers on efficiencies can also be produced from the point of view of physics (ie for slow pions for example)
• Updating SVT PID to use merged-track momentum information when available

DCH

• Separate MC and reco functions as part of a general code cleanup
• Integrate FCS and selected-bunch information into the reconstruction
• Event store - make DchGHit, DchDigi, DchDigiMC, DchPidInfo persistant. Make DchHit persistant if required by tracking design.
• Alignment
  Implement the ability to move the DCH globally, and the sense wires internally.
• Calibration:
  Time-to-distance calibration is expected. dE/dx calibration is not expected until later (status: T-t-D is late, expected before MDC2prime)
• DCH part of GraDisplay
  Draw hits, hots, wires and the various types of tracks
• Likelihoods
  (BobJ - this is here as a placeholder. By mid February we are supposed to have worked out what and when for likelihood PID information, at which time this will be updated)
• If the DCH is planning to do datastream calibrations in prompt reco, those plans should be shown to be consistent with prompt reco capabilities.

DRC

• Integrate FCS and selected-bunch information into the reconstruction
• Event store
  DrcPidInfo, DrcTrack, hits and related information will be persistant. Caching will be implemented to reduce read-time overhead when only the consistency values are required.
• Alignment
  The existing bar alignment code will be updated and interfaced to the calibration database, using the calibration classes for storage
• Calibrations:
  T0 phototube calibration will be done
• DRC part of GraDisplay
  • displays of (all or selected) Dirc tracks, associated hits and hit bars
  • displays of unassociated hits
  • displays of equatorial projection of a selected track (including error representation and "nearest solutions" underlined).
  • display of the expected rings
• Likelihoods
  (BobJ - this is here as a placeholder. By mid February we are supposed to have worked out what and when for likelihood PID information, at which time this will be updated)
• DRC plans to do datastream calibrations of T0 in prompt reco should be shown to be consistent with prompt reco capabilities and calibration classes.
• Further study of performance of association and fitting algorithms, resulting in selecting a default set for MDC2

Desired, but not committed to:

• A study of backgrounds due to muons in the SOB should be completed
• use the display for testing the alignment procedure.

EMC

• Integrate FCS and selected-bunch information into the Digi creation. This includes the necessary redefinition of Ghit and Digi objects. (Actually a sim resposibility)
• Event store - All EMC classes will be persistent on the MDC2 timescale.
• Alignment
  DetectorModel will be used for all geometric information
• Calibrations:
  • Implement mechanisms to apply crystal and cluster calibrations for photons and pi0s
  • Apply a first single-particle-MC calibration. This is intended as proof of concept, not a final calibration (e.g. will likely not improve the pi0 mass significantly)
  • Demonstrate use of (MC) non-radiative Bhabhas for finding crystal calibrations
• EMC part of GraDisplay
  Hit crystals will be visible via the "lego cluster" display, as will processed cluster positions.
• Likelihoods
  Existing support for generating PDF of energy distribution will be made compatible with any adopted proposal for handling likelihood information (status: will be done on MDC2prime timescale. Green check because of date of proposal adoption)
• Data stream calibration of cluster energies will be shown to be compatible with calibration classes and prompt reco architecture, but code is not expected to be available for the start of MDC2
• Photon ID, down to "medium energy"
• Improvements to electron ID using shower shape variables (and maybe NN?) in conjunction with E/p
• Angular dependent energy and position corrections for photons (at least)
• Track matching based on DetectorModel (i.e. to crystals, rather than some surface losely representing the inner surface of the EMC)

Items that will continue to receive effort as available, but which are not assured for MDC2 availability:

• Non-merged pi0s
• Rather better track matching than at present (possibly particle dependent)
• Handling of split offs.
• Improved low-energy photon identification
• Demonstrate use of (MC) radiative Bhabhas and kinematic fitting to create a photon sample for finding crystal calibrations
• Reconstruction of cluster timing information, and use for machine background rejection
• Working with tracking on Bremstrahlung-kink-finding and use of albedo tracks.
• Pair finding (photon conversions)

IFR

Because the IFR will be taking cosmic data as early as April, it has to be treated somewhat differently. The first three items on this list are therefore "early cosmic running" items. This list is still very preliminary, pending IFR group meetings during the week of January 15, 1998.

• Integrate FCS and selected-bunch information into the reconstruction. This includes any necessary redefinition of Digi objects.
• Simple IFR-only track finder for cosmic use
• Readiness for early cosmic ray running:
  • electronic channel<->strip mapping
  • check and correct RPC geometry according to "real detector"
  • ad hoc input module for test data
• IFR T0 finder
• List of objects to be put in the Event Store by MDC2:
  • IfrDigiLayerCluster, IfrDigiStrip
  • IfrComposite, Ifr2DCluster, fr3DClusters
  • NeutralHad
  • IfrPidInfo (charged, neutral)
  • SwmTrack
  • SwmTraj
• Alignment:
  1. align chambers within 1 sextant with cosmic rays (MC and/or real data)
  2. output constants to DB
  3. read-out alignment constants and fit cosmic tracks
  4. compare fit residuals to show improvement
• Calibrations:
  • measure RPC layer effciency/multiplicity with cosmic rays
  • measure RPC layer effciency/multiplicity with ad hoc data (muon pairs?)
• 2D, 3D clusters in IFR part of GraDisplay
• Add swum tracks to event display
• Likelihoods
  (BobJ - this is here as a placeholder. By February we are supposed to have worked out what and when for likelihood PID information, at which time this will be updated)
• If the IFR is planning to do datastream calibrations in prompt reco, those plans should be shown to be consistent with prompt reco capabilities.
• K0L-ID:
  • Complete the neutral part of the IFR Pid ( IfrNeutralPidInfo )
  • NeutralHadSelector in PidTools

• Muon-ID:
  improvement in mu/pi separation is expected using the swimmer (See Antimo studies).
• K0L-ID NeutralHadSelector in PidTools
  • perhaps provide a consistency for (n,n-bar,K0L)?
  • perhaps provide E measurement?

Level 1 Trigger

• Event store
  Only Digis need to be made persistent from Level 1 Trigger. All of them will be, starting with TSF digis. The complete set includes the L1(Tsf/Blt/Ptd/Emt/Glt/Fct)Digi classes.
• The L1 Trigger is planning to use datastream calibrations in prompt reco to track the XY beam position. Those plans should be shown to be consistent with prompt reco capabilities. (status: not considered a priority by trigger group, will be deferred to cosmic prep)

• L1 Trigger-specific views in the one-event display

Level 3 Trigger

• Event store
  (BobJ: MDC2 requires that GHits, Digis, and output objects "to the Beast level" be placed in the event store. It would be desirable to have further information recorded. A demonstrable goal needs to be written down)
• Alignment
  (BobJ: Is there alignment for the L3 trigger? If so, MDC 2 requires the ability to change all the global alignment, and at least one internal alignment constant. We need to confirm what's needed and get a demonstrable goal written down)
• Calibrations:
  (BobJ: MDC 2 requires that at least one calibration be implemented, so one should be selected and a demonstrable goal written down. Are there any from L3?)
• L3 Trigger part of GraDisplay
  (BobJ: may be already done, but needs a demonstrable goal written down)
• If the L3 Trigger is planning to do datastream calibrations in prompt reco, those plans should be shown to be consistent with prompt reco capabilities.
• Gregory has suggested the goal "defining L3/OEP output objects", including any bunch-finding information, etc.

Graphics

• Integration of system-specific improvements
• Have completed tutorial/reference available on the web. Have the web site linked from computing home page and the PRS forum home page. Include clear, example-driven instructions for adding new representations and projections. (Determination of clarity made by (i) surveying users and (ii) seeking graphics-group consensus).
• Maintain a listing of status of the Gra... executables in BaBar releases at SLAC.
• Improve user feedback on mouse/menu actions. Make window/menu/item names more intuitive. (Determination of success on this item by (i) surveying users and (ii) seeking graphics-group consensus). Note this is a limited scope, one time update.
• Introduce DrcGra into release scheme
• Research questions on client-server, other schemes for graphics. Be ready to make a decision on whether to proceed with such scheme and to plan attack if we proceed. (Group consensus)
• Remove CodeWizard complaints from GraBase and GraModel.
• Add persistance of window control.
• Improve modularity of code design. Better separate model from visualizer. This is important for the display as it stands, but would also be helpful for adopting any new system.

Wishlist items, on which progress will proceed as time is available, but not guaranteed to be ready on MDC2 timescale:

• Addition of solid shapes
• Add a representation editor.

Beta

• Access to BtaCandidates from the event store (status: BtaCandidates from the event store can be loaded using the usual input module forms. But this item was intended to allow users to directly invoke the BdbConvertors, so its only partially complete.)
• Access to tag and summary data from the event store (status: Tag and summary data from the event store can be loaded using the usual input module forms. But this item was intended to allow users to directly invoke the BdbConvertors, so its only partially complete.)
• Common form for PID selectors
• Common form for PID algorithms
• Common form for composite particle generators (status of this is not clear. In particular, there is a physics tools group that is working on it)
• Error/covariance matrices on Candidate 4vectors, including error calculations for derived quantities
• Update vertexing and fitting interfaces to work with tracking changes
• Filter -> tagging interface changes
• Ability to hide & restore MC truth via keyed access
• Inclusion of those algorithms and modules provided by the physics and/or reco groups, perhaps including
  • EventInfo updates
    • Primary vertex (physics)
    • Beam spot (found)
    • Event shape variables (momentum flow & spatial)
  • Common selection modules
    • for PID
    • for composite particles such as J/psi or K0S
    • for vertex finding
  Note that these must be provided in time and in a coordinated form.

Items which are requested, but we currently don't have the manpower to promise. Many of these are very, very good ideas.

• Actually creating the algorithms & modules mentioned above.
• Provide a ProxyDict or similar mechanism for attaching arbitrary user information to a candidate
• Program to load 4.3.2 Beast tapes to the database
• Production support for rerunning all the new simulations into the database.
• Additional tutorials & docs, particularly at the advanced level.
• Adapter to still read 4.3.2 Beast tapes.

Needs from simulation for MDC2

• All systems will need to use timing information (FCS) to create realistic digis.
• All Digi-generation code must work to X10 background
• All created digis are supposed to be consistent with what the electronics will be producing.
• All aspects of simulation are to be reproducible, in the sense that you get the same results for event N if you run it by itself, or run it after all the N-1 events.
• For tracking:
  • Inefficiencies in both Svt and Dch
  • electronic noise in Dch
  • merged bkgds in SVT and DCH
  • non-zero trigger time; New code will be required for the Dch.
  • Realistic non-uniform B-field model.
• For SVT:
  • Conversion of SvtSim to use SvtGeom/SvtElectronics
  • conversion of bbsim to 'correct' wafer spacings
  • Improvements to electronics simulation (offset spreads/gains/???)
• For EMC:
  • Update EmcSim to use and create timing information in Digis
• For IFR:
  • Introduction of inefficiencies and false hits
• For realistic physics:
  • Primary event (beam spot) displaced in space & time from 0,0,0,0

For Mock Data Challenge 2 prime

It is tentatively planned to simulate and reconstruct a larger number of events during September 1998 with new executables. These executables will be frozen at the beginning of August. A first proposal of schedule and scope has been posted to Hypernews. By the end of May, we need to have created more detailed task lists, etc, which will be posted here.

It is likely to include:

• Use of more severe machine backgrounds, up to and including X10
• Storage of the processing history of particular events & processing runs
• Tests of "reprocessing in place"
• System-level support for PID likelihoods. (Moved here because its requirements definition was too late to make the MDC2 update.)
• Beta-level access to individual event store items. (MDC2 wishlist item, insufficient manpower)
• Physics-provided updates to the sequences for generating Tag, composite, etc, objects. (Needed for realistic volume tests)

• Likelihood update, PID architecture update
• Likelihood all systems
• CLHEP update to be common with CERN
• Beta access to BdbConvertors

• PID sequences to be run in production for selection of identified lists of e/mu/pi/K/p, neutral particles?
• Any desired updates to primary vertex finding, secondary vertex finding, etc
• Any desired composite particle generators (D, D*, J/psi) that should be run in production
• Selection of samples of events:
  • mu pairs, tau pairs, etc
  • qqbar vs ccbar vs bbbar
  • Analysis-specific tagging (filtering), some from MDC1 and some new

Common & general items deferred from MDC2

• Physics 'filtering' support has to become 'tagging' support using the database
• Do production bug testing on all four supported architectures to the 50K event level
• Have merged/mixed backgrounds as normal part of development. Specifically, have X1, X3 and X10 MC samples available in the event store, and have at least X3 being routinely used for development.
• Output (text and histograms) must be compatible with production group, OEP and Prompt Reco standards

Desired items that will not be available for MDC2prime, unless additional manpower appears:

• Improved system-level documentation
• Dynamic linking, particularly of needed modules
• A complete set of regression tests (limited improvement is expected)
• A sweep through the code to reduce the level of spurious output, while increasing the debugging output available
• An interactive browser for event data, particularly one that works with the event store (perhaps integrated to the event display, but more usefully a lightweight standalone
• AppActions for debugging support, including checksumming the event, checking the malloc heap for problems, and resetting the cout formatting
• Detailed work on optimizing various aspects of the code for memory and CPU performance
• Significant work on compressing data for the event store

New items:

• Implement written digi standard for MC association, all systems.
• All reconstruction and production analysis must run without GHits present
• Underlying support for likelihood in ProbTools, and Pid base classes

Tracking

• Updated interface for kinematic fitting

• Small improvements in pattern recognition
• Add SVT hits to DCH tracks
• kink-finding, which might require some changes in the way analysis is done
• Inclusion of found bremstrahlung photons
• Consistent, accurate, precise vertex fitting.

SVT

• Calibration object update, particularly for handling bonding imperfections
• Check efficiency & PID after simulation is updated to reflect electronic results

Longer term projects; work on these will continue, but it is not planned that they will be done on the MDC2 timescale.

• Optimizing SVT-only track finding in the presence of various levels of backgrounds
• Adding SVT hits to DCH tracks
• Updating SVT PID to use merged-track momentum information when available

DCH

• Sequence cleanup
• Separation of the finders and fitters from the base class packages
• Alignment
  Implement the alignment code for the sense wires, both to move them, and to find out where to move them to
• Calibration:
  Time-to-distance calibration is expected. dE/dx calibration is not expected until later

DRC

• Report on sensitivity to measured backgrounds
• Likelihood update

Desired, but not committed to:

• A study of backgrounds due to muons in the SOB should be completed
• use the display for testing the alignment procedure.
• Calibration procedures to check quartz transparency and reflection coefficient using cosmics

EMC

• Likelihoods
  Existing support for generating PDF of energy distribution will be made compatible with adopted proposal for handling likelihood information
• Data stream calibration of cluster energies code that is compatible with calibration classes and prompt reco architecture will exist
• Simple non-merged pi0s
• Updates to PID algorithms for pi0, photon, electron

Items that will continue to receive effort as available, but which are not assured for MDC2 availability:

• Better non-merged pi0s
• Rather better track matching than at present (possibly particle dependent)
• Handling of split offs.
• Improved low-energy photon identification
• Demonstrate use of (MC) radiative Bhabhas and kinematic fitting to create a photon sample for finding crystal calibrations
• Reconstruction of cluster timing information, and use for machine background rejection
• Working with tracking on Bremstrahlung-kink-finding and use of albedo tracks.
• Pair finding (photon conversions)

IFR

Because the IFR will be taking cosmic data early, it has to be treated somewhat differently.

• Readiness for early cosmic ray running:
  • electronic channel<->strip mapping
  • check and correct RPC geometry according to "real detector"
• IFR T0 finder
• List of objects to be put in the Event Store by MDC2:
  • SwmTrack
  • SwmTraj
• Alignment:
  1. align chambers within 1 sextant with cosmic rays (MC and/or real data)
  2. output constants to DB
  3. read-out alignment constants and fit cosmic tracks
  4. compare fit residuals to show improvement
• Calibrations:
  • measure RPC layer effciency/multiplicity with cosmic rays
• Add swum tracks to event display
• Likelihood update
• K0L-ID:
  • NeutralHadSelector in PidTools

• Muon-ID:
  improvement in mu/pi separation is expected using the swimmer (See Antimo studies).
• K0L-ID NeutralHadSelector in PidTools
  • perhaps provide a consistency for (n,n-bar,K0L)?
  • perhaps provide E measurement?

Beta

• Ability to request specific BtaCandidates from the event store, via appropriate AbsEvent proxies
• Direct access to tag and summary data from the event store from Beta, without need to load between modules
• Update for new PID architecture, esp. removal of deprecated AbsPid forms
• Common form(s) for composite particle generators
• Another update of algorithms and modules provided by the physics and/or reco groups, to be provided in time and in a coordinated form.
• Improved interface for creation of MC truth BtaCandidates
• Update of BtaCandidate access to multiple reco objects, including better documentation
• Persistance of non-candidate objects, including EventInfo, vertexing candidates
• Direct access to daughters, mothers. Deprecate the iterator form. Return non-const pointers.

Items which are requested, but we currently don't have the manpower to promise. Many of these are very, very good ideas.

• Support for use with Fast Bogus
• Provide a ProxyDict or similar mechanism for attaching arbitrary user information to a candidate
• Production support for rerunning all the new simulations into the database.
• Access to map info in Event
• Additional tutorials & docs, particularly at the advanced level.

Needs from simulation for MDC2 prime

Items present in MDC2, but that we still need to have working correctly

• All systems will need to use timing information (FCS) to create realistic digis.
• All Digi-generation code must work to X10 background
• All created digis are supposed to be consistent with what the electronics will be producing.
• All aspects of simulation are to be reproducible, in the sense that you get the same results for event N if you run it by itself, or run it after all the N-1 events.
• For tracking:
• For SVT:
  • Update for consistency with measurements of electronics performance
• For EMC:
  • Update EmcSim to use and create timing information in Digis
• For IFR:
  • Introduction of inefficiencies and false hits
• For realistic physics:
  • Primary event (beam spot) displaced in space & time from 0,0,0,0

New items

• For realistic physics:
  • Event boost displaced from Z axis to correct direction

Preparation for 1998 Cosmic Commissioning

Priorities are:

1. Prepare to reconstruct cosmic data to the level needed to understand the detector _during_ the run. Its important that we get as much progress as possible during the run, and that we record good data for study during the roll-in period.
2. Demonstrating integration with:
   1. Event and conditions databases, particularly for processing real data and using online calibrations & conditions
   2. Online event processing
   3. Prompt Reconstruction
   These demonstrations should take place before cosmic running, so that the same operations can be tested in realtime with the data. The cosmic run is our only chance to do this before real data arrives.

As yet, the task list has not been broken out by specific systems. This will be done in a planning exercise in May of 1998, in advance of the end of the prior phase. The following list will form the basis of that.

• Full reconstruction storage to the event store, including demonstrating reprocessing (full and partial)
• Confirming as many calibrations as we can with cosmic data (What are these? We need to make a list by system)
• Demonstrating whatever PID distributions we can
• Develop selection modules for cosmic subsamples
• Selecting good samples for various studies?
• T0 processing and checking
• Have processing and reprocessing jobs ready for cosmic data
• Prove out the prompt reco connection, including logging. This includes having at least one system implementing a "prompt reco calibration" using standard classes, etc.
• Have simulated digis for any special commissioning hardware, including scintillators, etc.
• Create selection filters for "good" cosmics of various forms.
• "Detector OK" modules using conditions data
• Standard jobs for "IFR straight tracks", "DCH straight tracks", "field on tracking", "full tracking with trigger inputs"
• Support and update analysis tools that will be needed during the cosmic run, including getting documentation up to date
• Improve CPU and memory performance to the level needed for the expected cosmic data sample size
• Add event-store compression to the digi (and perhaps GHits) so that we are storing "final" format.

In the following, we'll accumulate specific tasks. We don't expect to close this until June 1998.

• Common
• Tracking
• SVT
  • Local alignment as needed for their standalone cosmics
  • If needed, as standalone tracker update
  • Integration of construction survey and construction database info
• DCH
  • dE/dx calibration
• DRC
• EMC
  • Demonstrate global alignment finding (deferred from MDC2)
• IFR
  • See also first few MDC2 items, due to timing of IFR cosmic start
• Trigger

Level 1 Trigger

• The L1 Trigger is planning to use datastream calibrations in prompt reco to track the XY beam position. Those plans should be shown to be consistent with prompt reco capabilities.
• L1 Trigger-specific views in the one-event display

Preparation for 1999 PEP-II Data

Priorities are not yet discussed, but will be something like:

1. Complete integration for running
   • Prompt Reconstruction
   • Online event processing
   • Event and conditions databases, particularly for processing real data and using online calibrations & conditions
2. Complete calibration and alignment preparations (to planned level)
3. Complete development with background (currently scheduled for earlier, but likely to be delayed)
4. Develop data selection, integrate whatever physics tools are available
5. Support physics ramp-up

As yet, the task list has not been broken out by specific systems. This will be done in a planning exercise in October of 1998, well in advance of the end of the prior phase. The following will form the basis of that.

• Have physics filters and algorithms installed and tested
• Generating data samples for specific particles for calibration, etc.
• Confirming as many calibrations as we can with cosmic data (What are these?)
• Selection of various composite decay samples
• demonstrating whatever PID distributions we can
• selecting good samples for various studies?
• T0 processing and checking
• Have processing and reprocessing jobs ready for PEP-II data
• Prove out the prompt reco connection, including logging
• Reconstruction access to full set of conditions data
• Access to monitoring data for real "subdetector OK" modules
• Support and update analysis tools that will be needed for initial data, including getting documentation up to date.
• Improve CPU and memory performance to the level needed for the expected initial data rate and sample size
• Add event-store compression to reco output so that we are storing "final" format.

In the following, we'll accumulate specific tasks. We don't expect to close this until October 1999.

• Common
• Tracking
• SVT
• DCH
• DRC
• EMC
• IFR
• Trigger

Level 3 Trigger

• Event store
  (BobJ: A demonstrable goal needs to be written down)
• Alignment
  (BobJ: Is there alignment for the L3 trigger? We need to confirm what's needed and get a demonstrable goal written down)
• Calibrations:
  (BobJ: Are there any from L3?)
• L3 Trigger part of GraDisplay
  (BobJ: needs a demonstrable goal written down)
• If the L3 Trigger is planning to do datastream calibrations in prompt reco, those plans must be consistent with prompt reco capabilities.

Understanding the first 1999 PEP-II Data

General goals / problems

• Demonstrate specific distributions from systems
• Generating data samples for specific particles for calibration, etc.
• Selection of various composite decay samples
• demonstrating whatever PID distributions we can
• selecting good samples for various studies
• T0 processing and checking

We have to simultaneously push on both single system performance and cross-system operations (tracking, etc).

In the following, we'll accumulate specific tasks. We don't expect to close this until January 1999.

• Common
• Tracking
• SVT
• DCH
• DRC
• EMC
• IFR
• Trigger