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: 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: (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
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.