This proposal is the outcome of discussions with the core and subsystem software groups. The original discussion can be found in Traudl's note.
Note that peripheral discussions will ensue from the Hits proposal in the areas of geometry and the MC parentage. The Hits will depend on the geometry in that they must know what volumes they belong to. Similarly they must know who their parents are. But in both these cases, nothing in the Hits definitions places real constraints on the other two areas.
Two subsystems (TKR, CAL) have asked for detailed accounting of energy in dead materials and exiting the instrument. We may need to supply some flexibility to the scheme due to possible constraints on file sizes and CPU time to read them.
Hits: MC truth of energy deposition over a given arc length of step. The parent particle type is recorded and optionally the position of the step endpoint. [THB: particle type has to be defined in a general way -- I propose using the PDG scheme, with extensions for heavy nucleii. But maybe this means a pointer to particle object, which itself has a type.]
Digitizations: Translation of the total deposited energy in active media into an electronic readout.
We propose to notionally separate the instrument into 'CAL' and 'non-CAL' components. In any case, all volumes are marked as 'sensitive' to the simulation package (eg, Gismo, G4). Volumes will carry an additional flag indicating whether they are 'sensitive' for digitizations. [THB: In gismo, this is not a flag, but reflects the behavior of the Detector object that gets called back for each step.]
All steps(*) are recorded in all volumes; dE, position vector, volume name and MC parent are recorded per hit. The hits are recorded up to and including the termination point or exit from the world volume.
All steps until the particle interacts are stored, just as for the non-CAL volumes. Once the particle interacts, it is tagged as showering and all its daughters' contributions are assigned to this 'shower initiator'.
Summed energy (and volume ID and list of MC parents) is stored in these volumes. Classes of volumes can have additional information stored, specifically the length-wise position moments for the logs. We're assuming at the moment that only the logs need this additional information, but not restricting to them.
Shower particles that leave the CAL volumes (ie albedo) would become 'real' particles again in the MC list.
These latter two points have been described in an earlier proposal.
(*) - we need to study whether we would record all steps or just sum up step information within a single volume if only dE/dx occurred (prior to exit or termination).
Each MC particle would store a vector of their energy losses, positions and volumes crossed prior to interacting anywhere or leaving the world volume. This would account in detail for all energy loss in the instrument and that which leaks out.
The CAL would be treated differently, with a vector of energy sums per MC particle spanning the volumes in which energy was deposited by the shower. For at least the logs, the position moments would also be stored.
Note that this proposal only refers to volumes. We can tune the volume segmentation to optimize the spatial understanding of energy deposit (presumably balanced against resource costs). [THB: presumably volume segmentation is an allocation of deposited energy to sub-volumes of the volume known to the simulation, for example strips in the silicon, that must occur during the simulation phase, where details of the geometry are known.]
We may need to think more carefully about the bookkeeping for shower particles leaking out of the instrument. That could cause an avalanche of particles being recorded.
We may find that the depositions in dead materials become of moot interest after a while. We will build in an option to turn this off. Another thing to consider is whether the live and dead material records could be kept in separate Root branches in the persistent store. In that case, there would be no read-in penalty if one did not reference the dead material hits, only a disk space penalty.
In the end, we will need to gain experience on whether the steps, albedo and leakage parts of the proposal cause resource problems.
Additional notes [THB]:
Each volume has to have a unique name that is consistent with automatic assignment by G4. This will involve some additional code in Gismo, which does not assign names.
The complete particle history tree, up to interactions in the calorimeter, has to be made persistent, with a class that is consistent with G4 and Gismo. But I (THB) think this is nonsense, all that is really of interest is the first or second-generation parent. That is, the primary or secondary electron or positron.
Last Modified: 12/13/2000 10:45