Discrepency in First-Order Transfer Matrix

[Chris Prokop]

Hi,

I've noticed a discrepancy between in the first-order transfer matrix (read via the .matext file, written from

&matrix_output
printout ="%s.matext"
printout_order = 2
SDDS_output="%s.mat"
SDDS_output_order=2
full_matrix_only=1
&end

There appears to be some dependence on this transfer matrix depending on what default_order is specified for tracking. Changing "default_order = 1" to "default_order = 2" in the &run_setup block produces the following change (truncated the transfer matrix just to show several of the changes). Of note are the fifth and sixth columns.


"default_order = 1"
C: 7.242487559697242e-04 2.484926385476421e-04 0.000000000000000e+00 0.000000000000000e+00 1.710070928372430e+01 -8.193165066476552e-04
R1: 8.335619846540105e-01 -2.803361304005287e+00 0.000000000000000e+00 0.000000000000000e+00 1.540391434852078e-01 2.193517664556615e-02
R2: 7.645791987162753e-01 -1.371724477005838e+00 0.000000000000000e+00 0.000000000000000e+00 3.352856859712416e-02 4.604423382828756e-03

"default_order = 2"
C: 7.246143875760628e-04 2.487342194818366e-04 0.000000000000000e+00 0.000000000000000e+00 1.710071682855462e+01 -8.182951192695051e-04
R1: 8.165524155515519e-01 -2.784564392068167e+00 0.000000000000000e+00 0.000000000000000e+00 1.860228464430133e+01 2.696346667360979e+00
R2: 7.587909465128337e-01 -1.365314750571623e+00 0.000000000000000e+00 0.000000000000000e+00 6.406591270588014e+00 9.285031409952567e-01

Is there any common reason why there would be this discrepancy? I assumed that changing the order would only change the T_ijk terms, but the displayed behavior is puzzling.

Thanks,
Chris Prokop

[michael_borland]

Chris,

The reason for this has to do with the way elegant computes the matrix for an RFDF element with non-zero length. It does this by splitting the element into many drift-cavity-drift slices, where the cavity slice is a zero length element represented by a second-order matrix. Because in general the orbit wanders from x=y=0 in tranversing an extended-length deflector, there can be feed-down from the second-order matrix of the zero-length slice into the first order matrix of the extended-length deflector. I think this is what you are seeing.
--Michael

[michael_borland]

Chris,

For some reason, I assumed you are using an RFDF element here. (Didn't you ask about them before.) Let me know if that isn't the case.

--Michael

[Chris Prokop]

Chris,

For some reason, I assumed you are using an RFDF element here. (Didn't you ask about them before.) Let me know if that isn't the case.

--Michael

Hi Michael,

Yes, I am using an RFDF element.

Thanks! That explanation makes sense, and explains why it seemingly only affects a few of the terms of the transfer matrix.

Thanks again!