I have been having a similar problem and am hoping to get clarification here.
My entire geometry is defined using GDML, I find it convenient for rapid prototyping and have a detector construction class that can use the auxiliary tags to apply visualization attributes to volumes as well as tag which volumes are to have which sensitive detector attached.
I have a gamma-ray detector that I have defined to be an aluminum shape with two daughter volumes. The first daughter volume is just the vacuum of the PMT, the second is a chunk of silicone that, in turn, has a daughter volume, a block of NaI(Tl) to which my sensitive detector is attached. This detector is placed 24 times on the sides of a cube as follows:
I was faced with the conundrum of having the sensitive detector class’s
ProcessHits function determine which volume it was in and determined that something like:
was a decent choice seemingly the minimum amount of nested memory access. Then I realized that I didn’t see any way to set copy number in the GDML manual. By reading the schema I discovered that the
<physvol ...> tag accepted attributes
copynumber as follows:
<physvol name="Detector07" copynumber="7"> So I set those for each of my placements of the detector logical volume.
<physvol name="Detector08" copynumber="8">
Unfortunately, on doing this yesterday, I discovered that the copy number does not propagate down to the daughters of the placed logical volume, as seen in the scene tree of my visualization:
I understand that I could get the touchable as described above and work my way up the touchable tree to get to that copy number from “down in the NaiCrystal_PV” but I would prefer to not require so much memory access in my process hits function. The more pointer chasing I have the more bits of potentially uncached memory accesses I have, on top of the string compares looking for a name to tell
ProcessHits “this is the bit you need to look for a copy number in.”
To avoid this inefficiency I have since been looking for a way to traverse the hierarchy at detector construction so that I could take the copy number of the “Detector” and propagate it down to the “NaiCrystal_PV”. In my search I discovered this exchange in the old forum:
If I am reading this correctly, my idea for this process is doomed because there is only ever 1 “NaiCrystal_PV” and it is just touchable from many locations, is this true?
If so, is there any way to get around this? Other than creating a different logical volume for every placement? (which feels really inelegant)