Summary of the Simulations Working Group

CZero Workshop - December 4-6, 1996

Co-Convernors: Amber Boehnlein (Fermilab), Rob Kutschke (Fermilab)

This document summarizes the presentations and discussions which took place in the Simulations Parallel Session at the C0 Workshop.

Postscript versions of the session talks are available at

1. Agenda 

Thursday, Dec. 5, 1996.  9AM to Noon

Introduction             - Rob Kutschke/ Amber Boehnlein 10

Beam Simulations         - Alexandre Drozhdin            30 + 10

MCFAST Overview          - Rob Kutschke/ Amber Boehnlein 20 + 10
      +Tracking

MCFAST Future Tracking   - Martin Lohner                 20 + 10

MCFAST Calorimetry       - Paul LeBrun                   20 + 10

Trigger Simulations      - Kevin Sterner                 20 + 10



Friday, Dec. 6, 1996. 9AM to 10:30

B Production             - Marc Baarmand                 30 + 10

Phyics Backgrounds       - Owen Long                     30 + 10

2. Simulation of Machine Backgrounds

Alexandre Drozhdin presented an overview of the types of beam backgrounds that exist in the Tevatron and the tools that are used to model those backgrounds.

  1. Proton-antiproton collisions are simulated with DTUJET93
  2. Beam halo interactions with scrapers and particle tracking through the Tevatron are modelled with STRUCT
  3. Particle loss induced hadronic and electromagnetic showers, and secondary particle transport in accelerator and detector components, including shielding, are done with MARS.

This suite of tools was used to optimize the position of a new shielding wall at D0 to counter beam backgrounds. Moreover the simulation also showed why the existing shielding wall was not adequate.

For C0, four types of beam background should be studied:

  1. Background originating from the halo particles in the final triplet of quadrupoles upstream of the interaction point
  2. Background from pbar-p collisions
  3. Background from halo particles passing through the detectors
  4. Background from inelastic beam-gas interactions

Conclusion:

Adequate tools exist for simulating machine related backgrounds in C0. This needs to be completed before the triggering simulations can be deemed mature.

3. MCFAST

Rob Kutschke, Amber Boehnlein, Paul Lebrun and Martin Lohner summarized the current status of McFast and gave an overview of development plans. Additional information can be found at the MCFAST home page.

MCFAST was conceived as a tool for designing a heavy quark experiment at a hadron collider, with emphasis on the tracking, vertexing and triggering subsystems. Since that time some additional functionality has been added, making it a more general tool for studying detector design.

In order to facilitate studying design changes, the detector configuration is specified in an ASCII file. The tracking code in MCFAST does a hit level simulation, which is based on individual device resolutions and which includes multiple scattering, executing quickly enough to process millions of events per design cycle. "Individual device resolutions" are, for example, the spatial resolution of a point in a pixel detector or the drift distance resolution in a drift chamber.

One motivation for developing MCFAST was the recognition that realistic B physics experiments at a hadron collider would require large background suppression factors and therefore could require that O(10e6) background events be simulated in a complete design cycle. This requirement sets the speed scale for a useful simulation tool for such an experiment, a scale that a GEANT based simulation cannot meet.

The original vision of MCFAST included the simulation of charged particle tracking, triggering and vertexing. Since that time, the scope has been expanded to include simulations of calorimetry and of particle ID; these simulations, however, are higher level parameterized simulations, not the hit level simulations which are performed for tracking.

At the C0 workshop several widespread misconceptions about MCFAST surfaced. These appear to arise from two sources: first, the capabilities of MCFAST have changed with time; and second, there have been some problems due to different understandings of the use of the word "parameterized". In order to clarify the status of MCFAST, a history and the development plan will be given.

The original MCFAST (v1.4 1994), was a wrapper around the SLAC TRACKERR program. After some initial experience, TRACKERR was found to have insufficient flexibility in its geometry and magnetic field representations. MCFAST (v2.1, 1995) was rewritten completely, retaining the essential algorithm of TRACKERR but supporting much more flexibility in detector design. The details of the algorithm, common both to TRACKERR and MCFAST, is given in Appendix A. The output of this algorithm is a simulation of the track parameters and covariance matrix, including both the effects of measurement errors and the effects of multiple scattering.

This approach had three significant weaknesses. First, the hits all lie on an ideal trajectory and, therefore, are not an adequate input to a trigger simulation. Second, there is no simulation of errors in pattern recognition. Thirdly, there are no non-gaussian tails in any of the hit resolutions.

Recently MCFAST (v2.5.1 1996--in beta test) was modified to implement explicit multiple scattering during the outward trace and hit generation step. MCFAST is now an adequate tool to produce the input for a trigger simulation. This test version was used for the detailed trigger simulations presented at this workshop.

Ongoing work, begun in fall 1996 and scheduled for completion in early 1997, includes,

  1. For technical design reasons, the new multiple scattering code does not work in a detector which has both central and forward tracking elements. As part of a larger project, described below, Martin Lohner will remove this limitation.
  2. Rob Kutschke has begun new work on the hit bookkeeping and the Kalman filter code; this work will allow for the simulation of pattern recognition errors and for the simulation of device misalignment. See Appendix B. for further details.
  3. Non-gaussian tails in the measurements will also be implemented in this release

Geometry:

The geometry is specified in an ASCII file. This makes it quick and easy for the user to specify a new detector design and to study variations on that design.

Calorimetry:

Calorimetry is supported for projective tower geometries shapes like tubes and cones. The parametric simulation includes the fluctuation of the conversion point and the longitudinal and lateral spread of the showers. Muons and hadrons (before converting) behave as minimum ionizing particles. Energy is deposited in the calorimeter towers and smeared according to a resolution function.

Future Developments

Martin Lohner discussed some of the future MCFAST tracking development work which was alluded to above. The choice of FORTRAN with no dynamic memory allocation has led to a lack of robustness in the detector specifications as well as pointlessly large and wasteful executables. The current geometry structures take up 10s of MBtyes when only 100s of KBytes are needed. Classes and structures have been defined and are being implemented in C++, with a FORTRAN binding being supplied. The initial implementation will be available for testing in early 1997.

This re-implementation of the MCFAST tracking algorithm as well as a proposed re-implementation of the calorimeter algorithm in C++ may fit nicely into the GEANT4 framework to supply users with fast algorithms as well as full GEANT simulations.

A final comment:

Always remember that MCFAST is designed to be a tool for understanding broad detector design issues and some selected detailed issues. It should be understood that MCFAST performs well within those limitations. It is the responsibility of the user to know if MCFAST is the appropriate tool for the problem at hand.

Discussion Following MCFAST Presentations

A discussion session followed the presentations in which 3 problems with MCFAST were identified:

  1. The existing muon simulation is much too naive. Currently punch through is not modeled at all and pi/K decay in flight is always modeled as two distinct tracks. The solutions to these are straightforward and are on the MCFAST to-do list. These are certainly areas of MCFAST to which a volunteer could contribute.
  2. No simulation of RICH or other particle ID. Code to simulate particular detectors exists but is not interfaced to MCFAST. For C0 studies, the existing code should be put in MCFAST as user code, analogous to the the trigger code.
  3. The simulation of multiple interactions assumes all events are in the same bucket. This is an issue for the calorimeters in high pt detectors operating at in a multiple luminosity environment. This is not a C0 issue and is conceptually easy to fix.

4. Simulation of Triggers

Kevin Sterner discussed the implementation of a vertex trigger algorithm for C0/BTeV in McFast. As mentioned above, he used the version of McFast which fully incorporates multiple scattering and energy loss into the outward trace. The results of this work have been shown in the Trigger Working Group and the details of the algorithm and the results are not described here. It should suffice to point out that the algorithm does full pattern recognition, starting from the measured hits. The algorithm is impact parameter based and looks for topologies consistent with a displaced secondary vertex in the event. The code as implemented works within McFast and provides a trigger decision as well as a structure of trigger information. The code is fixed to a particular vertex detector structure, but the parameters and the details of the devices (like the thickness and spacing) can be varied.

5. Simulation of B Production

Mark Baarmand presented results on the simulation of B production in hadron collisions. The Mangano, Nason, and Ridolfi calculation (MNR) [Nucl. Phys. B373 (1992) 295] of the fully exclusive bbbar cross section extends to order(alpha_s^3) and provides distributions of correlations among b, bbar, and the light partons. Marc has converted the MNR calculations into an event generator, HVQJET, which is interfaced to ISAJET. ISAJET is used to simulate the initial and final state radiation, fragmentation and the underlying event. Marc also reported that a bug in ISAJET v7.13 caused a predition of too much gluon splitting. The bug was fixed as of v7.20. Marc is working to make HVQJET available to users.

The feeling of the participants in the session was that there were no known show-stoppers with the present and forseen event generators: PYTHIA, ISAJET, HERWIG, HVGJET. However we must reevaluate these codes as new information becomes available from CDF and D0 Run I data.

6. Physics Backgrounds

Owen Long described work done for a BCD study which analysed the background sources to Bd->pi+pi-. The studies used the BCD silicon vertex detector and assumed perfect pattern recognition, and include multiple scattering, nuclear interactions, and electromagnetic cascades. With the cuts chosen, and to the limit of available statistics, charm and light quark backgounds were not significant compared to the background from other b events. This work is summarized in: O.R. Long et al, Preprint numbers: SSCL/PP/139, UPR/216E (U. Penn.), Princeton/HEP/92-07. Owen also described CDF's Run II plan for triggering on B->pi+pi-.

Because this work was statistics limited, and because it was done at SSC energies, it needs to be redone for C0/BTeV. However the feeling in the room was that a new simulation was very likely to confirm the result that the principle background to B physics is other B physics.

Appendices

Appendix A. The Original MCFAST Multiple Scattering Simulation

This is the guts of the original MCFAST tracking code. The essential idea was taken from TRACKERR.

  1. Trace the track outward through the detector, following the vacuum trajectory; that is, there is no simulation of multiple scattering at this stage.
  2. Compute the intersection of this trajectory with each sensitive volume and compute the "measurement", for example the position, and its error, of where the track crossed a silicon plane. The output of this step is the generated hit list for each track.
  3. On this outward trace, store a sorted list of all of the materials through which the track passed. The arc length in each material is also stored.
  4. Apply a simple model of efficiency and smearing to the generated hit list. In this sense the simulation can be said to be parameterized: each generated hit has some device-dependent resolution associated with it and the smearing is done according to that resolution. At present tails in the resolution function are not simulated. ( Here a true, full simulation would simulate such things as pulse sharing in a silicon detector; once this is done clustering code is also needed. )
  5. The output of the preceding steps is an interleaved list of measurements and scattering surfaces.
  6. Use the list assembled in 5) as the input to a Kalman filter. Notice that this will include all of the scattering surfaces. The output of this step is a set of track parameters and their covariance matrix.
  7. Here is the critical point. In any track fitter, including a Kalman filter, the covariance matrix does not depend on the measurements! It only depends on the measurement errors, the amount of multiple scattering and the relative positions of the measurement points and the scattering surfaces. On the other hand, the track parameters do depend strongly on the measurements.
  8. So the covariance matrix created in 6) is very close to correct. The errors which are made are that the relative positions of the measurements and scattering surfaces are slightly off. It is an excellent simulation of the covariance matrix which would have been obtained by explicitly modeling multiple scattering in both the outward and inward traces.
  9. Of course the track parameters created in 6) are complete junk. So they are discarded and a new set of track parameters, chosen from the measured covariance matrix, is thrown. It is these track parameters which are reported to the user.
  10. The most significant weakness in the above scheme is that one cannot properly model pattern recognition. This enters at two levels:
    1. In the trigger. The cuts in the trigger algorithm must include allowances for:
    2. how does putting an incorrect hit(s) onto a track affect the determination of the vertex parameters of the vertex from which said track originates.
  11. A lesser weakness is the failure to model the following component of the "real life" resolution function. When a particle goes through the detector it traverses a particular set of scattering materials. When we reconstruct the track we also must build the list of scattering materials through which the track passed. Whenever a track passes near the edges or corners of some material, then the material list will be incorrect sometimes, either by omission of some material or by inclusion of some incorrect material. This is believed to be a negligible effect and, moreover, one which will tend to cancel in the mean ( but not in RMS ) in an ensemble of events.

Appendix B: Simulation of Pattern Recognition Errors

  1. The goal is to simulate the errors which attach incorrect hits on tracks.
  2. First, generate the correct hit list for all tracks.
  3. Sprinkle noise hits throughout the detector. The algorithm may be left as user code.
  4. Look for sets of tracks which have many close by hits. Invent some algorithm for distributing the hits on tracks. The important thing here is to understand the frequency with which this problem occurs. In practice these tracks are likely to be so poorly reconstructed as to be useless - so the details of the misassignments are of much less importance than getting the frequency of misassignment correct.
  5. Look at the remaining hits on tracks and look for true hits which have nearby incorrect hits. Occasionally the incorrect hits will be placed in the hit list and the correct hit removed.
  6. In the far distant future, one could imagine implementing true pattern recognition code. But this is unlikely on the time scale of mid 1997.

Back to Working Groups

Last updated 2/3/97 - M. Smith (oboe@fnal.gov)