Closed Orbit Correction Fails to Work

[fliller]

Mike,

I have encountered a strange problem with ELEGANT. I have 2 identical lattices with the exception that 1 corrector in an arc is moved from point A to B. (the machine has 4 fold symmetry). In one case, I can correct the orbit, and in the other I cannot. Both are correctable in MAD, in fact, the unwworking lattice has a better orbit in MAD.

Stranger still, I can take the working lattice, and just add a corrector in the same location as the unworking lattice, and it breaks.

I've attempted a number of things, but no avail.

Ray

[michael_borland]

Ray,

The problem seems to be that you have multiple horizontal correctors between some monitors, which makes the response matrix nearly singular. In the "NoWork" files, there is one less monitor in each plane that is "useable" (i.e., downstream of a corrector). Somehow that makes the matrix bad enough that the correction fails.

One clue that this is the problem is the condition number, which is printed out just after the response matrix is computed. It's 2.4x10^5 in the horizontal plane. If you want good results, which should be under ~1000.

You can fix this by reducing the number of singular values you use. For example, set
keep_largest_SVs[0] = 16,
in the first &correct command in the command input file.

--Michael

[fliller]

Mike,

Thanks this did the trick.

Ray

[simone.dimitri]

Hi Michael (and everybody),
I am playing with the trajectory correction in a linac. I do not understand what elegant is doing with the module &correct, method="global", as I vary the number of BPMs and corectors. Could you please give me some indications?
I guess that for the same number of BPMs and correctors CHV, the response matrix (in both planes) is inverted with SVD and then applied for correction.
What happens when number of BPMs > or < number of CHVs? In the latter case (BPMs < CHVs) I receive a warning message, but the code is still running. Maybe should I look to some references on this?
Thank you in advance,
S.

[michael_borland]

Simone,

For each plane, elegant computes the response matrix and then inverts it using SVD. By default, it limits the number of singular values to the number of monitors, which helps to maintain stability but does not ensure it. If you find that the correction is not stable or that correctors are fighting each other, then you need to tune the number of singular values.

Consider the x plane only. First, set auto_limit_SVs[0] = 0, to turn off auto-adjustment of the number of SVs. Then, set keep_largest_SVs[0] = (NBPMs-1), where NBPMS is the number of horizontal BPMs. Do the same for the y plane (index 1), then run elegant. If correction is not satisfactory, decrease the number of SVs kept and repeat.

--Michael

[simone.dimitri]

Hi,
I have run elegant to correct a trajectory along the linac. I am forcing elegant to correct in 1 iteration, 1 cycle (per plane).
I have also asked elegant to produce the response matrices.
Now, I want to apply the inverse resp. matrix to the uncorrected trajectory to find the correctors setting. I expect to obtain what elegant does by itself. My commands are:

sddsmatrixmult rmatrix.hirm bpmx.sdds correctorsxDelta -ascii

rmatrix.hirm is generated by elegant
bpmx.sdds = uncorrected trajectory changed of sign. This is therefore the delta(position) at the BPMs I am asking for.
correctorsxDelta = output file, I expect to obtain the delta(kick) to be set in the correctors. Since they start from 0 kick, this is also the absolute kick to be used.

While elegant produces a well corrected trajectory and kicks of the order of 10-4rad, my matrix multiplication gives negligible kicks~10-8rad.
So, I am wondering if my interpretation of matrix multiplication is correct. Is it?
Is the output inverse resp.matrix generated by elegant the same it actually uses for the correction?

I have followed some useful indications and comments by Michael and L. Emery on this topic, but I could not find a solution to the present problem anyway.
Thank you in advance,
Simone

[michael_borland]

Simone,

The matrix is actually the transpose of the matrix you need. Plus, there is an extra column (s, giving the distance) that will confuse matters.

I've attached a set of example files that show how to get it to work.

--Michael

[simone.dimitri]

Hi Michael,
thank you for the examples. I have applied your script to my lattice and I have found the source of the discrepancy.
When I do not include errors on the BPM alignment, everything is fine (see attachment bpm_noerr.png). But, as I also include these errors, the elegant response in terms of kicks is different from the response matrix prediction (see attachment bpm_err.png). The same happens as I include the bpm noise option in the &correct module.
So, I guess that when I run &correct, even with only BPM alignment error, elegant sees the beam offset at the monitors and try to correct it. But, at the same time, the beam position file .cen - generated with only errors included and no correction - multiplied by the transposed response matrix has 0 everywhere so that the resp. matrix multiplication does not predict any kick.
If I am right, now my question is: why &correct sees the beam offset at the BPM location, while everything is zero in the .cen file?
Am I missing something else?
S.

[michael_borland]

Simone,

The reason for this is that all output from elegant that contains particle coordinates or moments of particle coordinates is created based on the particle coordinates measured relative to the reference trajectory. Since BPMs don't affect the reference trajectory, you won't see any effect from BPM errors in the .cen file.

Please see the attached file for a demo of how to get the BPM offsets and use them in the outboard trajectory correction.

--Michael

[simone.dimitri]

Yes, Michael, I see.
Thank you a lot.
S.