Issue with Vertical Kick in FLUKA Beamline After Rotation

Dear FLUKA experts,
I’m currently working on a rather complex beamline setup in FLUKA, and I’ve run into an issue that I hope you can help me with.

My beamline consists of 3 dipoles and 7 quadrupoles, with a 16° horizontal bending angle. The challenge arises from the fact that the beamline must be installed in an existing tunnel with a ~5° inclination, while the decay tunnel at the end needs to be leveled to the surface. To accommodate this transition, I had to apply a roll to the beamline to ensure proper alignment.

Since FLUKA does not allow nested roto-translations, implementing this was quite challenging, but after several days of work, I believe I managed to get it right. The magnetic fields inside the beam pipe are defined with the correct roto-translation—when I plot them, they appear as expected, and the magnets are positioned correctly in the geometry.

However, I’ve noticed an issue: there seems to be a vertical force component generated by the dipole fields, giving a slight vertical kick to my beam. By the time the beam reaches the last quadrupole, about half of it is lost against the walls of a magnet. This suggests that either the dipole field is not being applied correctly or there is a fundamental issue with how I built the beamline.

I would really appreciate any insights on what might be going wrong. I’m attaching my input file below—specifically, the relevant roto-translations start from QUAD_ROT.

Thanks in advance for your help!

Best regards,

Matteo
PBC_SBN_DESIGN_BDnew.inp (124.6 KB)

Hello Matteo,

Thank you for your question and for providing the input, I am going to look into this and let you know early next week.

Meanwhile, I noticed you say that transformations cannot be nested. If you mean composed, as in applying a sequence of transformations, FLUKA can handle it, see link in Notes 5. If you mean something else, let me know.

Stefano

Dear Stefano,

Thank you for your reply! I look forward to your feedback.

Regarding transformations, I am indeed aware of the possibility of applying them sequentially, and I make extensive use of them in my input file. Perhaps a practical example will help clarify my point.

My beamline is positioned on a plane that is inclined downward relative to the tunnel floor. If nested transformations were possible, the implementation would be straightforward: I could define all the horizontal rotations of the dipoles and apply them within a single global rotation that describes the roll of the entire beamline.

Interestingly, Flair can render the geometry correctly even with nested transformations, but when starting the FLUKA run, it throws errors.

Thanks again for your help!

Best regards,

Matteo

Hi Matteo,

thank you for your patience. The geometry you are working with is quite complex, but I believe I found what is wrong with it.

Issue 1

I am assuming that in your geometry you want the design trajectory of the beam to pass through the central point of the quadrupole magnets, i.e. you want the beam Z axis to be transformed exactly like the Z axis of the quadrupole axis. If this is not the case, let me know. If instead that is your plan, there appears to be a slight misalignment.

I made this screenshot by following these steps:

  1. I positioned myself in the position of the magnets
  2. I have applied to my z-y view the transformation quad_rot
  3. I have aligned the origin of my view such that is is centred at the position of where the beam is created
  4. I toggled the visualization of the beam, and changed the scale parameter so it would pass through all the elements
  5. I changed the aspect ratio such that the s-coordinates through the magnets would be reduced, and amplifies drifts in the transverse position

What the screenshot is showing you is basically a quadrupole-centered view of the beam alignment, which clearly shows that the beam itself is not aligned with (not a huge misalignment, in absolute terms, about 3 cm over 12 m, but very noticeable from a beam dynamics perspective.

Solution:

Align the beam so that it is in the direction of the longitudinal axis of the magnet system (quad transformation).

The issue appears to be that when you specified the cosines of the beam with respect to x and y axis:

cos(x) = 0.0283
cos(y) = 0.0847

you calculate cos(x) incorrectly. Without more information on how this value was calculated, it is hard to say what went wrong, angular transformations are non-commutative and can be very tricky. To make your life a bit easier, you can use geoviewer, apply the quad_rot transformation, and see what angle the z axis of the frame makes with x, and that is the one you should use. It should be

cos(x) = 0.01951

With this corrected value, the same screenshot as above looks like this:

Issue 2

The magnetic field you are requesting on the dipoles (1.5-1.8 T) are simply too weak to bend a 400 GeV proton beam. I am assuming you wanted something closer to 8 GeV. To bend protons of 400 GeV in your geometry it would take an ambitious ~90T.

I hope this resolves your issues. Let me know if I made any wrong assumptions, or if there is anything else I can help with

Stefano

Hi Stefano,
Thank you for the reply and I am sorry that I wasn’t clear about my experimental setup.
The beam line is intended to be used in a neutrino physics experiment.
The primary beam is indeed a 400 GeV proton beam (the SPS one) but the slight horizontal kick is wanted since the target has a 0.5° angle in order to have an angled production of secondary particles; this is done to split between the secondary beam and the primary one that will go into the dump; indeed, when I remove the 0.5° angle, the same problem appears.

Also, with regards of the second issue, the magnets are tuned with a magnetic field of 1.8 Tesla because I want to steer the secondary beam which is made up of π+ and K+ with an energy 8.5 GeV.

I managed to pinpoint it to the dipoles because if you study the fluence after every beam line elements one can see that after the dipoles the beam starts to drift on the vertical axis when it should remain in the very middle.
In the picture below is shown this behavior, although at the end of the 2nd dipole just to emphasize this effect, but if one look at the fluence at the end of the first dipole can see this slight kick on the y direction that obviously get larger and larger.

I am pretty sure it is a geometry problem because when I remove the vertical tilt of the beamline, the beam gets through the magnet in the correct place as you can see in the next picture .

I hope that this make the situation clearer and if you need any other clarifications just let me know. Also, please note that I am currently at CERN so if you think it is better we can meet in person and I can guide you through my model as I understand that might be difficult without the right context.

Best regards,
Matteo

Hi Matteo,

thank you for the clarification. Can you send me the input where you removed the vertical tilt of the beamline? I can run them side-by-side and see what happens.

I did not see any kicks when using a USERDUMP to plot the trajectories of pions, but you should try to do the same.

If I understand your argument, you are saying that the rotations you apply do not break the symmetries of the problem in any way, (or they do so so far awaw from the magnets, that they are approximately conserved). Meaning, the beamline with the tilting is identical up to a rotation to the one laying flat, and so any physical result would have to be identical in both frames. If that is your reasoning, I agree. One has to prove that the symmetry is in fact sufficiently conserved.

I think with the other input and being able to compare results I should be able to see what is wrong, but if not then yes we can try to meet in person. For now it is good to have the discussion here, so other users with similar issues can benefit as well.

Stefano

Dear Stefano,
I will try on Monday to track the pions with a USERDUMP and in the meantime I can send you the file without the tilt.
PBC_SBN_DESIGN_BDnoTilt.inp (124.7 KB)

My argument is exactly what you said; the beam does not care about this vertical tilting. I have also spoken with different people from the beam department here at CERN at they confirmed my hypothesis. Also, from my understanding of the real implementation of this is the standard way to do it when you have to change the vertical position of a beam.

Best regards,
Have a nice weekend,
Matteo

Hi Matteo,

I was wondering if you managed to look at the USERDUMP, and see if there are any kicks.

Indeed, when I run the noTilt version, I recover the “correct” y-symmetric fluence. I was also initially under the impression that you meant a rotation of the tunnel in the global y-z plane (i.e. the tilt of the tunnel), but I understand now that you meant a rotation of each individual element in x-y. It is of course more complicated than just rotating the elements in place, since the dipole magnetic field by its nature is going to divert particle motion off axis; instead of being constrained to the x-z plane defined by the tunnel floor, the magnetic field now pointing somewhat also in the neg-x-direction, and therefore particles moving in the tunnel z direction will acquire a neg-y component, i.e. approaching the floor. Therefore, to maintain coinsistency, the elements in the beamline would have to be repositioned in the tunnel. This re-positioning of the magnets themselves appears to be done correctly, but it is crucial to understand.

However, the beam itself is not rotating according to the geometry of the new beamline. It appears to be going straight along the tunnel z-axis, parallel to the floor. However, as we said above, the elements themselves are not strictly parallel to the floor (for good reasons, in order to satisfy the optics condition). But the beam then intercepts these elements at a different height than it does when the beamline is parallel to the floor, thus breaking the symmetry.

Therefore, because of the presence of the tunnel-fixed beam, the rotational symmetry argument is broke, and a difference in the fluence is not unexpected.

I hope this resolves the issue,

Stefano