feat: use BoundedMultipoleMagnet with AABB pre-filter to MultipoleMagnet#1048
feat: use BoundedMultipoleMagnet with AABB pre-filter to MultipoleMagnet#1048
Conversation
There was a problem hiding this comment.
Pull request overview
This PR introduces a performance optimization for multipole magnet field evaluations by adding an axis-aligned bounding box (AABB) pre-filter to the MultipoleMagnet field type. The new BoundedMultipoleMagnet is designed as a drop-in replacement that performs a cheap AABB check before delegating to the expensive rotated tube containment check and multipole field calculation. According to the PR description, this addresses a significant performance bottleneck where 30% of simulation time was spent in field evaluations, with 25% of that in Tube::Contains checks.
Changes:
- New
BoundedMultipoleMagnet.cppimplementation with AABB pre-filtering - Updated all far-forward and far-backward multipole magnet field definitions to use the new field type
- Updated electron beamline quadrupole field definitions
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| src/BoundedMultipoleMagnet.cpp | New field plugin that adds AABB pre-filter to DD4hep's MultipoleField |
| compact/far_forward/magnets.xml | Updated 8 magnet fields to use BoundedMultipoleMagnet |
| compact/far_forward/electron_beamline.xml | Updated 2 quadrupole fields to use BoundedMultipoleMagnet |
| compact/far_backward/magnets.xml | Updated 5 magnet fields to use BoundedMultipoleMagnet |
| compact/far_backward/lumi/lumi_magnets.xml | Updated 2 commented-out ideal field definitions to use BoundedMultipoleMagnet |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Briefly, what does this PR introduce?
This PR adds a pre-filter to the MultipoleMagnet to apply an axis-aligned bounding box. This avoids expensive rotated r-z Tube::Contains evaluation in many cases, in particular since our fields are all added in an OverlayField, and assigned to the global field manager (i.e. evaluate for the far forward and far backward regions for every particle in the EM calorimeter showers).
Profiling indicates we spend 30% of the total ddsim (no optical photons) simulation time (for DIS 18x275 Q2>1000) in dd4hep::MultipoleField::fieldComponents, of which 25% (of the total simulation time) in the Tube::Contains (this is based on callgrind). This PR aims to address that (more profiling below).
Other options considered:
Comparing profiling in the ctree artifacts (for DIS 10x100 Q2 > 1000 this time, sorry), we see the total time of simulation go from 822s to 768s. The time in dd4hep::MultipoleField::fieldComponents (in the various places in the call tree where it is called) goes from 45+5+6+4s to 12+1+1+1s, for a 6% speed increase.
What kind of change does this PR introduce?
Please check if this PR fulfills the following:
Does this PR introduce breaking changes? What changes might users need to make to their code?
No.
Does this PR change default behavior?
No.