Third order dipole matrix

Moderators: cyao, michael_borland

Björklund
Posts: 84
Joined: 19 May 2016, 07:14

Third order dipole matrix

Post by Björklund » 23 Oct 2018, 06:45

Hi,

I have been doing bunch compressor optimization of two bunch compressors, optimizing after T166, T266, T566, U1666 and U2666, to reduce slice centroid offset from higher-order dispersion after the compressor. In the first compressor, the tracked beam corresponded well with the analytical equation based on T166 and U1666, but in the second one, there was a large discrepancy which looked very characteristically third-order (U1666). It took me a good while to figure out what it was, and in the end I found that the dipoles (I'm using CSRCSBENDs) are only implemented to second order as matrices, while the other elements are to third order. I seem to have been lucky with the dipole contribution in the first compressor.

First of all, I'm wondering if it's possible for you to add this third order matrix for the dipoles (and also add matrix elements for the edge_effects = 2 and edge_order = 2 option, which is not added to first order since it gives a residual linear dispersion but R16 = 0), and secondly, it would be great if it was somehow made more clear which elements are implemented to which order. I now have the option enabled to do everything to third order, but I haven't seen any message stating anything about the dipoles not being the same order as the rest of the elements.

EDIT: I tried using tracking_matrix in csbend, but this just gave me a matrix full of 0s. Maybe I used it wrong, but it didn't seem to work for me at least.

If it's not straightforward to add this matrix, is there some other code that does this that you could point me to?

Best regards
Jonas

michael_borland
Posts: 1796
Joined: 19 May 2008, 09:33
Location: Argonne National Laboratory
Contact:

Re: Third order dipole matrix

Post by michael_borland » 23 Oct 2018, 11:58

Jonas,

You should be able to get the third-order tracking-based-matrix from version 34.4.1 of elegant. Please check the following
  • On the CSBEND element, set TRACKING_MATRIX=3
  • In the run_setup command, set default_order=3.
I ran a test and did not see the problem with R16 that you mentioned. If it persists, please post an example.

Other codes that might be applicable here
  • The last version of TRANSPORT, which supported dipoles to third order. I don't know where to obtain this. It seems to no longer be available.
  • COSY Infinity might provide the equivalent of a higher-order matrix. I've had issues with the dipole model in the case of small bending radius, but perhaps that's been resolved.
The program 'elegantto' can help you convert an elegant lattice into a form that should be accepted by these programs.

--Michael

Björklund
Posts: 84
Joined: 19 May 2016, 07:14

Re: Third order dipole matrix

Post by Björklund » 24 Oct 2018, 03:03

Hi,

Oh, all right, it's user error on the tracking_matrix, I thought it was an on-off thing (i.e. just 1 and 0) and not the order that you were supposed to enter. I'll try that right away, but maybe it can be clarified a bit in the manual? I always run the default_order = 3, though. I'll give it another shot!

Regarding the offset, I'll attach two pictures showing the mean slice x-position as a function of energy spread (a bit noisy, but I just ran them quickly with not so many particles; the trend should show, though). The first one is with edge_effects = 1 and edge_order = 2, the second one with both those options = 2. In both cases, R16 = 0. Note the different scales. In the second one, there is a clear linear term and a weak second order one, as far as I can tell. I can email you a lattice file if that would help.
Edge_effects_1.PNG
Edge_effects_2.PNG
Edge_effects_2.PNG (9.58 KiB) Viewed 7245 times

Björklund
Posts: 84
Joined: 19 May 2016, 07:14

Re: Third order dipole matrix

Post by Björklund » 24 Oct 2018, 06:39

Hi again,

So I got the tracking_matrix running, but it gives completely unreasonable values for e.g. T166 and U1666, they are several orders of magnitude too large.

//Jonas

michael_borland
Posts: 1796
Joined: 19 May 2008, 09:33
Location: Argonne National Laboratory
Contact:

Re: Third order dipole matrix

Post by michael_borland » 24 Oct 2018, 08:18

Jonas,

Please post the files you used to get the plots you posted showing a dispersive term. Is this for a single dipole, a chicane, ... ?

As for whether T166 and U1666 are too large, again please post the input files. Are you thinking of the '6' coordinate in percent, which would give factors of 10^2 and 10^4?

--Michael

Björklund
Posts: 84
Joined: 19 May 2016, 07:14

Re: Third order dipole matrix

Post by Björklund » 24 Oct 2018, 09:19

Hi,

Attached are two files that should be possible to run with few modifications. The lattice is a full double-achromat bunch compressor, which was also used to generate the two previous images. There is a knob for turning edge effects on and off.

When it comes to the matrix for this compressor, the tracking based one gives a decent enough result for the transverse slice offset if plotting it vs the polynomial using R16, T166 and U1666. Now, the R16 terms i definitely larger than it was before, but running without the tracking_matrix doesn't give these matrix terms. For the other compressor, though, the matrix option gives something very weird. I can perhaps provide that file later.

//Jonas
Attachments
Run_MAX4_BC1.ele
(1.51 KiB) Downloaded 207 times
MAX4_BC1_test.lte
(16.92 KiB) Downloaded 220 times

Björklund
Posts: 84
Joined: 19 May 2016, 07:14

Re: Third order dipole matrix

Post by Björklund » 24 Oct 2018, 09:39

Hi again,

Here is the lattice for the other BC, this gives unreasonable parameters. Plotting the polynomial over the tracked slice offset gives no overlap whatsoever.

It can be run using the same run file, with
Po = 6100,
beta_x = "2.454",
beta_y = "12.870",
alpha_x = "0.9915",
alpha_y = "-5.3115",

//Jonas
Attachments
MAXIV_BC2_v4_test.lte
(22.24 KiB) Downloaded 207 times

michael_borland
Posts: 1796
Joined: 19 May 2008, 09:33
Location: Argonne National Laboratory
Contact:

Re: Third order dipole matrix

Post by michael_borland » 24 Oct 2018, 09:49

Jonas,

I did a test using your chicane and the R16, T166, and U1666 matrix elements look reasonably good. See the attached files, from which I get

Code: Select all

 Coefficient01  Coefficient02  Coefficient03 
       m              m              m       
---------------------------------------------
 -1.461267e-03  -7.847101e-03  -2.061669e-01 
Printout for SDDS file stdin

      R16            T166          U1666     
      m/1             m                      
---------------------------------------------
 -1.463519e-03  -6.729664e-03  -2.058399e-01 
The "Coefficient.." values are from a fit of (x, delta) at the exit, whereas the R16, T166, and U1666 values are from the matrix. They are not exactly the same, but not wildly off.

The discrepancy with T166 can be resolved using more fitting points, which presently isn't under user control. However, a control exists in the next release (35.0), which I hope to have out next week.

--Michael
Attachments
2018-10-24.zip
(8.84 KiB) Downloaded 198 times

Björklund
Posts: 84
Joined: 19 May 2016, 07:14

Re: Third order dipole matrix

Post by Björklund » 25 Oct 2018, 01:38

Hi,

Yes, like I mentioned, the tracking based matrix seems to work well enough for BC1, but I still don't get why the dispersion seems to not be closed when changing the edge_effects from 1 to 2.

I don't see the same edge effect behavior in BC2 and the tracking matrix also gives very strange values for this compressor. The tracked particle offset and the analytical equation mismatch completely.

The new feature with the fitting points - is that fitting points for the tracking matrix calculation or for just fitting a polynomial?

//Jonas

michael_borland
Posts: 1796
Joined: 19 May 2008, 09:33
Location: Argonne National Laboratory
Contact:

Re: Third order dipole matrix

Post by michael_borland » 25 Oct 2018, 09:11

Jonas,

I agree that it is puzzling why the dispersion is not matched with EDGE[12]_EFFECTS=2. There is also a slight trajectory offset, which is not unexpected because this edge model (by K. Hwang) includes the trajectory effects of the extended fringe fields. One can tune out the trajectory effects by adjusting the FSEs (setting FSE_CORRECTION=1), but the dispersion persists and takes nearly the same value with the opposite sign. Even so, I recommend always setting FSE_CORRECTION=1.

Checking the R matrix, I see that R11 is not identically equal to R22 (the difference is about 3ppm in your case), which indicates a problem. If I set EDGE[12]_EFFECTS=1, R11=R22 to much higher accuracy. At this point, my recommendation is not to use EDGE[12]_EFFECTS=2, but stick with EDGE[12]_EFFECTS=1. We'll have to dig into the implementation to see why the "symplectic" method isn't satisfying this required condition. (I'm assuming your chicane is supposed to be symmetric; let me know if that isn't the case.)

There are other issues with our implementation of K. Hwang's method (or the method itself, I'm not sure) that make it less than ideal for your case. Unlike the old K. L. Brown method (EDGE[12]_EFFECTS=1), it doesn't include the effect of the dipole gradient (K1) on the edge effects.

Thanks for your persistence in bringing these issues to my attention. I'll add a note in the manual to warn other users.

The new feature I mentioned for the number of points in the matrix determination changes how many particles are tracked. The fitting order will be chosen automatically to be one less than the number of points (e.g., with two points you could get the constant and linear terms), on the assumption that noise is negligible. Unfortunately, figuring out the matrix from tracking is not the ideal approach since there is always uncertainty over how much (costly) tracking to perform and the best fit order to choose.

--Michael

Post Reply