I have a very general question to which I could not get any information so far.
So I want to do alignment studies with ROOT, which mean I want to verify that the procedures finding the misalignment (matrices) of the design to the real geometry deliver the correct results.
For this we would have done simulations with a geometry that is misaligned, by taking the design geometry (which has no overlaps) and alter the location of the individual volumes with modification matrices. Then the reconstruction of the events would be performed starting with the design geometry again and the alignment procedures would have to find the “mis-alignement” or modifications introduced before. By comparing these two results one can verify the alignment procedures.
However there is a problem in the simulation step. The modification process (which mis-aligns the design geometry a bit) generates overlaps in volumes that had no overlaps before!
Now the questions are:
is this the right way to verify alignment procedures? or is there another better way?
if this is the correct way? how should one handle the overlaps? just leave the geometry with overlaps?
I hope I explained it clearly enough. Thank you in advance!
Hi Stefan,
Your checking procedure seems fine. It is not ideal, but somewhat unavoidable that you get some overlaps after misaligning - as far as these will not affect much the material budget and it will not cut down the detection efficiency (first thing to check). In the alignment procedures one typically moves the detection elements. TGeo allows to move higher level volumes, which would help preventing overlaps at sensor level, but sometimes the alignment comes with too large corrections which generate problems. I implemented some years ago a feature that can solve the efficiency loss (overlaps at sensor level), called TGeoParallelWorld. The idea is that you can define “higher importance” volumes so that when particles would touch them any overlapping volumes will be ignored. You would populate the parallel world with your alignable sensors, then geometry navigation would give precedence to boundary crossings in this parallel geometry.
If you are hitting the detection efficiency issue, you can have a look at TGeoParallelWorld + the corresponding API in TGeoManager.
thx for your reply! Ok so other experiments also made alignment studies in this way I proposed? In general I’m just unsure what problems the overlaps of volumes will induce. If I understood you correctly only the detection efficiency can break down. I assume thats because the reconstruction algorithms may not be able to handle such misaligned geometries? But that would be precisely what we would want to check: When do the reconstruction/alignment procedures break down.
Could you comment on the technical difficulties of overlapping volumes in Geant? Does it not create any troubles in the simulation?
I read posts and heard people say that the geant simulation is not perfectly stable in case of overlapping volumes (e.g. http://hypernews.slac.stanford.edu/HyperNews/geant4/get/geometry/1311/1.html).
In order to have navigation features properly working one has to follow some rules for building a valid geometry.
The daughter volume(s) must not extrude the mother shape. They are allowed however to have a common boundaries.
The volumes positioned in the same container must not overlap with each other. They may touch on one boundaries or shape vertex.
and
We will designate non-overlapping nodes as ONLY and the others MANY as in GEANT3, where this concept was introduced: …
One needs to know that navigation inside geometry parts MANY nodes is much slower. Any overlapping part can be defined based on composite shapes - might be in some cases a better way out.
As a way out of the overlapping dilemma, I saw that I can also modify the geometry volumes shape later on. So I guess to avoid the overlap I could iterate over all overlapping volumes, and use TCompositeShapes to remove the overlaps. That would be quite a bit of work I think, and also a very general feature. So it could be plugged into the TGeo ROOT package at some point. I’m not sure what ROOT developers think of this idea
Yes, ALICE uses ROOT geometry alignment features, see: https://alice-offline.web.cern.ch/Activities/Alignment/Framework.html so you may want to get in touch with them. They have hit as well problems related to generating overlaps.
About the impact of overlaps in simulations: there can be many, so this is why people should do studies… Typically for an overlap region, the material is undetermined and depends on where the particle is coming for, so it will generate systematic errors related to whatever depends on material budget. How big or relevant these are has to be studied. Another effect is possible suck tracks, since the navigator may not be able to cross some boundaries (in practice I’ve not seen many of these). The other nasty effect is that some scoring volumes or layers may become completely “invisible” to transport. This is why recommendations are there, and misaligning volumes is not a fully safe procedure. However it can approach much better your detector’s “reality” than other misalignment procedures do (such as misaligning digits/clusters).
The solution based on composite shapes or changing the shape parameters is tedious and error prone, I wouldn’t go that path. What you can also do is trying to minimise the use virtual container volumes used just to position other volumes, by using TGeoAssembly - in this case you get less overlapping “envelopes”.
But I would start simple and just do the study you started with the overlaps in, then do the “damage” assessment.
We can have a chat sometimes if you are CERN based.
Cheers,
Andrei
Thx for the valuable information, just what I was looking for! All right, so I will go down my initial path with volume mis-alignment and study the overlaps. I’m in the Helmholtz Institute in Mainz working for PANDA at GSI/FAIR, so a chat sometimes only works Skype wise (maybe that’s also a way to contact you in person?) Thx again for your help!
(maybe that’s also a way to contact you in person?) Thx again for your help!