Symplecticity in low-alpha tracking

[Kruschinski]

Hello everyone,

We would like to do some tracking investigations in a low-alpha lattice involving alpha buckets.
But right from the start I see some very strange behavior in the longitudinal phase space. It is still a regular RF bucket, but the fixed point nevertheless has a momentum offset, and there are sudden jumps in momentum at specific times (after 3.5 ms, 7 ms, 14 ms...).

I have checked the one-turn matrix given by &matrix_output for symplecticity and have found that it is actually not symplectic? But how can this be since I am only using symplectic elements (CSBEND, EDRIFT, KQUAD, KSEXT, KOCT)?

I would appreciate any hints on what the problem here might be.

Thank you,
Arnold

[michael_borland]

Arnold,

Regarding the symplecticity of the matrices, you have to realize that elegant uses t (not -t) as the time variable. So the symplecticity check is to look at U-M*U*Transpose(M), with

Code: Select all

U={{ 0,  1,  0,  0,  0,  0},
   {-1,  0,  0,  0,  0,  0},
   { 0,  0,  0,  1,  0,  0},
   { 0,  0, -1,  0,  0,  0},
   { 0,  0,  0,  0,  0, -1},
   { 0,  0,  0,  0,  1,  0}}

Note that U[5,6] and U[6,5] are different in sign than usual.

As for the jumps, these are probably a result of limited numerical precision. Elegant works with the actual arrival time, rather than t-<t>, as the time coordinate. This has many advantages, but also introduces precision limitations that can result in small phase jumps. You can reduce this effect by setting CHANGE_T=1 on your RFCA elements.

The momentum offset can result from errors in setting the rf frequency. For the most accurate results, track a single particle one turn, look at the arrival time, then use that to compute the rf frequency, taking care not to truncate or round.

--Michael

[Kruschinski]

Dear Michael,

thank you, I did not realize the different sign in the longitudinal coordinate, with the changed matrix the symplecticity check now gives a positive result.

Since my original post I have made a few more runs investigating the momentum offset. I have reproduced the behavior for different lattices, and it is also present for high momentum compaction (albeit not as pronounced).

I even found an official example where it is reproduced:
If I run the PAR/synchrotronTune example, unchanged, I get the following motion in longitudinal phase space:

There is a momentum offset on the fixed point as well (it is quite small in the example, but still significant). The example uses radiation damping and rf_setup, so surely the rf frequency is correct? I have also tried slightly changing the RF frequency for my case, but any deviation just causes the phase space ellipse to slowly drift away in time). (Incidentally, I also obtained the frequency value I use from a tracking run with rf_setup.)

Is this a more fundamental issue then? I feel the jumps are a secondary problem to this...

Thank you very much for your help,
Arnold

[michael_borland]

Arnold,

Those small momentum offsets result from small errors in the path length, which is an issue with the symplectic integrator for dipole magnets (e.g., CSBEND, CSRCSBEND). There are three solutions to this. First, you can increase the number of slices (N_SLICES parameter) and use the 6th-order integrator (INTEGRATION_ORDER=6). Second, you can set REFERENCE_CORRECTION=1, which will compensate not only for the path-length error but also small (x, x') errors. Finally, you can adjust the rf frequency based on a measurement of the time of flight of a reference particle, after carefully setting it up so the reference particle starts on the closed orbit; in some ways, this is best because it will allow you to account for synchrotron radiation effects, but it takes more work.

You can also combine these, of course.

--Michael

[Kruschinski]

Michael,

thank you so much for your help!
All the issues are solved now. If I use the 6th order integrator with REFERENCE_CORRECTION in the bends the result is dramatically improved, only the spurious phase jumps for long term tracking remain. These I can remove by using CHANGE_T.

I am a bit unsure of the dangers of using these options, in the manual you write that REFERENCE_CORRECTION should be used carefully. I will keep this in mind for my use case. Are there any additional pitfalls when using REFERENCE_CORRECTION and CHANGE_T together?

Arnold

[michael_borland]

Arnold,

There aren't any dangers in using CHANGE_T=1 and REFERENCE_CORRECTION=1 together.

The warning about using care with reference correction was intended to address the possibility that someone would use reference correction to compensate for having a grossly inadequate number of slices. It think you've been careful in choosing other parameters so you shouldn't worry.

--Michael

[Kruschinski]

Good to know Michael, I agree the number of slices should be adequate. Thanks for elaborating and many thanks again for your help!

Best regards,
Arnold

[michael_borland]

Arnold,

I should note there is one pitfall to using CHANGE_T=1 on RFCA elements: it only works correctly if all rf elements have frequencies that are harmonics of one another. In addition, one should set CHANGE_T=1 on the rf element with the lowest frequency. Finally, no other time-dependent elements (like bumpers) can be included in storage rings if CHANGE_T=1 is employed.

--Michael