Add functionality to track in a BeamPipeChain

[simonge]

Briefly, what does this PR introduce?

An option had been added to include sensitive elements at the start and/or end of beam pipe vacuum. This allows easy tracking of the shape and position of beam electrons/protons to compare with accelerator group and stand alone simulations. The segment in which scattered electrons of different kinematics can also be studied/verified.

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?

No

[simonge]

This will be extended to include a specific configuration for testing along with a benchmark script and sample beam particle events.

[simonge]

Is there some way to turn on/off the sensitivity of a detector via a flag/constant in a config file? Ideally this readout would be off unless the (e.g.) ip6_extended config was used.

At the moment I can only work out how to do this by completely copying the magnets.xml file and adding a readout and sensitive flag there.

[veprbl]

I think, using the files is the way to go. To reduce duplication, you may need to abuse <include>s.

[simonge]

The approach I've currently implemented seems to work. Where additional detectors elements are created in entirely separate code and injected into the relevant beampipe segment.

[simonge]

Please can someone review this, it is aimed at benchmarks which will compare the electron beam shape progression between the simulation and those expected by the accelerator lattice.

One thing I'd like to discuss is how best to terminate the electron beam beyond where it's needed, which is relevant beyond the core of this PR. Speeding up single beam electron simulations ~200x. At the moment I have introduced a filter which kills all particles which enter a volume and just added that to a vacuum element in the pipe, might it be better to instead introduce a new geometry element "BeamStop" which is placed in the beamline instead of changing what's there?

[Chao1009]

Looks good to me

[simonge]

Apologies I decided to move to the beamstop implementation and needed to give the assembly a token ID for the benchmark to run.