rfmode element in a active harmonic cavity

[li.chao]

Dear All,

This is Chao. Recently, I am looking back to the transient beam loading simulation with rfmode element in elegant. What I am trying to do is simulate a double rf system, where the main cavity is ideal (RFCA) and the harmonic cavity is rfmode element. With the setting in the attached file, the coupled bunch growth rate due to the harmonic cavity is below the radiation damping till 100nC. To maintain the harmonic cavity voltage and phase, a cavity feedback is also applied to the harmonic cavity. In the attached files you can see the settings prepared for running.

Here is my question:
1. I assume the cavity feedback can maintain the condition \tilde{Vc}=\tilde{Vg} +\tilde{Vb}, where \tilde{Vc},\tilde{Vg},\tilde{Vb} are the cavity voltage, generator voltage and beam induced voltage vectors. However, when I feed a very small shut impedance Rs in rfmdoe (harmonic) element, leading to a very small beam induced voltage \tilde{Vb}, I expect the (harmonic cavity) rfmode element will perform as a ideal cavity like RFCA element. So I expect almost an ideal bunch lengthening effect, however, the simulation results does not give any bunch lengthening. I probably have a wrong understanding on setting in the rfmode element, would some one help me to figure which part I made a mistake?

2, in my setting rfmode settings, why my output for rfmode cavity feedback ( feedback_record="%s.rfhc-fb") does not have any data there? Any mistakes in the settings?

Great thanks.
yours Chao

[michael_borland]

Chao,

I think the problem was just some typos in the definition of the RFMODE element for the harmonic cavity. See attached.

Also, be sure that the macro <qin> is defined to something non-zero.

I did see output in the feedback file. Please be aware that asking for this output at small intervals will slow things down.

--Michael

[li.chao]

Thanks Michael. I got it.
I am also trying to do some benchmark study between elegant and a code developed in house.
Will let you know my process and it will be great if I can get further assistant from you.

Thanks again.
yours Chao

[li.chao]

Dear Michael,

I am trying to run elegant with setting as shown in the attached file. In the setting, still the main cavity is the ideal RFCA element and the harmonic cavity is the rfmode element. Since the harmonic number is 3840 in our ring, the filling pattern is expressed as
3840 = 2* (100*10+920), where I have two periodic bunch trains, each bunch train includes 100 bunces. 10 empty rf buckets between bunches within one bunch train and 920 empty buckets between bunch trains.

For simplicity, in the simulation, one bunch is represented by one macro-particle.

In the harmonic cavity "rfmode" settings, there is no cavity feedback, in this scene, I expect the generator phase and voltage both does not change during the simulation. In my understanding, when the cavity feedback in on, then \tilde{Vg} is changed, leading to a variation of the net cavity voltage changing of \tilde{Vc}=\tilde{Vg}+\tilde{Vb} that beam feels.

However, with the settings in the attached file without cavity feedback, the simulation results in *.rfhc shows that generator voltage and phase both vary as function of tracking turns and bunch index. Why the generator voltage and phase change in my settings?

Another thing is about data "dCt" in the *.wp* files. I found all of the dCt data is the same in the *.wp* files. Is what expected?

yours Chao

/////////////////////////rfmode Harmonic settings //////////////////
HCRFMode: RFMODE, RS=1.8e6, Q=17000, beta=5.3, bin_size=1e-12, n_bins=1000, &
FREQ="f0 ringHarm * 3 * 13.882e3 +", DRIVE_FREQUENCY="f0 ringHarm * 3 * ", &
V_SETPOINT="V_Hc", PHASE_SETPOINT="Phi_Hc", &
PRELOAD=1,PRELOAD_HARMONIC="ringHarm 3 *", bunched_beam_mode=1, &
N_CAVITIES=1,RECORD="%s.rfhc",sample_interval=100,flush_interval=100

[michael_borland]

Chao,

Your file train.sdds has an issue: you set IDSlotsPerBunch = 1, but your particleID values are 1, 11, 21, ... This confuses RFMODE's bunch finding algorithm, causing it to think there are buckets you want to simulate between the bunches. The simulation is still the same, but the output becomes confused. Try

Code: Select all

sddsprocess train.sdds -redefine=param,IDSlotsPerBunch,10,type=long

Following that, the HC cavity log should look as expected if you filter out the buckets in the gap, e.g., using

Code: Select all

sddsplot -colum=Bunch,VCavity Tracking.rfhc -filter=col,Charge,0,0,\! -graph=sym

As for the dCt values all being the same, that has to do with a problem with the START_PID and END_PID values. The way it is programmed, if START_PID=END_PID, they are ignored. I don't like this and will change it in the future, but if you add 1 to your END_PID values you can work around the problem.

--Michael

[li.chao]

Dear Michael

The explanation of the IDSlotSSperBunch: Number of particle ID slots reserved to a bunch"

I guess I can simply set IDSlotSSperBunch value at the ith page as particleID (start_id at the i+1 page) - particleID( end_id at ith page).

Or probably the safe way is to set IDSlotSSperBunch value as the number of particle in the page. Then in each page the particleID should be START_PID,START_PID + 1,...,END_PID. And at the ith page and (i+1)th page, ensure the condition: particleID ( start_ID at i+1 page) = particleID (end_id at ith page) + 1.

Both approaches will work, right?

Would like to ensure one thing for print out setting, for example

"wc900: WATCH,FILENAME="%s.wc900", MODE="coordinate",FLUSH_INTERVAL=100,interval=100,startPID=901,endPID=902"

For the case of one particle per bunch, the setting above will print out data related to the startPID=901 particle, right?

yours Chao

[michael_borland]

Chao,

IDSlotsPerBunch needs to be the same on all pages. This isn't checked, but if it isn't done things will get messed up. The reason is that this is a global parameter that is used to group particles into bunches according to the particleID values. The page structure of the file ends up being ignored in that process.

The bunch number is computed as Floor[(particleID-1)/IDSlotsPerBunch]. So if IDSlotsPerBunch=10, particleID values 1-10 are in bunch 1, 11-20 in bunch 2, etc.

--Michael

[li.chao]

Dear Michael

Thanks for your explanation. I got it.
Assuming I have Np particle per bunch, in my script to prepare the train.sdds, I ensure that IDSlotsPerBunch=Np for all pages. And particleID in the first page varies from 1 to Np, in the 2nd page varies from np+ 1 to 2*Np...

Then, if I set only one particle per bunch, the watch element is defined as
"wc0: WATCH,FILENAME="%s.wc0", MODE="coordinate",FLUSH_INTERVAL=100,interval=100,startPID=1,endPID=2"
As suggested, endPID=startPID+1. It should print out the particle info as specified to startPID=1.

The attachment includes results from in-house code and elegant. In the settings, the main cavity is set as RFCA and the harmonic cavity is set as RFMODE element without the generator (passive cavity). Beam current is 200mA current (1mA=7.68nC). Only one particle in one bunch. The filling pattern is 3840 = 2*(100*10+920), where I have 2 bunch trains, and each train contains 100 bunches.

Then I am trying to compare the beam induced in the harmonic cavity at the 0th turn and the 1000th turn. In the attached files, there are 4 figures, giving the amplitude and phase of the beam induced voltage. I would say the abs(Vb) value agrees well between elegant and our code, whereas the arg(Vb) seems does not agree well.
As you can see, in figure 0_turns_argV.png, the beam induced phase shows a sawtooth from bunch index above 100 in elegant simulation.
In figures 1000_turns_argV_elegant.png and 1000_turns_argV_CETASIM.png, they show beam induced voltage phase. Elegant simulation shows phase oscillation around -pi, whereas our code shows different behavior, you can see in the figures.

Would you please check my elegant script, is everything there set correctly? And would you mind commenting a little about the beam induced phase of the 0th turn, why it shows a sawtooth…, and also the phase oscillation on 1000 turns?

Great thanks for your answers.
Yours Chao

[michael_borland]

Chao,

One issue with the phase plots is just a matter of the phases being close to -pi, which causes them to wrap to +pi. You can fix this with

Code: Select all

sddsprocess 200mA.rfhc -redefine=col,%s,"%s 0 > ? pop 2 pi * - : pop $ ",units=rad,select=Phase*

When you do this, you'll noticed that the phases are "noisy". That's because you have quantum excitation turned on, which is not a good approach when you are simulating an entire bunch with one particle. Set QEXCITATION=0 on SREFFECTS elements to address this.

Another issue I noticed is that your bunches are not spaced exactly by n/rfFrequency, which means that in elegant the bunches will need to execute synchrotron oscillations and damp to the correct spacing.

I couldn't change this and check whether it explains other effects (e.g., sawtooth) because I don't have the command you used to run elegant (with the values for the macros).

--Michael

[li.chao]

Dear Michael,

I thought elegant will turn turn off the quantum excitation effect once there is only one particle in one bunch. Following your suggestion, set QEXCITATION=0 on SREFFECTS elements helps to get a smooth beam induced voltage phase.

As to the bunch separation time distance, it is supposed to be n/rfFrequency as you point out. The inaccuracy comes from rpnl command used in my bunch train preparation script. In the file makBunchTrain.sh shows how I generate the bunch train.
In previous simulation, I use
frf=`sdds2stream twiss.rf -parameters=Frequency` to get the RF frequency. It seem like that it is not accurate enough. Then, I switch to the method to give the values explicitly as
line 26: frf=4.996540948545876e+08
line 27: trf=2.0013845784427e-9

I think the bunch center separation time distance now is correct as expected, which is n/rfFrequency.

The attached files, it also include file run_script.sh. It shows how I run the Pelegant.
For short, I summary the main command as:
"mpirun Pelegnat Tracking.ele -macro=root=200mA,qin=1536e-9.

After the correction above, the sawtooth is also gone.


In the attached files, I also show compares between codes. the 1st turn, 100th and 1000th and 9900th turns. Seems the beam induced phase are still not consistent with each other. (Strange, 1st turn beam induced phase agrees roughly, whereas when beam evolution, it starts to show differences between codes. )

Would be very eager to know which part I might make mistakes in code. I will organize another post to discuss that.

Thanks for your reply again and looking forward to further discussion in the coming days.

yours Chao