Elegant users forum

Hi Michael,
I am trying to simulate a linac with the elegant. The travel cavity is modeled by the element RFCW.

There are several questions hopefully you can help me.
1, Assume I have a 50 cells in total, in the RFCW, which parameter in this RFCW element give the information of number ofcells in total.
2, Numerically, how elegant simulate particle motion in RFCW element? If N_KICKs is set as 50 also, can I simply consider each longitudinal kick is the same as that in RFCA element, and each kick also corresponds to one cell correspondingly?

3, If I am interested in the transient beam phase space evolution along the cavity, how can I print the particle cord out? Split the cavity into several sub-cavities and insert watch element in between?

4. in the attached file, I prepare a very simple lattice, where an RFCW element is applied there and phase of this cavity is set to 0. For a special case, I set only one particle with no energy and longitudinal position offset. I expect there should be no particle energy change. Whereas, compare the data of p in the initial and final distribution (LINAC2.INPUT,LINAC2.OUTPT), the p vales varies.
Did I make a mistakes there?

Thanks for your reply.
yours Chao

Chao,

The RFCA element is a special case of the RFCW element, using the same code for simulation of the accelerating fields. The CELL_LENGTH parameter on RFCW is only used for scaling of the wakes, which are assumed to be given for a single cell. If your wakes are for a full structure, then you can set CELL_LENGTH equal to the total length L.

The N_KICKS parameter, if non-zero, for RFCA/RFCW controls the number of integration steps. It is unrelated to CELL_LENGTH.

If you want to see the phase space evolve along the linac, then yes, splitting the structure and inserting WATCH elements is the correct approach. It is best to split the structure into sections of length C/FREQ, then use PHASE_REFERENCE to ensure that the elements are consistently phased. The reason you see some small acceleration in your test case is that your initial beam is not fully relativistic, so it moves slightly in phase as it transits the cavity. When N_KICKS is non-zero, RFCA/RFCW interpret the PHASE parameter as the phase at the start of the cavity. If you want a more intuitive (but less correct) result, use N_KICKS=0 to invoke the idealized full-relativistic matrix mode.

--Michael

Dear Michael,

Thanks for your replying. However, I have to ask one more round to confirm my understanding.

"The RFCA element is a special case of the RFCW element, using the same code for simulation of the accelerating fields."
and
"The N_KICKS parameter, if non-zero, for RFCA/RFCW controls the number of integration steps"

Confused about this process again. If n_kick=1, I think RFCA/RFCW kicks the particle one time (longitudinal momentum change), then particle passed through the whole cavity with length L. I would say the transfer matrix could be simplified as multiplication of a longitudinal kick M_{Long_Kick} and drift with length L M_{Dr_L}.

Assume I set 2 kicks in the cavity, how this longitudinal kick and drift are splitted, especially the exist particle velocity changes in this process. Maybe I am thinking something fundamentally wrong. Please correct me and explain more on that.

yours Chao

Chao,

The kick algorithm is drift-kick-drift, which is a higher-order integration than kick-drift (O(h^2) vs O(h)).

If N_KICKS=0, an analytically-derived transfer matrix is used. That matrix assumes ultra-relativistic motion, which gives constant phase.

--Michael

michael_borland wrote: ↑

14 Jun 2023, 17:42

Chao,

The kick algorithm is drift-kick-drift, which is a higher-order integration than kick-drift (O(h^2) vs O(h)).

If N_KICKS=0, an analytically-derived transfer matrix is used. That matrix assumes ultra-relativistic motion, which gives constant phase.

--Michael

I see, which means if n_kicks=50, there will be 50 "drift-kick-drift" simulated in this element. For each sub “drift-kick-drift", the length of this sub “drift-kick-drift" is L/n_kicks, where L is the total length of the cavity, am I right?
Then I guess the cavity field at the the nth sub kick for the ith particle can be obtained by
V_{n,i} = (Volt/n_kicks) * sin( 2*PI*f/(\beta_i * c_{light}) * (L/n_kicks + z_i) + Phase),
and z_i is the particle position reference to the "synchrotron particle".

If I git it correct. It seems like set n_kick number as the number of accelerator cell number is a good strategy.

The reason I ask this is due to confusion caused by numerical simulations based on independent variable time (T) and position (Z).
Especially there is time depended element and the electrons speed are not constant.

yours Chao

Chao,

Yes, I think you have it right. The RFCA/RFCW elements with N_KICKS>0 integrate (t, E) as a function of z. At the start of the integration, elegant converts the (z, delta) coordinates to (t, E) using the known velocities of each particle, and only converts back at the end of the element. The propagation from one kick to the next is fully relativistic, so it includes the time of flight based on the energy after the kick, rather than the initial beta. The structure is assumed to be designed for a speed-of-light particle.

Making the number of kicks equal to the number of cells is reasonable, but probably excessive for most cases, since the velocity doesn't change much. Also, if you want to split the structure and put diagnostics between the parts, you need to ensure that the parts have lengths that are integral multiples of c/frequency and use a common PHASE_REFERENCE to ensure that elegant enforces the fact that the separate RFCA/RFCW elements are all driven by a common source with a known phase relationship.

--Michael

Dear Michael
Thanks for a nice discussion. I think I got it.

There is one more question I need you help. It relates to the subject we discussed. At this moment, I am prepare to simulate a linac.
Unfortunately, on top of the cavities, there are some quads, which mean there existing element overlapping in the lattice. At this moment, I am trying to splitting the cavities into several sun-cavity, and among these sub-cavities, a very short quad are inserted in between to representing the over-lapping of the quads and cavities.

According to the discussion in previous posts, seems like setting n-kicks =1 can ensure a more consistent results, is it?
Please correct me if I am wrong. The detail of how I splite the cavity can be found in the attached file.

Thanks again.
yours Chao

Chao,

We have the same configuration with the APS linac: quadrupoles over top of the structures. I also split the linac into many sections, then put very thin quadrupoles between them.

Using the kick-based model should be more accurate, but I think you'll see an effect only if your beam is not fully relativistic. The matrix-based model should be quite good for your >25 MeV beam, and may be faster as well.

--Michael

Dear Michael,

Thanks a lot for your reply, and I need your help of one more thing, which related to the emittance growth in the linac.

As discussed in the previous post, I am now cutting the cavity into sub-parts and inserting quadrupoles in between to model the overlapping between cavity and quadrupoles. These quadrupoles, overlapping with cavities, are modeled by thin lens with a very short length (1.E-6 m,). In the attached file, you can find how it is modelled, for example in LINAC.lte between line 37 and 52.

Here is my question:
With the lattice file attached, I found that the normalized emittance is significant increased at the place of these thin lens quads are located. These elements where the emittance starts to grow are defined at LINAC2.lte file, between line 46 and 52.
Actually, I am expecting the emittance stays as a const value. Is there any thing wrong in my files?

run command:
elegant LINAC2.ele -macro=root=root,vol=0,rms_s0=1.eE-3,rms_p0=3.E-3,npart=1000,MeV=50

Thanks for your kindly help.
yours Chao

Dear Michael，

I got the answer of my previous post.
Change KQUAD element to Quad and limit transfer matrix order to 1. The emittance growth in linac is gone.

Thanks a lot.
yours Chao