Rev 1
This proposal is the outcome of discussions with the core and subsystem software groups. The original discussion can be found in Traudl's note. See here for the original draft of this proposal.
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.
must account for all event energy, whether deposited in active or passive media in all volumes or exiting the world volume
this energy accounting must be segmented; it cannot just be one number for all energy not seen in active media
CAL logs must register energy sum and energy-weighted longitudinal position moments
MC parentage must trace back to the original interacting particle
must account for energy loss in dead material in the TKR.
the dead material energy loss must be segmented at least by plane
energy loss in the Silicon must record the volume ID, position of the step, direction cosines and MC parent particle. It may need to record the exact particle type that did the deposit, and the total energy of that particle.
must know whether this hit came from the primary particle or a daughter
MC parentage must trace back to the original interacting particle
must account for energy loss in dead material in the ACD.
TBD how such energy loss must be segmented
energy loss in the scintillator must record the volume ID, position of the step and MC parent particle.
MC parentage must trace back to the original interacting particle
There appears to be no requirement for identifying intermediate particles in the MC parentage tree. A very simple MC record could result.
To respond to these requirements, we propose to notionally separate the instrument into 'volume integrating' and 'single-step' components. In any case, all volumes are marked as 'sensitive' to the simulation package (eg, Gismo, G4). Volumes will carry an additional property indicating whether they are 'sensitive' for digitizations.
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 single-step volumes. Once the particle interacts, it is tagged as showering and all its daughters' contributions are assigned to it.
Summed energy (and volume ID and list of MC parents) is stored for 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.
Energy depositions from shower particles that leave the CAL volumes would have that property tagged in their Hits status word.
(*) - 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).
This proposal only refers to volumes. We can tune the volume segmentation and type (single-step or integrating) to optimize the spatial understanding of energy deposit (presumably balanced against resource costs).
Both the world volume and the spacecraft may need to be volume integrating, otherwise the number of hits recorded will probably be excessive.
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.
We run the risk of drowning in hits and will need considerable flexibility in controlling the volume of data we produce.
Supply a job option for whether or not to store hits in passive materials.
Supply an attribute for each volume which can select from:
single step
volume integrating
store/calculate moments
only return an energy sum
Allow for separate Root PDS branches for hits in active and passive materials, hence different TDS classes. In that case, there would be no read-in penalty if one did not reference the dead material hits, only a disk space penalty.
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.
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.
Last Modified: 12/13/2000 10:45