We need to assess the readiness of the detector simulation packages for MDCII and address the items which need work. In detector simulation, the priorities of MDCII are:

• Ability to exercise the event store database and obtain reproducible results in the process
• Realism in detector response, including the capability to
  1. Use detector calibration constants to introduce channel-to-channel variations and electronics noise
  2. simulate detector imperfections
  3. introduce Detector misalignment
  4. incorporate machine backgrounds
• Improved CPU and storage performance
• Improved data monitoring

I/O to the event store database:

• Generation of Digis: Each subsystem XxxSim package should be capable of accessing the GHits from bbsim and produce the corresponding detector response objects (Digis). The code producing Digis should should not be buried in the XxxReco code.
• Digi format: The contents of the simulated Digi should be the same as for real data.
• Storage limitations: We want to avoid overrunning static arrays which depend on the number of Hits/Digis per event. Use extensible arrays or dynamic memory allocation instead. Need to be able to work with X10 backgrounds without crashing.
• Monte Carlo truth: The original Monte Carlo track number should be retained in the GHit. Then for each Digi, there should be a list of contributing GHits.
• Reproducibility: Can the same Digi be obtained by reading event N from the .xdr vs processing the N-1 previous events first ? Recomendation is to use a common underlying random number engine which is seeded from the random numbers stored in the .xdr header file. For C++ code, this means CLHEP/Random/RanecuEngine classes, or for F77 code, gnrdm.

• Calibration constants: What types of calibrations are being planned ? Are the relevant constants available in the conditions database ? Can they be used to produce smeared Digis ? Example: In the Emc, Noise (in MeV) = noise (pedestal width in channel counts)/light yield(channel counts/MeV). Each of the quantities on the RHS can be obtained from calibration constants in the conditions database.
• Geometry constants and misalignment capability: To test our ability to align the detector in MDCII, I propose that we simulate a perfectly aligned detector in Sim and misalign it in Reco.
• Timing: At the digi level, the level 1 accept (L1A) time should be obtained from the L1FctData package. The FcsSim package should be used to obtain the Fast Control and Timing clocks.
• Inefficiencies and false hits: How are these being modelled in your subsystem ?
• B-field: Nonuniform B-field. The package BField contains a field map which has been shown to obey Maxwell's equations.

• Timing benchmarks/subsystem on bbsim and xxxSim stage: Need to resurrect the timing capabilities in bbsim. Systematic timing studies should be performed for XxxSim code in order to determine which code should be optimised (in general there is a trade-off between realism and speed. Which areas in the simulation can be sppeded up without an appreciable loss in realism).
• Event sizes: How many words are being written/subsystem onto the .xdr file? Is it possible to write a filter module at the front end of the digitization step to eliminate GHits which could not possibly contribute to the response of the detector during integration time following the level 1 accept for each subsystem ?

• QA histograms for gn* packages Need to define a small number of histograms (not Ntuples) which for each subsystem, can be written to a Zebra file (one directory/subsystem), monitoring the quality of the GHits. Want to restrict the size of this file to be small compared to the .xdr file. No Ntuples!

See the Digi page in simulation for an overview of Digitization readiness.