Solve all overlaps detected in Phase I Tracker #29366
Conversation
…, to avoid polluting Fireworks with non existing overlaps.
… scenario (more consistent, and safe since it is an infenitesimal reduction anyway).
…AxGrounding. Same issue, same remedy here: borders are defined at exact same phi.
|
The code-checks are being triggered in jenkins. |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-29366/14468
|
|
A new Pull Request was created by @ghugo83 for master. It involves the following packages: Geometry/MTCCTrackerCommonData @civanch, @Dr15Jones, @makortel, @cvuosalo, @ianna, @mdhildreth, @cmsbuild can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
|
@cmsbuild please test |
|
The tests are being triggered in jenkins. |
|
+1 |
|
Comparison job queued. |
|
Comparison is ready Comparison Summary:
|
|
@ghugo83 , this is a useful fix, because an overlap is detected. At the same time, making gaps between volumes is not a good practice, because it is obviously slow down the simulation - all particles will make an extra step between such volumes. CPU in Geant4 is always proportional to number of steps independently on how long they are. So, this fix is an exception for this concrete geometry. |
|
@civanch Thanks a lot for your comment. In general, speaking of the number of steps, why are the cables modeled in such fine detail? Would phi sections of cylinder, averaging out all services contributions, not suffice? This would instead reduce by several orders of magnitude the number of steps. |
|
@ghugo83 , a general approach in CMS, ATLAS, and some others is to describe as accurate as possible real geometry. If simulation is slow due overdoing this in some sub-detector, than a possible short-cut is developed. It is difficult to do in the inverse order. |
|
+1 |
cmsbuild
added
fully-signed
geometry-approved
and removed
geometry-pending
pending-signatures
labels
|
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @silviodonato, @dpiparo (and backports should be raised in the release meeting by the corresponding L2) |
|
+1 |
Solve all overlaps detected in Phase I Tracker:
In general, I would think it is good practice to avoid having volumes 'sharp' at the same boundary in the XML description, since with default meshing / rounding errors, they can be seen / actually become overlaps.
Directly using an epsilon in the XML description in this kind of situations should solve a lot of headaches, at no cost for the geo and Material Budget.
PR tests:
0 overlap with G4 AND Fireworks overlap-checking tools, for both Reference and Migrated 2021 Scenario.