Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unified "Key" for all detectors in detectorSimulations #72

Open
moukaddam opened this issue Mar 13, 2014 · 2 comments
Open

Unified "Key" for all detectors in detectorSimulations #72

moukaddam opened this issue Mar 13, 2014 · 2 comments

Comments

@moukaddam
Copy link

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
Copy link
Contributor

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants