RFTMEZ0: on-crest phase depending on number of cells or cavity length?

[Ikpfelix]

Hi Michael,

I want to work with the element RFTMEZ0 in order to investigate the phase slippage and to find the perfect acceleration process.

I noticed the following, what I do not understand: the on-crest phase seems to be dependent on the number of used cells (or cavity length). We use 20-cell Tesla-like cavities that are operated in pi-mode. To understand the element RFTMEZ0, I imported a 20-cell field map, a 2-cell field map and a 1-cell field map. They are simple test functions in the shape of 10 or 1 or 1/2 sine, respectively, as visualized in the picture. One cell is 0.05 m, hence 2 cells are 0.1 m and 20 cells are 1 m.

I used 10000 discrete points at each time, so the step size changes in the sdds files. The phase I have to adjust to accelerate on-crest depends on the number of cells (or the cavity length):
20-cell cavity: PHASE = 180°
2-cell cavity: PHASE = 0°
1-cell cavity: PHASE = 270°
(I converted the phases to rad in the lattice file).

Why is there a dependency on the number of cells (or on the cavity length) and what is the functional relationship?

I attached my files.

Thanks in advance,
Felix

RFTMEZ0.zip

(64.88 KiB) Downloaded 252 times

[michael_borland]

Felix,

The issue is that RFTMEZ0 has set up the phasing of the fields before it performs integration. It does this by assuming that the fields reach their peak when the *drifting* particle reaches the center of the element. This results in a ~180-degree phase difference between your 2-cell and 20-cell cases, because the difference in the location of the phasing point is an odd number of cells.

It's also important to realize that when you have multiple RFTMEZ0 elements, they'll get independently phased unless you specify that they have a common phase reference using the PHASE_REFERENCE parameter. If the elements are part of the same physical element, it is essential to do this.

In the end, the best approach is to perform a preliminary scan or optimization to find the phase for maximum acceleration. The attached files show how to do this.

--Michael

[Ikpfelix]

Hi Michael,

Thanks for your quick response, your explanation makes the behavior comprehensible.

Thanks also for your optimization script! I have a few questions regarding this:

1) As an optimization term you use pAverage once and pCentral once. Actually, I have already asked myself at some point, which is more suitable or why exactly is there a difference between this quantities.

2) I had previously played around with ACCURACY and with N_STEPS and can see an influence on the final momentum.
If I use METHOD="non-adaptive runge-kutta" both ACCURACY and N_STEPS influences the final momentum but only for N_STEPS the computing time increases.
If I use METHOD="runge-kutta" both ACCURACY and N_STEPS influences the final momentum and for both the computing time increases.
In your example, you used METHOD="non-adaptive runge-kutta" and set ACCURACY=1e-5.
Can you explain more exactly what ACCURACY and N_STEPS does? Is N_STEPS a kind of accuracy? My first naive thought was that an accuracy like 1/N_STEPS arises but then it would not make sense to be able to choose ACCURACY itself. What exactly is the difference between ACCURACY and N_STEPS? To what extent does it depend on the chosen METHOD?

3) Supplementary to the previous question: is the imported field interpolated by elegant or is the integration by elegant limited to the discrete steps given in the imported file?

4) I am not sure why you used "sddsprocess -pipe -clip=0,1,invert" in the run.sh since there is only one row in the result of "sddscombine testCrest02.finc testCrest20.finc -pipe=out". What is the effect/idea of sddsprocess in this case? I am familiar with "sddsprocess -pipe -clip=0,1,invert" in the case of a multi-row sdds-file.


Thanks again,
Felix