&correct trajectory and centroid location do not match

Moderators: cyao, michael_borland

Post Reply
foshea
Posts: 34
Joined: 23 Jun 2009, 21:00

&correct trajectory and centroid location do not match

Post by foshea » 07 Jul 2021, 17:15

I'm having an issue with getting the centroid trajectory (Cx, Cy in %s.cen) of a low energy beam (beta*gamma = 0.15) to match the trajectory given by &correct. I cannot post my lattice, so I'll have to settle for describing the problem as best I can and hope I trigger enough keywords to get some help.

The procedure I use is as follows:
1) Apply DX, DY and TILT errors to all elements in the beamline and use &correct with use_actual_beam=1 to correct the actual beam. No particles are lost during any step of correction. The particle distribution, created by &bunched_beam is dumped.
2) Start a new run, loading the beamline parameters from the first run %s.par file and the particles from the previous &bunched_beam command. I don't make any (purposeful) changes to the beamline.

When I compare the centroid of the beam with the location &correct stored in the %s.traj file, I see the following:
x_diff.png
y_diff.png
Some things to note:
A) The difference between Cx and tx grows in the x plane when the beam encounters CCBEND, CSBEND, and KOCT elements.
B) The difference between Cy and ty grows in the y plane only after the second octupole element (a KOCT with K3 = 1e5)

When I turn the octupoles down to K3 = 1, the difference in the x plane decreases by about 10 and the difference in the y plane decreases by about 1000. So the problem appears related to non-linear terms.

C) When I turn the emittance off, the problem disappears and the size of the difference grows with the emittance:
emittance scaling.png
(the blue lines in this plot should be the same as the blue lines in the earlier plots).

The %s.scor file doesn't say anything is amiss (last cycle only):

Code: Select all

! page number 5
1
horizontal
y
                  11
0 2  4.222957902801451e-04  3.819824209220663e-07  6.528723299873405e-04  1.213059097236478e-06  0.000000000000000e+00 uncorrected
1 2  4.223228884189203e-04  1.694805007503511e-07  6.530368655140750e-04  5.329144666130232e-07  0.000000000000000e+00 intermediate
2 2  4.223781431869066e-04  3.133198275403931e-08  6.530529696092211e-04  9.589005090640639e-08  0.000000000000000e+00 intermediate
3 2  4.223878670832647e-04  4.706707577105076e-09  6.530545456763386e-04  1.412959277930599e-08  0.000000000000000e+00 intermediate
4 2  4.223891734397776e-04  6.464001139210110e-10  6.530546999080880e-04  1.909276956549126e-09  0.000000000000000e+00 intermediate
5 2  4.223893305044277e-04  8.459786425816505e-11  6.530547149996340e-04  2.463008593352016e-10  0.000000000000000e+00 intermediate
6 2  4.223893482881213e-04  1.075514988753212e-11  6.530547164761781e-04  3.090787588982610e-11  0.000000000000000e+00 intermediate
7 2  4.223893502282219e-04  1.341945341352402e-12  6.530547166206296e-04  3.811301499574704e-12  0.000000000000000e+00 intermediate
8 2  4.223893504346657e-04  1.653115665182144e-13  6.530547166347859e-04  4.645512653375649e-13  0.000000000000000e+00 intermediate
9 2  4.223893504562397e-04  2.018002284845066e-14  6.530547166361586e-04  5.616931798152480e-14  0.000000000000000e+00 intermediate
10 2  4.223893504584655e-04  2.453153372099536e-15  6.530547166362970e-04  6.766783227502016e-15  0.000000000000000e+00 corrected
! page number 6
1
vertical
y
                  11
0 2  2.550751063263231e-03  1.974161027912328e-08  6.389949646327886e-03  6.223468694012380e-08  0.000000000000000e+00 uncorrected
1 2  2.550730896537905e-03  7.380602328376411e-09  6.389894691335394e-03  2.285461221116201e-08  0.000000000000000e+00 intermediate
2 2  2.550738222288705e-03  1.114054430430259e-09  6.389913680352164e-03  3.401138528802698e-09  0.000000000000000e+00 intermediate
3 2  2.550739585385067e-03  1.300754558455450e-10  6.389917230189794e-03  3.944067523513339e-10  0.000000000000000e+00 intermediate
4 2  2.550739752706852e-03  1.292472969547715e-11  6.389917666135713e-03  3.900797359897984e-11  0.000000000000000e+00 intermediate
5 2  2.550739769235862e-03  1.088810084979493e-12  6.389917709149767e-03  3.270152253674608e-12  0.000000000000000e+00 intermediate
6 2  2.550739770534921e-03  6.956802156178397e-14  6.389917712517339e-03  2.063245266911013e-13  0.000000000000000e+00 intermediate
7 2  2.550739770596484e-03  1.718779534629724e-15  6.389917712674172e-03  3.770660442681175e-15  0.000000000000000e+00 intermediate
8 2  2.550739770592616e-03  6.813934141735971e-16  6.389917712663486e-03  1.990495550503735e-15  0.000000000000000e+00 intermediate
9 2  2.550739770590943e-03  1.637381382850079e-16  6.389917712659034e-03  4.877694168708980e-16  0.000000000000000e+00 intermediate
10 2  2.550739770590601e-03  2.747176054824397e-17  6.389917712658131e-03  8.273954438253739e-17  0.000000000000000e+00 corrected
where Prms and Pmax are tiny. The &correct routine clearly thinks it has converged.

D) When I look at the beam at the end of the beamline, there are some obvious outliers. (For some reason I can't add any more pictures, I'll add it to a reply.) When I increase the number of particles from 10k to 160k, the difference in the centroid versus the trajectory improves by less than a factor of two, but it does improve.

When I think about all of these pieces of information together, it seems that the monitors are able to ignore the outliers when optimizing the trajectory, but the centroid command cannot, and therefore the centroid appears to be moving around relative to the &correct trajectory. Meanwhile, the numerical integration in the CCBEND, CSBEND, and KOCT elements is causing outliers. It is also possible that the lattice I load in step 2 doesn't match the lattice from step 1 in some way that isn't obvious to me. [Edit: checking the %s.cen file produced during step A shows that it is identical to step B. I think the lattices for the two steps are the same.]

I guess one of two responses will help me. Either I should just ignore it and move on (or try to filter outliers somehow), in which case it would be helpful to have a way to compute the beam trajectory without using centroid or touching the correctors, or some way to resolve the discrepancy between the two methods.
Last edited by foshea on 08 Jul 2021, 08:00, edited 1 time in total.

foshea
Posts: 34
Joined: 23 Jun 2009, 21:00

Re: &correct trajectory and centroid location do not match

Post by foshea » 07 Jul 2021, 17:16

Here is the picture of the beam at the exit:
particles out.png

foshea
Posts: 34
Joined: 23 Jun 2009, 21:00

Re: &correct trajectory and centroid location do not match

Post by foshea » 08 Jul 2021, 16:04

I think this issue is related to octupoles and &correct. Here is what happens when I set default_order differently in step A and step B:

Code: Select all

		K3 = 1				K3 = 100000
A order	B order	x-Diff (mm)	y-Diff (mm)	x-Diff (mm)	y-Diff (mm)
1	1	0		0		0		0
1	2	0.02		0.02		0.02		0.02
1	3	0.02		0.02		0.02		0.08
2	1	0.02		0.02		0.02		0.02
2	2	0.004		0.001		0.004		0.001
2	3	0.004		0.001		0.1		0.75			
3	1	0.02		0.02		0.1		0.4
3	2	0.004		0.0006		0.15		0.4
3	3	0.004		0.0008		0.02		0.3
When the simulation is forced to be purely linear, the centroid and trajectory match really well. When the octupoles are (effectively) off, the difference between the difference is quite small. When the octupoles are on, they make a significant change to the two measures of the beam path. I have to conclude from this that strong octupoles and the &correct routine do not mix for some reason, but I don't know why? Is this behavior expected?

foshea
Posts: 34
Joined: 23 Jun 2009, 21:00

Re: &correct trajectory and centroid location do not match

Post by foshea » 09 Jul 2021, 20:20

Ok, I have a kinda-sorta functioning example.

There are three parameters that interplay to cause wild behavior of the centroid. I think this is what I'm seeing in my simulations. I hacked the staticPlusDynamicErrors example to bits trying to reproduce the problem I was seeing. I cannot explain why these particular parameters matter, but they do. I ran a number of trials and found the following:
trials.jpg
At the top of run.ele, I define 3 parameters that are used to update the beam or lattice:
d3l is the length of drift d3, values I used were 0.0 and 0.1 (meters)
k33 is the strength of the octupole, values I used were 0.0e5 and 1.0e5 (1/m^4)
emits multiplies the emittance defined in &bunched_beam, I used values between 1 and 1.5 (no units)

Some things to note:
1) If the octupole is off, the "instability" (for lack of a better word) never appears.
2) If the length of drift d3 is zero, the instability is strongly suppressed. d3 shows up only once in the lattice and it's really small, I don't know why it would have such a large effect.
3) If d3.L = 0.1 and the octupole is on and strong there is a threshold for the emittance (particle amplitude, I assume) where the correctors become unreasonably strong (10s of millions) and there is a small number of particles that wander way, way off (5e8 m at output). Most importantly for the problem I've been describing, the centroid and &correct trajectory start to diverge after the octupole:
xy.png
The threshold is emits ~= 1.5. If I use emits = 1.48, everything looks pretty normal. If I use emits = 1.49, the correctors jump up into the thousands and a particle wanders off to 1.5e4 at the output of the beamline. If I use emits = 1.5, everything goes pretty wild as previously described. I'm pretty sure this is the problem I'm encountering in my other simulation. In some ways it is more extreme in this example (correctors in the 10s of millions here that doesn't occur in my main simulation), and in other ways it is less extreme (the difference between the centroid and the trajectory in this example is less than a micron at most and in my simulation it is almost a millimeter).

Does anyone have any insight into what the problem is? It is pretty clear that particles are doing odd things after passing through a strong octupole, but a further problem is that the &correct routine apparently isn't seeing all the particles otherwise the trajectory and the centroid location would agree with use_actual_beam = 1.
Attachments
unstable_octupoles.tar.gz
(1.49 KiB) Downloaded 200 times

foshea
Posts: 34
Joined: 23 Jun 2009, 21:00

Re: &correct trajectory and centroid location do not match

Post by foshea » 13 Jul 2021, 08:56

Another clue is that residual dispersion due to having kickers in an area with "natural" dispersion due to bends is pretty strongly correlated with the trajectory difference between the centroid and the value found by &correct, especially in the y-plane.
x-diff.png
y-diff.png
I still don't understand why this would cause a difference between the centroid and the &correct trajectory.

Oh, and I updated to version 2021.2.0 yesterday, hoping it would solve this problem, and no luck.

foshea
Posts: 34
Joined: 23 Jun 2009, 21:00

Re: &correct trajectory and centroid location do not match

Post by foshea » 13 Jul 2021, 11:55

Another unexpected feature shows up in my last post. Why is the beam not on the x-axis near the end of the beamline? Isn't that what correction should be doing?

If I look at the last ~10 meters of beam line in the trajectory file, it appears that the last kicker isn't properly zeroing the position of the beam on the last HMON:
s(m), x(m), y(m), ElementName, ElementOccurence, ElementType, Particles:

Code: Select all

 3.647668228940114e+01  2.249921340924638e-04 -6.596132337219080e-13 TRA-D.00 1 EDRIFT 10000
 3.647668228940114e+01  2.249921340924638e-04 -6.596132337219080e-13 TRA-K.02 1 KICKER 10000
 4.413668228940114e+01  1.590093866604966e-03 -3.006133390244872e-11 TRA-D.01 1 EDRIFT 10000
 4.426168228940114e+01  1.612370330908364e-03 -3.054112684437033e-11 TRA-D.02A 1 EDRIFT 10000
 4.426168228940114e+01  1.612370330908364e-03 -3.054112684437033e-11 TRA-P.02H 1 HMON 10000
 4.435668228940114e+01  1.629300443778955e-03 -3.090577005340073e-11 TRA-D.02B 1 EDRIFT 10000
 4.435668228940114e+01  1.629300443778955e-03 -3.090577005340073e-11 TRA-P.02V 1 VMON 10000
 4.440768228940114e+01  1.638389241214737e-03 -3.110152469280869e-11 TRA-D.02C 1 EDRIFT 10000
 4.452668228940114e+01  1.659596435231578e-03 -3.155828831578368e-11 NOTCAT 1 EDRIFT 10000
Between kicker TRA-K.02 and horizontal monitor TRA-P.02H there is nothing but drift and yet the beam is allowed to deviate from zero by nearly 2 mm. When I look at the .cor file, I see that the last kicker remains off (both HKICK and VKICK are ~1e-19). That seems wrong to me.

foshea
Posts: 34
Joined: 23 Jun 2009, 21:00

Re: &correct trajectory and centroid location do not match

Post by foshea » 13 Jul 2021, 15:56

The trajectory not being corrected was due to me setting n_xy_cycles = 1 in my &correct statement. It didn't occur to me that this could be an issue, because it is the default setting but simply commenting that line out fixes the trajectory problem from my last post:
x-diff.png
y-diff.png
The problem with the centroid and the trajectory not being the same remains, however.

foshea
Posts: 34
Joined: 23 Jun 2009, 21:00

Re: &correct trajectory and centroid location do not match

Post by foshea » 13 Jul 2021, 18:08

I move some of the MONIs closer to that second octupole to see if the problem was the size of the trajectory. Hoping that would fix the issue. Nope.
x-diff.png
y-diff.png

foshea
Posts: 34
Joined: 23 Jun 2009, 21:00

Re: &correct trajectory and centroid location do not match

Post by foshea » 14 Jul 2021, 15:56

The problem was that the first element in the lattice was a TWISS element. I had used that in the original design because we had several inputs to switch between and it was convenient. That element doesn't play well with &correct, I guess, because when I eliminate it (and move the twiss parameters to &twiss_output), I get excellent agreement between the &correct trajectory and the centroid trajectory (note the scale in the upper left of each plot):
x-diff.png
y-diff.png

Post Reply