Dear colleagues,
some very important requirements for MDC2 have been pointed out  after last common Dch Reco-Simu meeting and last MonteCarlo general meeting.
The relevant points  are summarized in the note of  Bill available in:
 /BFROOT/www/Computing/Offline/Simulation/web/mdc2.html
Bill has requested comments and/or changes to the list before the end of  this week.
In this mail I'll give some observations on these points and I'd like  to have a fast feedback to send the DCH point of view on this item.

• 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. Note that nder certain circumstances in the Geant step, a secondary will be assigned the same track number as the primary. This needs to be fixed.

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

Realism in detector response simulation:

• 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, we should start with a perfectly aligned detector in the Geant tracking step and misalign it in the digi step. This is most easily handled if your subsystem's geometry in XxxSim is based on DetectorModel.

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

Improved CPU and storage performance:

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

Improved data monitoring:

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