Unified "Key" for all detectors in detectorSimulations

[moukaddam]

Some of the detectors will be used together in the simulations e.g. Spice + Tigress or Paces + Griffin. I suggest that we agree on numbering each detector up to the smallest detector element with a specific number or a key, we could get inspired by the mnemonics at TRIUMF (http://www.triumf.info/wiki/tigwiki/index.php/Detector_Nomenclature).

This Key could be delivered to the "StepTracker" and will be available to use in the eventAction. It could be used to fill the Tree, the histograms and the Ntuples and also as a condition for particular operations on particular detectors.

We could parse the key and get what is the type of the touched detector, its number, segment... The Griffin part contains a very similar thing where they parse the name of the volume touched to get the relevant information. With Spice also we have something similar. However when spice is touched, "detNum = 1" is different than the same value ("detNum = 1") when Griffin or PACES are touched. So the idea is to add an additional key number at the beginning that is specific to the detector.

[evan012345]

This is a great idea. Check out "G4Region.hh", I think this is something you can use here. There is a Geant4 example using "RegionInformation" in examples/extended/runAndEvent/RE01/.

Basically in your detector construction you initiate the RegionInformation class and pass it some variables like "This is the world", or "This is part A of the detector", etc. Then you pass this to your logical volume. In the stepping action you can get at this information via step->preStepPoint->physicalVolume->logicalVolume->region->regionInformation, thus you can easily identify in which region the current step belongs. We could keep this "number key" you speak of inside RegionInformation.

I've been meaning to redo the way the detector number and crystal number are found in the SteppingAction. As you said, right now we parse the name of the volume touched to get the relevant information. Although it works well, it's a bad way to do it. String comparisons are slow. We would be able to speed up the simulation if we used volume copy numbers.

[bkatiemills]

I agree, a standardized per-detector element label is an excellent idea - @moukaddam, please use exactly the nomenclature at the link you provided to stay consistent with the rest of the GRIFFIN / TIGRESS software universe.