Confusion to the RFMODE element

[Shichang]

Hello Michael,
Here I utilize three active cavity in the ring tracking,with one fundamental frequency,the other two are second-harmonic cavity and third-harmonic cavity.Then I got some confusions to the tracking results.
1.The unit of the PhaseCavity should be rad ? I thought it may be a small bug.
2.The result PhaseCavity and the PhaseGenerator always be the phase_setpoint subtract 90 degree,is it a common rule?
3.I understand that the VCavity and PhaseCavity in the *.rfm result are the final RF parameter when a bunch pass through a RF cavity,is it correct?


Thanks for your patience to explain my confusions.
Best regards,
Jiang

[michael_borland]

Jiang,

1. The phase setpoint is in degrees, but phases for the output files are in radians. Units for inputs are listed in the manual, and you can check units in output files using sddsquery.
2. Yes, you are correct that the phases in the output file also use a convention that is 90 deg shifted from the phase setpoint. If the feedback has settled, the PhaseCavity values (converted to degrees) will be PhaseSetpoint[deg]-90. The PhaseGenerator will be different from PhaseCavity, of course, if the cavity is detuned.
3. VCavity and PhaseCavity are averaged over the particles in the bunch, as is "V" (which is just the beam-induced field). The *PostBeam quantities are the values after the bunch has completely passed.

Sorry for the confusion of different units and conventions! I'll add some notes to the manual to clarify things.

--Michael

[Shichang]

Hi Michael,
Thank you for the timely reply!
Furthermore,I met another problem recently when utilizing the RFMODE element in ring tracking.
Like I said above,I use three active cavity in the lattice with given harmonic number,and I set the parameters in RFMODE. But the beam always get lost in the initial 50 turns.I had checked the *.rfm output,the beam_induced field haven't been established completely.Since I reference your bunchlengthingCavity code,and ramp the total charge over 9000 turns in slow RF feedback.However they get lost in the initial 50 turns and I don't know the reason. I used 756 bunches with average current 30mA, and including only 1 particle in each bunch due to the limited computation speed.The attachments are the lattice and .ele file.
Could you give me some advice?

Best regards,
Jiang

[michael_borland]

Jiang,

My prior experience is that three-cavity systems are very difficult to stabilize. We tried it for the APS-U and could never get stability above 20 mA.

I didn't see any obvious problems with your files. A first step in investigating this is to convert two of the three cavities to RFCA elements, so they are always perfectly powered. (Set fiducial="light" to avoid phasing problems with a multi-bunch beam.)

--Michael

[michael_borland]

Jiang,

Ok, I found one problem: the input phase convention on RFMODE is different from the phase convention in the output files. So you shouldn't add 90 degrees to the PHASE_SETPOINT values. The RFMODE element uses the same convention for PHASE_SETPOINT as RFCA uses for PHASE. By using the following, I got the beam to last a while longer:

Code: Select all

RFM1: rfmode,freq=166600378.9227662086,record="%s.rfm1",sample_interval=5,bin_size=1e-12,n_bins=2000,&
      amplitude_filter="AmpFeedbackFilters.sdds",phase_filter="PhaseFeedbackFilters.sdds",&
      Q=5e8,beta=3.734194789610459e+02,Rs=6.7900e+10,drive_frequency=1.666003368479859e+08,v_setpoint=7.15759255929481e6,&
      phase_setpoint="139",update_interval=5,N_cavities=1,bunched_beam_mode=1

RFM2: rfmode,freq=333200660.6661608815,record="%s.rfm2",sample_interval=5,bin_size=1e-12,n_bins=2000,&
      amplitude_filter="AmpFeedbackFilters.sdds",phase_filter="PhaseFeedbackFilters.sdds",&
      Q=1e9,beta=1.746625237192438e+02,Rs=1e11,drive_frequency=3.332006736959718e+08,v_setpoint=3.59075757209399e6,&
      phase_setpoint="6",update_interval=5,N_cavities=1,bunched_beam_mode=1

RFM3: rfmode,freq=499799590.161690414,record="%s.rfm3",sample_interval=5,bin_size=1e-12,n_bins=2000,&
      amplitude_filter="AmpFeedbackFilters.sdds",phase_filter="PhaseFeedbackFilters.sdds",&
      Q=1e9,beta=4.768280568098270e+03,Rs=9.3500e+10,drive_frequency=4.998010105439577e+08,v_setpoint=0.901270230331987e6,&
      phase_setpoint="230",update_interval=5,N_cavities=1,bunched_beam_mode=1

Let me know if you see further problem.

--Michael

[Shichang]

Michael,

The result seems to be better,which could survive over 300 turns.However the beam loss energy after these turns.Here are my two more questions:

• 1.From the *.rfm output of the tracking result,the RF feedback system doesn't seem to work very well.The voltage and phase of three cavity are changed a lot from the initial setpoint. Does it mean that the parameters of the feedback file *.sdds are not set correctly?

• 2.Besides that,I understand that the final beam induced voltage are decided by the average current and the tuning angle of the cavity.The quantities Phase in the *.rfm file,which described as the phase of beam induced voltage,is it have a rigorous relation with the tuning angle?

Best regards,
Jiang

[michael_borland]

Jiang,

If I use the RFCA elements in your lattice file, the beam is also lost. Adding up V*sin(phase) for all the cavities gives 4.38 MV, whereas the energy loss per turn is only 2.8 MV. This needs to be fixed before switching to RFMODE elements.

Once you've got the right voltages and phases, you'll need to decide how to detune the cavities, as they are presently all on resonance. Typically you'll need to detune by -10 to -20 kHz, but that depends on a lot of factors. You can use the TAPAs Android app to help figure out the matching and detuning (look for Main Cavity Beam Loading under Electron Storage Rings).

Even after doing that, you may indeed find that the loops are too slow. You can try to resolve this by ramping the current up more slowly, or adjusting the loop parameters. As I mentioned earlier, we tried to stabilize a three-cavity system for APS-U and never succeeded above 20 mA, so I expect this will be very challenging.

You can make your simulations much faster at this stage by switching to concatenated matrix-based tracking. It won't matter for now. See the attached file for how to do this. Also, you should switch off quantum excitation since you have only 1 particle per bunch. Set QEXCITATION=0 on the SREFFECTS element.

--Michael

[Shichang]

Hi Michael,

We met a problem in the recently study on RFMODE.
In a passive harmonic cavity defined by RFMODE, the cavity phase is connected to the tuning angle,which is given by the resonant frequency.Their relationship can be expressed a tangential function,and the cavity phase is the tuning angle plus 90 degree.Here is the problem,suppose the cavity phase which I need to lengthen the bunch is 300 degree,so the tuning angle is 210 degree.However,the code may do the calculation through the resonant frequency,and the result is 30 degree rather than 210 degree.Since the periodicity of the tangential function is 180 degree.Is there any way to change the domain of definition ?

Best regards,
Jiang

[michael_borland]

Jiang,

The phases are computed using the atan2(Imag(V), Real(V)) function, which has a range of [-pi, pi]. It may just be a matter of the convention used in defining phi=0.

--Michael

[Shichang]

Hi Michael,

Thanks for your patient reply! We found an another problem that the bunch length calculated by the element RFCA and RFMODE are different.
The double rf system is detuned at 200mA under our main ring lattice.Near the optimal lengthening condition,the tracking result of bunch length is different from the calculation.Then we read the data "V" and "PHASE" from the passive cavity defined by RFMODE and track again utilizing the RFCA element,the bunch length is larger than prior result.

Furthermore the dCt varies with Cdelta given by the RFMODE seems strange.

Feedback system seems work well,and the file is in the attachment.

Best regards,
Jiang