This proposal stems from Traudl's MC raw data document. The underlying goals of this proposal are to allow a good record of energy deposit in the calorimeter: based on a shower initiating particle, and to allow albedo particles from showers to be recreated as 'real' particles.
This was done from the LCD project using Gismo, so there is an example to start from.
assign energy deposited in the active material of the calorimeter to the particle that entered the CAL and started the shower. Bookkeeping for shower particles would be abandoned.
allow particles that exit the CAL and re-enter the tracker or ACD to be recreated as real particles.
energy deposit in the logs would be subdivided by the list of MC particles that contributed energy to them
a record of energy deposited in non-sensitive materials be recorded
a record of energy exiting GLAST be recorded (this should be achieved by the particles exiting as real particles)
in order to keep track of shower particles and whether to convert a shower particle back to a real particle, there needs to be a sharp definition of CAL and non-CAL. Volumes need to carry such an attribute.
the score function of the digitizer needs to have access to the MCParticle object. This breaks the clean separation of the digitizer from the MC particle.
a shower particle would have to traverse its parentage tree to the shower initiating particle
the shower initiating particle needs to be tagged as such
all volumes would need an associated digitizer, sensitive or not
a proper MC record of particles and their terminating positions and energies would satisfy the requirement for tracking exiting energy.
Here are snippets of code from the LCD project which achieved this shower bookkeeping.
DigitizerInterface::score is modified to pass a pointer to the current MCParticle
void DigitizerInterface::score(MCParticle* track)
Supply a function to search the tree for a parent shower particle
// look back into the shower to find a shower, or return zero
const MCParticle* shower_initiator(const MCParticle* p) {
while( p !=0 ) {
if( p->status() == MCParticle::SHOWER ) return p;
p = p->parent();
}
return p;
In the CAL digitizer:
// if the particle has interacted, and has no source itself, set its status to SHOWER
const MCParticle* shower_source = 0;
if (MCPart->status() != MCParticle::ALIVE) {
shower_source = shower_initiator(MCPart);
if(shower_source==0) {
const_cast<MCParticle*>(MCPart)->setStatus(MCParticle::SHOWER);
shower_source = MCPart;
}
}
.....
// depositing energy: look for a shower initiator
if( shower_source==0 ) shower_source = shower_initiator(MCPart);
// if none, attribute it to this guy
if( shower_source==0 ) shower_source = MCPart;
then use shower_source as the MCParticle of record for storing particle info for
this deposit.
In MCParticle, where the generations are trimmed, only do it for showering particles, and trim all generations. Note that this trim will kill off newly real albedo particles!
// finally, if not displaying, get rid of children here
// only for particles which showered in the calorimeters
if(status() == SHOWER) removeChildren();
all CAL volumes would have to have some kind of associated digitizer; this will also follow from the requirement of recording energy deposited in dead material.
albedo particles would be nuked in this scheme, if they were created!
albedo particles are not created
there would have to be logic in the digitizers of non-CAL volumes to check whether an MCParticle was the daughter of a shower initiator. If yes, then it would have to flag the particle as albedo. Perhaps the removeChildren method would have to check for this flag?
will have to take special care for spatial bookkeeping - 'daughter' particle will not be directly connected to its parent, ie parent's termination point is not the initial point of the albedo particle. I think Traudl's design covers both initial and termination points, so this may not be an issue.
how do we want to represent the energy deposited in dead materials? Summed per sub-system? Grouped in some other way? Individually for all volumes??
how do we deal with shower leakage? At high energies lots of shower particles will leak out the back. And remember that 'back' is notional. For example a very off-axis shower might leak into the ACD.
R.Dubois Last Modified: 12/13/2000 10:45