Comment on the beambeam ipynb
Hi, here my comments.
In this page, we showed the different properties of the beam-beam element in MAD-X as well as the way it is implemented regarding the tracking module and the different flags such as bborbit* or onepass.
Why the * on bborbit?
As general remarks, it is worth noticing that the kick induced by a beam-beam element is not normalized to the beam energy. Moreover, the beam intensity specified by the user corresponds to the one of the weak beam that is the beam one is tracking. In order to modify the intensity of the strong beam and therefore the strength of the beam-beam kick, one can modify the charge argument of the beam-beam element. Finally, the bbdir argument of the beam-beam element plays also a very important role since it sets the direction of the opposite beam. If this argument is set to +1, the directions of the two beams are the same, and the kick vanishes.
I would be more general, saying that the definition of the beambeam is strongly coupled with the definition of the weak beam (MAD-X is implicitly assuming a fully symmetric collider as for the nominal LHC). I would stress that the "kick vanishes" when the beam direction =+1 only for ultra-relativistic beam (see space charge for low energy). I would stress that the beambeam assumes always co-linear BB interaction. In the body of the document, I would explicitly make the example of a 6.5 TeV weak proton beam colliding with counter-rotating e- beam at 2 GeV with npart=3e9.
In this note we dealed
dealt, hint: use the spell check in VS Code**
also with offsets of the strong beams, this was used to understand better the way the tracking module and the dipolar effect of the beam-beam element (through the bborbit flag) are implemented in MAD-X. We summarize here very important statements that compose our conclusions regarding this study:
- If the bborbit flag is set to True, MAD-X will take into consideration the dipolar effect of the beam-beam element on the closed orbit.
And on the beam trajectory. Have a look to the px in the twiss table. In general, I see that you are not putting emphasis on the beam trajectory (non periodic but still affected by the dipoles). Indeed I think that to clarify it one should make an example (perhaps before introducing the non-linear lens) with a dipole kick. The problem of the document is that you are not considering as output the summ/twiss table, so the information on the trajectory/closed orbit is lost. I would add, something like: This will be visible in the TWISS table, where the closed orbit or trajectory (for the period and for the line, respectively) is defined wrt the reference orbit. The reference orbit exists both for period and for the line.
- If one considers a transfer line, no closed orbit exists and the effect of the bborbit flag after tracking does not make any sense.
It does, in the sense that the px of the trajectory is changed (see the TWISS table). In this specific case, beambeam at #e, the effect is not visible if one do not look at the px inthe TWISS table.
To overcome this issue, one must set the onepass flag of the tracking module to True so MAD-X will no compute a closed orbit. Once this is done, the effect of the bborbit flag becomes irrelevant.
I would not refer to an "issue". Up to now we consider dipolar kick with respect to the period-twiss (CO) and line-twiss (trajectory). We tell MADX to solve the lattice as a period or a line in the twiss syntax. If it is a period the TWISS needs to find the CO to period-twiss. There is another important ingredient: the "track" command. When we ask to track, we need again to specify if we are considering a period or a line, and this is possible with the onepass flag. BTW, the track command express the particle position wrt the CO (onepass=false)/reference (onepass=True) and not to (always) the reference orbit as the TWISS does (note the potential confusion to name x-twiss as the x-track even if they are relative to a different frame).
- If one considers a circular machine, the onepass flag should obviously be set to False (default value). Regarding the induced kick by the beam-beam element, the tracking results will the same, no matter the bborbit flag. This is due to the fact that the tracking is always done with respect to the closed orbit.
- On the other hand, the bborbit orbit flag, in the case of a circular machine, will indeed modify the closed orbit that one can read from the Twiss table. If it set to False, no dipolar component is taken into consideration and the closed orbit vanishes. If it set to True, the beam-beam element acts also as a dipolar kick on the closed orbit and one can see through the Twiss table that the closed orbit does not vanish anymore.
Again, the bborbit flag modifies also the beam trajectory of the line. I think it is important to clarify the vocabulary with "period" and "line" (we use them in a very specific sense). And to note that also unstable period can have a CO.
The authors hope that this note will bring a little bit of light in the darkness that is the world of conventions in MAD-X, and encourage you to share and discuss with them in case of problems, or questions.
This is not only the darkness of MAD-X, these are general problem of vocabulary (period, line, CO, reference orbit, trajectory,...) and concepts (what does the TWISS and the TRACK as concept and not as implementation). I found it a very interesting exercise and I encourage you to make a second interaction, putting in evidence as the period/line/CO/RO/TJ are dealt in MAD-X syntax. I would start with a simple dipolar kick to show the problem. The concepts are there but I do not see the logic properly emerging.
- difference between period/line
- introduction of reference orbit (always defined), closed orbit (defined for period), trajectory (defined for line).
- introduction of the optics: the period-twiss (it needs a closed orbit) and the line-twiss
- introduction of the tracking: the period-track anf the line-track.
- then the beambeam. Perhaps the first four points can be addressed in a separate document.