Compact lumi pair spectrometer

[dhevang]

Briefly, what does this PR introduce?

Implement a new luminosity dipole magnet based on design from BNL engineer Peng Xu.
The stronger magnet allows the pair spectrometer to be much more compact.

What kind of change does this PR introduce?

• Bug fix (issue #__)
• New feature (issue #__)
• Documentation update
• Other: __

Please check if this PR fulfills the following:

• Tests for the changes have been added
• Documentation has been added / updated
• Changes have been communicated to collaborators

Does this PR introduce breaking changes? What changes might users need to make to their code?

Does this PR change default behavior?

[wdconinc]

This looks like a lot of nice work.

[dhevang]

Made commits to fix an overlap error in my system and for Dima's copyright suggestion. However, now another overlap error occurs in epic_craterlake. It appears to be related to some change in the beamline magnet volumes.

[wdconinc]

It appears to be related to some change in the beamline magnet volumes.

That's why I asked @ajentsch to double check with you that his beamline magnet changes wouldn't affect the backward region :-) There were no overlaps after those changes were merged in main.

[ajentsch]

It appears to be related to some change in the beamline magnet volumes.

That's why I asked @ajentsch to double check with you that his beamline magnet changes wouldn't affect the backward region :-) There were no overlaps after those changes were merged in main.

How could my changes cause overlaps on the opposite side of ePIC?? (I did communicate the changes to both @dhevang and @simonge)

[dhevang]

Yeah, Alex mentioned the change to me.
The tests that I triggered 18 hours ago went through fine without this overlap error. The one I triggered this morning had a problem though. All I did in between was change a copyright comment.

[wdconinc]

How could my changes cause overlaps on the opposite side of ePIC?

Because you changed a magnet geometry description that is also used on the opposite side of ePIC.

The tests that I triggered 18 hours ago went through fine without this overlap error.

Not getting an overlap error is not a guarantee that there are no overlaps (but getting an overlap error is a guarantee that there is an overlap):

• overlap checking is a statistical procedure, not an analytic procedure,
• there is a tolerance, and for overlaps that are close to the tolerance you may 'sneak through' without triggering an overlap error.

[ajentsch]

Sure, but I *removed* a piece of extraneous geometry, and didn't change the yoke itself. It should have actually reduced the chance of an overlap.

…

On Fri, Aug 11, 2023 at 12:26 PM Wouter Deconinck ***@***.***> wrote: How could my changes cause overlaps on the opposite side of ePIC? Because you changed a magnet geometry description that is also used on the opposite side of ePIC. The tests that I triggered 18 hours ago went through fine without this overlap error. *Not* getting an overlap error is not a guarantee that there are *no* overlaps (but getting an overlap error is a guarantee that there is an overlap): - overlap checking is a statistical procedure, not an analytic procedure, - there is a tolerance, and for overlaps that are close to the tolerance you may 'sneak through' without triggering an overlap error. — Reply to this email directly, view it on GitHub <#498 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADABSF3UUJ2YTG7SIJUR2JTXUZMKJANCNFSM6AAAAAA3L3KSIE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- ------------------------------------------------------------- Alex Jentsch Assistant Staff Scientist, EIC Directorate Brookhaven National Laboratory Upton, NY 11973 Bldg. 510, 2-234 Phone (office): 631-344-2139 Phone (cell): 281-726-0114 Pronouns: he/him/his

[dhevang]

Well, the last 2 CI tests that I triggered went through fine (no FF overlap error). Despite the statistical limitation to these checks, should we merge this into main or wait till a fix comes? It should affect all other PRs too right?

[ajentsch]

I meant to fix it yesterday, but then another issue derailed me yesterday and today. I should be able to get it fixed tomorrow. Sorry about that.

…

On Thu, Aug 17, 2023, 8:50 PM Dhevan Gangadharan ***@***.***> wrote: Well, the last 2 CI tests that I triggered went through fine (no FF overlap error). Despite the statistical limitation to these checks, should we merge this into main or wait till a fix comes? It should affect all other PRs too right? — Reply to this email directly, view it on GitHub <#498 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADABSF56MBHFO4VT7JYSOTLXV234XANCNFSM6AAAAAA3L3KSIE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dhevang]

@wdconinc initiated two new tests today and both failed with the same overlap error:
Overlap is detected for volume AV_11293!VacuumMagnetElement_assembly_51#51!v_b1pf_vacuum_5#5:57 (G4Cons) with AV_11287!Q2PF_BeamlineMagnet_assembly_29#29!yoke_vol_0#0:30 (G4Tubs)
Concerning the issue, I suppose the problem is that the G4Tubs do not lie on the same straight line, because there's the b1pf dipole. The vacuum tube inside the b1pf is at a slight angle wrt the Q2PF tube. So a tiny corner of the vacuum tube edge probably hits the Q2PF. Although not the most elegant solution, could one simply modify the length or radius of the vacuum by like 0.5 mm? @ajentsch is that a viable solution?