rfmode element in a active harmonic cavity

[li.chao]

Dear Michael，

The attached file includes an elegant input for my recent simulation, single cavity (RFMode element) only. It also includes 3 figures for comparison among the result between elegant and our code developed in house. Still one macro-particle in one bunch.

The are several findings in my study:
1. in our version of pelegant, set watch element as
"wp0: WATCH,FILENAME="%s.wp0", MODE="parameters",FLUSH_INTERVAL=100,startPID=1,endPID=2",
it gives out the average particles with particleID=1 and particleID=2, but not particleID=1 only. Thus, in the simulation, I just set startPID=endPID in my simulation, ignoring data in *.wp files.

2. with the script in the attached file, the main cavity rfmode is set as:

"MCRFMode: RFMODE, RS=40.8e6, Q=29600, beta=3.0, bin_size=1e-12, n_bins=100, &
FREQ="f0 ringHarm * 13.943e3 -", DRIVE_FREQUENCY="f0 ringHarm * ",&
V_SETPOINT="V_Mc", PHASE_SETPOINT="Phi_Mc", &
PRELOAD=1, PRELOAD_HARMONIC="ringHarm", bunched_beam_mode=1, &
N_CAVITIES=1,RECORD="%s.rfmc",sample_interval=100,flush_interval=100"

In this setting, I expect the generator voltage vector \tilde{Vg} is a fixed value since I did not put any cavity voltage feedback.
Whereas, the output in *.rfmc shows that the generator voltage amplitude abs(\tilde{Vg})=VGenerator is constant, however, phase of the generator arg(\tilde{Vg})=PhaseGenerator varies as function of time. Why the generator voltage vector in this setting is not a fixed value?

3. The argV.png and absV.png shows the compares of beam induced voltage between elegant and house developed code. Again what I found is that the abs(Vb) agrees well, however the arg(Vb) does not. I would like to discuss with you about my approaches used in code.
In attached SPBeam.cpp, between line:1328 and 1333, for each bunch beamVec, I get the time distance from current bunch to next bunch, beamVec.timeFromCurrnetBunchToNextBunch.

beamVec.timeFromCurrnetBunchToNextBunch is applied for beam induced voltage rotate and decay in SPBunch.cpp, between line 379 to line 433.

Do you think anything could be wrong in my approaches?

yours Chao

[michael_borland]

Chao,

For item 1, we'll be releasing a bug fix soon for this issue.

For item 2, the reason the generator phase varies is that it reflects the change in arrival time of the bunches, which reflects their finding equilibrium positions under the influence of beam-induced rf transients. If you reduce the average beam current, you'll see that the generator phase variation decreases, since the bunch arrival times are no longer modulated.

I'm not sure about item 3. It's hard for me to find the time to study your code. Our method is described in
https://accelconf.web.cern.ch/IPAC2015/ ... pma006.pdf

--Michael

[li.chao]

Dear Michael,

Great thanks for your reply. I think I got the approaches used in elegant for RFMode simulation.
The confusion always comes from the reference frame chosen for rotation and "head" or "tail" particle convention.
In my previous simulations, I always chose the reference rotation frame with reference to n*tRF, where n is an integer number and n*tRF representing the adjacent bunch separation in time. In this frame, the generator vector rotate phase is n*2pi. According to particle arrived time \deltaT reference to reference particle, different particle got a momentum kick respectively.

In the attached file, there shows two benchmarks, one result is obtained with condition single cavity (RFMODE element), and the other is that the main cavity is ideal (rfca) plus a passive harmonic cavity (rfmode). In both cases, elegant and CETAsim results are agree well with each other.

As to the approaches for cavity feedback, I need a further time to digest the approaches in your paper. Will let you know if there is further question on that.

Thanks for your nice discussion. It does help a lot.

yours Chao

[li.chao]

Dear Michael

I am doing benchmark when there are multi-particles in bunches in beam loading simulation.
One thing I would like to confirm is about the approaches used in elegant.
For example, when we cut one bunch into bins, I assume in elegant, the bunch passes through the cavity in a bin-by-bin process. During this process, electron particles in each bin lead to a "bin beam" induced voltage, and this "bin beam" induced voltage rotate and decay till the following bin comes.

Do I get the right understanding about what elegant is doing for multi-particles in bunches in beam loading simulation？

yours Chao

[michael_borland]

Chao,

Yes, that is a good description of what we do.

There's also a "binless" mode that uses the individual particles to do the same thing. It's pretty slow but can be used for checks.

--Michael

[li.chao]

Dear Michael

Thanks for your reply. Then we are using the same algorithm for this simulation. Another thing has to take case is the time distance between bunches when bunches are soft. Within bunch, it is bin-by-bin process. Among bunches, the time distance from ith bunch to (i+1)th bunch become the distance from the last bin of ith bunch to the first bin of (i+1)th bunch.


In the attached file, it shows the compare between elegant and CETA in a single RF system. Data are from 1, 101, 201,301,401 501 601 701 and 801 turns. As usual, I compare the beam induced voltage, generator voltage and cavity voltage. With 200 bunches in total and each bunch includes 1000 macro-particles. From the results, you can see they are basically agreed with other in the single RF system.

One thing bothers me is that my results show more noise than elegant results. As you know, further, the noise of the cavity voltage sampled may have influence on the cavity feedbacks. Right now, my approach to get the (beam induced, cavity, generator) voltage for each bunch is to do average among bins weighing my particle number in bins. However, it is still not as smooth as elegant. Would you mind comment a little bit, how can I avoid the noise during the (beam induced, cavity, generator) voltage vector calculation?

One step further, I also compared the double rf system. In simulation, the same subroutine for transient beam loading is shared by the main cavity and harmonic cavity. What I found is that the (beam induced, cavity, generator) voltage of the main cavity and harmonic cavity roughly agrees in the first 100 turns. Results beyond 100 turns are not comparable at all. Do you have any feeling about which part in the algorithm might lead to the discrepancies come?

yours Chao

[michael_borland]

Chao,

I don't do anything special to control noise. My algorithm is similar to what you describe: I make weighted sums of the quantities for each bin. I do this for real and imaginary components, then compute the phases from the average values.

I'm not sure why a discrepancy develops as the simulation runs. Often this sort of non-physical behavior results from a subtle program bug. You might try using a program like valgrind to check for memory access issues.

Also, do the simulations agree when there is a single bunch, or a uniform train of bunches? If so, that might be a clue.

--Michael

[li.chao]

Dear Michael

Thanks for your nice discussion and suggestion. I did not know valgrind before. And I looked into it during the past days. It is a very nice tool.

I also look into my code again. All of a sudden, I realize my average process to get the average voltage vector in polar coordinate system is not suitable, especially when the voltage vector oscillation around -pi (or pi in another sense). I modified the code to Cartesian coordinates. Now I got results the same as elegant produced. In the attached file, you can find a slide there. It shows benchmark results.

Still there are two more things:

1, with current Pelegnt version at desy (2021.3.0), the *.wp file does not produce KAverage correctly. If run script elegant, the KAverage value are just as expected.

2. I would like to know how to set different bunch charge for different bunches. Right now, I generate a train.sdds file which includes all bunches information as input to "&sdds_beam &end" namelist. Each page represents one bunch. The attached file shows how I use elegant and the train.sdds file I generate.

run command: "elegant Tracking.ele -macro=root=200mA,qin=1556e-9"

It actually assumes that all bunch charge in train.sdds are the same as default.

I noticed that there is a parameter called Charge in each page of the train.sdds. Can I modify this parameter "Charge" directly there (page by page) to specify different bunch charge values? Or how should I prepare the train.sdds file?

yours Chao

[michael_borland]

Chao,

I'm glad to hear that you are now getting the same results as elegant after finding a problem. I'll look into the KAverage issue.

To vary the charge per bunch in elegant, at present you have to vary the number of particles per bunch. The reason is that elegant assigns the same charge to each macro particle. I hope to improve this in the near future.

--Michael