Transfer matrices strongly dependent on element_divisions

[Björklund]

Hi,

I was optimizing some second- and third-order matrix terms and then did some tracking to confirm all the values after the optimizer had converged. I wanted to track with more element_divisions than 1 to get nicer plots. U1666 and U2666 specifically were about 2-3 orders of magnitude larger than expected, and then I tried to start the optimizer with higher element_divisions, which yielded an error saying that a drift I have as an optimization value were below its lowest limit. So firstly, the optimizer seems to treat element_divisions in a weird way, and secondly, when I tracked with just 1 element_division (which I also had optimized with), the matrix values looked like expected, so something weird might be going on there too.

For reference, I am using KQUADS and similar for the higher orders, since I have some multipole stuff that I want to be in the actual tracking later. I don't know if this is what somehow causes this discrepancy.

Best regards
Jonas

[michael_borland]

Jonas,

I did a simple test with a single KQUAD element. I agree that the third-order path-length elements are different when one divides the element. This is because the expressions for quadrupoles don't contain values for those elements, which I think I convinced myself must be zero (or just too hard to compute). Meanwhile, if one subdivides, one gets some cross-terms like U56ij, with i and j being 1, 2, 3, 4.

If you are concerned about these matrix elements, I would use the subdivided lattice. I'll add calculation of those matrix elements to my to-do list.

--Michael

[michael_borland]

Jonas,

To be clear, the quadrupole matrix has Uijkl correct elements for non-path-length terms. It's just the third-order path-length terms that are missing.

Another way to determine these matrix elements is using the analyze_map command, which it turns out gives results for the U56kl for a quadrupole that are different from those from dividing the element and using the matrix_output command. This presumably means that there are some missing path-length terms that can't be recovered using matrix concatenation, so my previous advice should be taken with a lump of salt. At this point, the best I can suggest is to use analyze_map. Unfortunately, one can't perform optimization of the results.

--Michael

[Björklund]

Hi,

So, the specific terms I were looking at were U1666 and U2666, which changed with element_divisions, and which are just transverse. I looked at these matrix terms over an entire bunch compressor, which contains CSRCSBENDs, KQUADs, KSEXTs, KOCTs and EDRIFTs, so it's not a simple setup. I didn't check any of the other matrix terms, except for the Rij terms, which changed at the 5th decimal point or so, so not nearly as much as the Uijkl terms that I looked at.

I suspect that the U5666 (and other longitudinal terms) of a single, relatively short quadrupole would not be very large, but the effect of all the elements on the matrix term of the whole compressor was very large (although I didn't actually check U5666). I very much need the terms for use in the optimizer, but I might check out the analyze_map when I have time.

In your first message, did you mean that the case with higher value of element_divisions is better to use? It sounds to me like the cross-terms are artifacts, but maybe I misunderstand what you're saying.

Best regards
Jonas

[michael_borland]

Jonas,

The cross terms are real and should at least give some of the effects. The idea is that if the first segment transforms according to

Code: Select all

x1 = R1*x0 + T1*x0^2

and the second segment is similar with R2 and T2, then the concatenation is

Code: Select all

x2 = R2*(R1*x0 + T1*x0^2) + T2*(R1*x0 + T1*x0^2)^2

which has some third- and fourth-order terms. In the limit of very short segments, my intuition is that this will give an approximation of the third-order matrix, or at least some parts of it. Obviously, this can't be the whole story (e.g., doesn't work for octupoles).

--Michael