New fastring

[swhite2401]

This PR proposes a new implementation for the fast ring allowing to switch radiations on and off with standard lattice function.
Only one lattice object is then produced.
It is also possible to model higher order chromaticity terms with manual input. The automated generation considers only linear terms. This is safer since fit parameters have to be adapted depending on the order the the user wants to consider.

[swhite2401]

@lfarv, @lcarver, @oscarxblanco this is still WIP and more testing is needed but I believe all the functionalities requested are now implemented. Please take a first look and let me know if you see something that needs to be modified/improved.

[swhite2401]

For the moment the new function is in physics/new_fastring.py to allow for easy comparison and testing. Once validated I will move everything to fastring.py and replace the old implementation.

[oscarxblanco]

@swhite2401
for our lattice the amplitude detuning is not negligible, I had to add it, and the new fast ring matches pretty well the element by element tracking.

chrom_arr, *_ = at.chromaticity(ring, order=15, npoints=31, dpm=0.02)
_, dnuwa, *_ = at.detuning(ring)
fast_ring, split_ring = fast_ring_new(ring, keep_cavities=True, detuning_coeff=[dnuwa[0,0],dnuwa[0,1],dnuwa[1,1]])

I will now test tracking an off-energy particle and adding the non-linear chromaticiy to the new fast ring.

[oscarxblanco]

@swhite2401 , I saw the coefficients returned by at.chromaticity and I have a doubt. Are they the result of a Taylor expansion ? i.e. are the coefficients multiplied by $k!$ ?
It is not explicitly writen in the docstring of at.chromaticity but I need to divide each component by its factorial in order to get what I expect.

[swhite2401]

@swhite2401 , I saw the coefficients returned by at.chromaticity and I have a doubt. Are they the result of a Taylor expansion ? i.e. are the coefficients multiplied by k ! ? It is not explicitly writen in the docstring of at.chromaticity but I need to divide each component by its factorial in order to get what I expect.

I had the same issue and yes the coefficients are multiplied by k!.
I do the inverse transformation in the fastring so that it is directly compatible with the output of chromaticity().

I will add a word in the documentation of chromaticity.

[swhite2401]

for our lattice the amplitude detuning is not negligible, I had to add it, and the new fast ring matches pretty well the element by element tracking.

I am surprised that you had to manually add them, if not specified they should be automatically computed form the input lattice.

[oscarxblanco]

@swhite2401 , I still don't manage to get an off-energy particle tracking with a good result.

This is what I have modified:

chrom_arr, *_ = at.chromaticity(ring, order=3, npoints=31, dpm=0.02)
_, dnuwa, *_ = at.detuning(ring)

fast_ring, split_ring = fast_ring_new(ring, keep_cavities=True,
                                      detuning_coeff=[dnuwa[0,0],dnuwa[0,1],dnuwa[1,1]],
                                      qpx = chrom_arr[0,:],
                                      qpy = chrom_arr[1,:],
                                      )
...
    zin[4] = zin[4] + 10e-3

[swhite2401]

@swhite2401 , I still don't manage to get an off-energy particle tracking with a good result. This is what I have modified:

chrom_arr, *_ = at.chromaticity(ring, order=3, npoints=31, dpm=0.02)
_, dnuwa, *_ = at.detuning(ring)

fast_ring, split_ring = fast_ring_new(ring, keep_cavities=True,
                                      detuning_coeff=[dnuwa[0,0],dnuwa[0,1],dnuwa[1,1]],
                                      qpx = chrom_arr[0,:],
                                      qpy = chrom_arr[1,:],
                                      )
...
    zin[4] = zin[4] + 10e-3

Be carefull the first element of chrom_arr is the tune, you fastring instanciation should be:

fast_ring, split_ring = fast_ring_new(ring, keep_cavities=True,
                                       detuning_coeff=[dnuwa[0,0],dnuwa[0,1],dnuwa[1,1]],
                                       qpx = chrom_arr[0,1:],
                                       qpy = chrom_arr[1,1:],
                                       )

[swhite2401]

With these 2 lines:

chrom_arr, *_ = at.chromaticity(ring, order=15, npoints=31, dpm=0.02)   
fast_ring, split_ring = fast_ring_new(ring, qpx=chrom_arr[0, 1:], qpy=chrom_arr[1, 1:], keep_cavities=True)

I get:

[oscarxblanco]

@swhite2401 , all OK for off-energy particles up to 0.1%.
When tracking a particle 1% off-energy it seems that I need the non-linear momentum compaction factor.

zin[4] = zin[4] + 10e-3

I will try the non-linear momentum compaction factor.

[swhite2401]

I will try the non-linear momentum compaction factor.

Sure you can but I suspect it would change much, the transfer matrices and other quantities are computed around the on-momentum closed orbit so as you deviate form this it is not a surprise that it starts diverging.

If you need to use the fast ring off-momentum I can add a dp argument to compute everything around the dispersive orbit, would you find it useful?

[oscarxblanco]

I did a test with 2% energy offset, and +100 um in the horizontal plane.
With the following lines in the script the longitudinal plane looks perfect.

mcf = at.physics.get_mcf(ring.disable_6d(copy=True),fit_order=3,n_step=10)
fast_ring, split_ring = fast_ring_new(ring,
                                      qpx=chrom_arr[0, 1:],
                                      qpy=chrom_arr[1, 1:],
                                      keep_cavities=True,
                                      alphac=mcf,
                                      )

The transverse, however, behaves really non-linear, while the fast ring shows an ellypse which I think is expected.

I think this difference is not a problem, but, adding a dp argument is a good idea.

[oscarxblanco]

Here is the result with horizontal offset of 20 um, and energy offset of 0.2% which is closer to what the beam would be. It seems all is OK.

[swhite2401]

I think this difference is not a problem, but, adding a dp argument is a good idea.

Ok I will add it

[oscarxblanco]

@swhite2401 , could the amplitude detuning be a polynom ?

[swhite2401]

@swhite2401 , could the amplitude detuning be a polynom ?

Yes I could add this

[swhite2401]

@oscarxblanco , for the amplitude detuning, everything is new done w.r.t. action which is cumbersome when going to higher orders, I would like to change this to simplify the implementation.
Before that, I will wait that @lcarver is back because I need to break backward compatibility to move to amplitude.

Is the rest of the code ok for you? Can I start cleaning up this PR and prepare for the merge?

[oscarxblanco]

@swhite2401 , all the rest looks OK for me.

The current detuning as a function of action already works, and the polynomial amplitude detuning might not be necessary.

[swhite2401]

The current detuning as a function of action already works, and the polynomial amplitude detuning might not be necessary.

Ok I start cleaning up and wait for @lcarver approval.

But let's see it is a good occasion to improve the detuning function, maybe in a separate PR. Let's see.
Thanks a lot for the review!

[swhite2401]

@lfarv , @lcarver I believe this is getting ready to merge. Any further comments?

Concerning the non-linear amplitude detuning requested by @oscarxblanco , I think I will keep it for another PR as this is one is already quite large.