6.3.1 Far-Backwards Lattice

[simonge]

Briefly, what does this PR introduce?

Originally instigated by moving the B2eR magnet out of the cryostat, this geometry matches the most recent lattice of the accelerator in the far backward region.

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?

No

Does this PR change default behavior?

Changes the path of electrons in the far-backward region. This will break the Low-Q2 Tagger reconstruction, simple retraining of the network should be sufficient after this is eventually merged.

[simonge]

@nat93 @adamjaro Please could you check the quadrupole fields have been calculated correctly from the tables, I don't think the x/y divergence plots I see quite match those you both previously shared.
https://github.com/eic/epic/blob/6.3-Lattice/compact/fields/beamline_18x275.xml#L22

[ajentsch]

@simonge have the quad fields been confirmed yet? I will approve once your question has been answered by either @adamjaro or @nat93 to make sure things are correct.

[ajentsch]

@simonge have the quad fields been confirmed yet? I will approve once your question has been answered by either @adamjaro or @nat93 to make sure things are correct.

Also, you may need to pull the latest version of epic because there are some new magnet XML files I put together. I made some new changes today. You should wait until those are approved, and merged, and THEN pull that new version in, and add your changes to the additional XML files for the magnets.

[nat93]

@nat93 @adamjaro Please could you check the quadrupole fields have been calculated correctly from the tables, I don't think the x/y divergence plots I see quite match those you both previously shared. https://github.com/eic/epic/blob/6.3-Lattice/compact/fields/beamline_18x275.xml#L22

Hi @simonge,
Here is what I have in my (SynradG4) code for those magnets:

• Q1eR: K1L = -0.4140 [1/m] --> K1 = -13.691602 [T/m]
• Q2eR: K1L = +0.3164 [1/m] --> K1 = 13.453487 [T/m]
• Q3eR: K1L = +0.119551 [1/m] --> K1 = 11.861213 [T/m]

I used a similar formula to calculate the gradient (K1): K1 = 3.33564 x K1L / length x pc

[simonge]

@nat93 Great, thanks for confirming.

@ajentsch This might still be a draft for a bit while as it will break the Low-Q2 ML reconstruction in EICrecon.

@veprbl @wdconinc Any idea how the (semi)automatic updating of the neural network is going to work in practice. Ideally it would come as part of this PR but the performance would only get checked checked downstream as a benchmark which I don't believe are ever run on epic PRs.

[simonge]

My thoughts.

1. Add a capybara test which uses a configuration with beamline_tracking.xml enabled.
2. If there are differences in this run a larger sample of min bias events through epic and EICrecon
3. Run the benchmark training script on the output
4. Publish a separate capybara comparing the reconstruction before and after the network is updated.
5. Update epic data with the new network (manual or automatic?)
6. Update the link in the calibrations to match the new file.

Can/should there be human intervention in some of these steps?

[veprbl]

My thoughts.

1. Add a capybara test which uses a configuration with beamline_tracking.xml enabled.
2. If there are differences in this run a larger sample of min bias events through epic and EICrecon
3. Run the benchmark training script on the output
4. Publish a separate capybara comparing the reconstruction before and after the network is updated.
5. Update epic data with the new network (manual or automatic?)
6. Update the link in the calibrations to match the new file.

Can/should there be human intervention in some of these steps?

I believe bench:calo_pid is running training on each run, and weight files are always available as artifacts. Your step 2. is what is missing. Updating epic data (your step 5.) is what capybara capy command could do. Automated editing of compact XML and submitting a PR should be possible, although there is no precedent for that yet. We were discussing a similar automation path for material maps with @ShujieL, and that is also missing step 2. to make it work currently.

If training is too slow to be ran every time, there is a precedent for benchmarks that only run on demand: