Considerations extracted from February 4, 1998 DCH software meeting
I/O to the event store database:
- 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.
I'll verify that the track number stored in the GHits is the number of the current tracked particle and not the number of the mother.
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.
The conditions database will contain the parameters needed to convert time to distance and distance to time.
Information useful for the smearing of the Digis and to introduce electronic effects like pedestal, noise, .. will be available for MDC2.
We are not sure that DchSim will be able to include these effects in April .
- 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.
We agree in part with this point. We think that the best solution is to introduce the misalignments directly in bbsim, where the geometry is used to make the
hits. The Global misalignment is ready. Some local alignment like sectors of wire or single wire (both sense and field wires) directions may be well defined only in bbsim.
- Inefficiencies and false hits: How are these being modelled in your subsystem ?
We think that the model of false hits must be connected to the prototype results and/or the cosmic ray tests of the chamber (June, July ...) . It cannot be available for the start of MDC2 (April)
- B-field: Nonuniform B-field. The package BField contains a field map which has been shown to obey Maxwell's equations.
Follow some comments of Art Sneider
The magnetic field given by gufld (and hence by BFieldBbsim) is less than perfectly Maxwellian. It is much better than the
previous version, but both Bill Dunwoodie and I see violiations near r=0 and at boundaries.
I think we should use something better for MDC II.
A simple thing to do would be to use polynomial fit to current gufld; these are forced to obey Maxell exactly. This would entail
adding a polynomial option to gufld. It would be wise to also improve the bookkeeping so that field being used is recorded
some place; such as on the "tape" or in the data base.
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).
We've obtained a gain of 20% in bbsim using another tracking approch in the chamber.
In this new algorithm we've included the multiple scattering for directly crossed wire. The approach is ready and will be tested to be used for
MDC2.
- 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 ?
We think that the track finding efficiency is related to the hits found in the chamber then all the hits must be considered. In DCH the number of stored words is not so high to require a reduction.
We can consider a reduction of the number of words stored
in ghits, not all used in the digitization.
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!
A set of histograms has been already prepared, we will look to see if more informations will be useful.
|
