-
Notifications
You must be signed in to change notification settings - Fork 101
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
Bug in DD4hep G4 converter (G4 Physical volumes creation) #786
Labels
Comments
Salut Gabrielle, Problem confirmed:
Markus |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I tracked back issues from CMS, which seem to come from the dd4hep G4 converter (no worry, not reflection-volume related this time ;p).
The issue appears in the following situation:
Whenever, in the XMLs, a given container volume (containing at least one child) is placed in different mother volumes located at different hierarchy levels.
When that happens:
The children inside the container end up (wrongly) duplicated N times (N being the number of different mothers hierarchy levels).
Please note that this issue
does not appear at XML parsing stage (looking at the volumes there, they are all ok).
The issue appears at G4 conversion stage: the G4 Physical Volumes children are wrongly duplicated.
I could isolate and reproduce the issue within dd4hep, with a simple test XML file.
trackerpixbar.xml.zip
You just need to put it in place of examples/DDCMS/data/trackerpixbar.xml .
You just need to activate the G4 debugPlacements.
Then run:
python ../DDCMS/scripts/CMSTrackerSim.py
And look up for "+++ Place volume trackerpixbar:TestChild".
You will see that, according to the XMLs logic, the TestContainer physical volume should only contain 1 child, TestChild.
But when TestContainer is placed in different mothers of different hierarchy levels, the children inside TestContainer get placed several time within TestContainer, hence get multiplied!!
Here, TestContainer ends up with 2 children instead of 1!
You can also see in the G4PhysicalVolumeStore, that there are too many TestChild ren.
In this example, TestContainer only has 1 TestChild, but this issue also happens for any number of children. If TestContainer has several children / a child subtree, the entire child subtree is wrongly duplicated.
This has many consequences on CMS side (ECAL, PSS), where we wrongly end up with too many G4PhysicalVolumes.
This situation actually seems pretty generic, hence branches up to many use cases.
Could you please have a look?
At this stage, this should be easy to debug on dd4hep side now :)
Let me know if you need any other info.
Regards
@ianna @cvuosalo @civanch
The text was updated successfully, but these errors were encountered: