Third order dipole matrix
Moderators: cyao, michael_borland
Third order dipole matrix
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 higherorder 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 thirdorder (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
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 higherorder 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 thirdorder (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

 Posts: 1796
 Joined: 19 May 2008, 09:33
 Location: Argonne National Laboratory
 Contact:
Re: Third order dipole matrix
Jonas,
You should be able to get the thirdorder trackingbasedmatrix from version 34.4.1 of elegant. Please check the following
Other codes that might be applicable here
Michael
You should be able to get the thirdorder trackingbasedmatrix 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.
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 higherorder matrix. I've had issues with the dipole model in the case of small bending radius, but perhaps that's been resolved.
Michael
Re: Third order dipole matrix
Hi,
Oh, all right, it's user error on the tracking_matrix, I thought it was an onoff 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 xposition 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.
Oh, all right, it's user error on the tracking_matrix, I thought it was an onoff 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 xposition 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.
Re: Third order dipole matrix
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
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

 Posts: 1796
 Joined: 19 May 2008, 09:33
 Location: Argonne National Laboratory
 Contact:
Re: Third order dipole matrix
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
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
Re: Third order dipole matrix
Hi,
Attached are two files that should be possible to run with few modifications. The lattice is a full doubleachromat 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
Attached are two files that should be possible to run with few modifications. The lattice is a full doubleachromat 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
Re: Third order dipole matrix
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
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

 Posts: 1796
 Joined: 19 May 2008, 09:33
 Location: Argonne National Laboratory
 Contact:
Re: Third order dipole matrix
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
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
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.461267e03 7.847101e03 2.061669e01
Printout for SDDS file stdin
R16 T166 U1666
m/1 m

1.463519e03 6.729664e03 2.058399e01
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

 20181024.zip
 (8.84 KiB) Downloaded 198 times
Re: Third order dipole matrix
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
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

 Posts: 1796
 Joined: 19 May 2008, 09:33
 Location: Argonne National Laboratory
 Contact:
Re: Third order dipole matrix
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
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