New far forward beampipe and cryostat model v2025 implementation

[nat93]

Briefly, what does this PR introduce?

This PR introduces a complete model of the cryostat (fwd and bwd) with detailed description of superconducting coils, support tubes, yokes, yoke shielding, heat shielding, and cryostat vessel. The fwd and rear sides were adjusted in order to avoid overlaps with off-momentum detectors and low-Q^2 tagger pipes.

The corresponding STEP file can be found on SharePoint: EIC Public Sharing Docs → Documents → Experimental Program → ePIC → Engineering → STR-Files → IR6_CRYOSTAT_2200m_top_4-24-2025.stp [https://brookhavenlab.sharepoint.com/:u:/s/EICPublicSharingDocs/EdR44ODny1BEmMTTks61CCwBe8tJYMc0iWkPIYY_EjYEuw?e=2XLUEt]

The changes have been communicated to TIC, IR, and MDP communities.

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?

Yes, it adds extra materials between the beam pipe (beam loss hot-spots) and the ePIC detector. It is crucial for the realistic detector background and dose calculations.

[wdconinc]

I will of course ensure that the necessary changes for the OMD and RP are in place before a new campaign would be launched with the changes

Considering how much we keep having to delay campaigns for late changes and requests, I would suggest that this work of implementing any changes to the OMD reconstruction matrices should start soon. It seems unlikely that we would merge this and knowingly break (apparently) also the far forward without any PR already in place.

[ajentsch]

I will of course ensure that the necessary changes for the OMD and RP are in place before a new campaign would be launched with the changes

Considering how much we keep having to delay campaigns for late changes and requests, I would suggest that this work of implementing any changes to the OMD reconstruction matrices should start soon. It seems unlikely that we would merge this and knowingly break (apparently) also the far forward without any PR already in place.

I will do it this week - it's on my very long list.

[nat93]

Hi @simonge,

I'm still not entirety comfortable with this PR. There is too much to review with due attention to ensure it is both appropriately maintainable and functional without dedicating a significant uninterrupted period of time. It would take less time to review and merge a series of incremental PRs. This might just be a flaw in my current attention span capacity.

There is only one .cpp file with two functions and four XML files describing the cryostat geometry. Nothing has changed for any of the systems except for the OMD, for which @ajentsch has provided a comprehensive explanation.
I believe it would be wise to focus our efforts on ensuring the geometry is updated, rather than on optimizing the design or performance - especially given that the current setup in DD4Hep is outdated and will never be built. Furthermore, we are all aware that additional updates are on the way, which will inevitably affect the detectors: a new beam pipe from the vacuum group, new magnets, and more.
We are already behind with the B2eR update, which, as decided by the Project, must be moved outside the cryostat. Of course, we can propose further updates to the warm B2eR, but only after implementing the changes that have already been decided.

Furthermore, radiation calculations are an ultra-high priority. They are essential for machine and detector protection, including the design and placement of collimators, shielding, optics tuning, and the vacuum system. From my perspective, this currently appears to be the most pressing/urgent issue (<-- rephrased to avoid misunderstanding). We must implement the geometry and run full radiation simulations - including TID, background rates, and related metrics - to determine whether ePIC can withstand the expected conditions.

Why have you moved the far_backward magnet definitions out of magnets and into beamline_extension_electrons?

I did this for consistency. The HSR BWD/FWD magnets are defined in beamline_extension_hadron.xml/ion_beamline.xml, while the ESR BWD/FWD magnets are defined in beamline_extension_electron.xml/electron_beamline.xml. This separation makes it clear where to look for each ring.

This cpp file is used only for cryostat magnets, so there is no need to create a separate - it is already a separate class. For most of the elements, the common coordinate is the yoke position. However, there are many individual components that are not aligned with the yoke, such as holes, electron beam pipe elements and magnets.
This will likely highlight my ignorance of the magnet geometry. The Q1eR and Q2eR coils and support tubes are already factorized out from the cryostat volume with the cryostat volume built around them from the Q1APR etc definition. Could we not do the same for the Q1APR etc. making the xml files and geometry hierarchy easier to understand?

In the latest commit, I have moved BWD cryo magnets from far_backward/beamline_extension_e/h.xml to far_backward/magnets.xml.

Please remove the white space between the numbers, units and operators in the xml.

I have removed the white space between the numbers, units and operators in the xml.

Please update the copyright statements to include your name.

I have added my name.

[wdconinc]

@nat93 Everyone's work is important in this collaboration. Acting dismissive of others' work will not be tolerated here.

[nat93]

@nat93 Everyone's work is important in this collaboration. Acting dismissive of others' work will not be tolerated here.

Hi @wdconinc , perhaps my message was not clear. The main idea is to optimize the procedure to avoid double work for everyone. I did not mean what you wrote. Opposite, I do respect other people work and it would be not efficient optimizing configuration that is already outdated, postponing the central detector protection and collider design - this is the message.

[nat93]

Hi @ajentsch,
Thanks for catching the missing units — you are absolutely right that all dimensions should be explicitly defined with units. I have also added a few other missing units (including OMDs) and corrected some typos in the older scripts, as we previously discussed ('apperture' -> 'aperture').

[ajentsch]

Yes, we should. Those were put in "by hand" to have vacuum surrounding the detector planes. Those numbers will need to updated now, too. Will try to do that tomorrow.

…

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

On Fri, Jul 4, 2025, 12:20 AM Andrii Natochii ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/forwardBeamPipeBrazil.cpp <#893 (comment)>: > @@ -517,10 +525,23 @@ static Ref_t create_detector(Detector& det, xml_h e, SensitiveDetector /* sens * SubtractionSolid final_vacuum_main_pipe( vacuum_main_pipe, cutout_for_OMD_station, - Position(0.0, 0.0, (2251.0 - beampipe_dimensions[pieceIdx].zCenter))); Hi @ajentsch <https://github.com/ajentsch> , should not we use units here as well? — Reply to this email directly, view it on GitHub <#893 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADABSF3MWPU3VGW5ZS6XHH33GX6JPAVCNFSM6AAAAAB7UPHSWCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDSOBVGQZDGMRSGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[johnlajoie]

Hey @nat93 @simonge @ajentsch @wdconinc - I'm trying to follow along with this an other PR's to see where we are in converging on an updated geometry that can be used in a consistent fashion for the "events with background" that we need to get going on the preTDR studies. @simonge - you had a bulleted list of seven things you wanted to see before this PR was merged. Is this feasible in a reasonable amount of time, and how much time is that?

I realize a lot of work is being done by a small number of people so please don't take any of this as a criticism, just trying to to make sure I understand where we are.

[ajentsch]

EICrecon PR with updated OMD matrices is ready: eic/EICrecon#1957

[nat93]

Dear @wdconinc, @simonge, and @johnlajoie,

Following the suggestions from Simon and Wouter, as well as our Zoom discussion, @ajentsch and I have refined the PR to meet the outlined criteria. - Many thanks to Alex for assistance.

The FWD beam pipe remains unchanged in this PR - there is no impact on the far-BWD detectors. On the FWD side, the beam pipe was adjusted to eliminate overlaps between the cryostat and the OMD chamber (Alex has updated the detector positions accordingly). The magnetic fields remain unchanged, and the detector acceptance is not reduced. In fact, on the FWD side, the acceptance may slightly increase due to the larger inner radius of the HSR cryostat compared to the beam stay-clear aperture.

This PR is a step forward, but additional improvements will follow: proper beam pipe definitions, a warm and split B2eR, and refinements to the magnetic fields and/or coil length (to be coordinated with the optics and magnet teams).

If everyone agrees, we propose to proceed with merging this PR.

[veprbl]

Trying to figure out what are the remaining blockers.
@simonge You were planning to look at the impact of this latest version?
We also need to check material map before/after merging this.

[simonge]

From what I see there is no impact compared to the current version at the moment as expected.

[simonge]

We also need to check material map before/after merging this.
There shouldn't be any change to the material map as I understand because everything is outside of the central detector region and outside the beampipe in the FF/FB regions.

There might be some changes I suggest down the line but happy to approve now and get the OMD update in EICrecon merged too.

[nat93]

Hi @simonge , should we expect or wait for any further checks? If not, can you please approve the PR so we can merge it? Thanks

[simonge]

Approved. I was hoping someone with more experience of the material map would confirm a new one wasn't needed.

[veprbl]

I will take care of the map.