Chromatic effect of the dipole edges not taken into account

[chernals]

The thick tracking routine for combined function dipoles (ttcfd) takes the chromatic effects into account in an exact manner by re-normalizing the transverse momenta by the total momentum, this is

px_n = px / delta_plus_1 py_n = py / delta_plus_1

and the inverse factor is applied at the end of the element.

However, the dipole edges (fringe + edge angle) map is applied outside of this renormalization.

I would argue that this is incorrect and that the fringes should be applied on px_n and py_n so that the chromatic effect is fully taken into account.

[tpersson]

I think it is correct since MAD-X is tracking px and that is what is used in the derivation of that map: https://www.cockcroft.ac.uk/wp-content/uploads/2014/12/wolski-5.pdf

To me it looks like the angles are explicitly wanted for the THICK dipole.

[chernals]

I agree that the derivation is done with px (other similar derivations, like in Brown 75, are done with x' which leads to equivalent results).

However, this assumes that px is PX (the unscaled horizontal momentum) scaled by the P0 total momentum of the particle.

In our case in MAD-X, to correctly take into account the effect of DPP in quadrupoles, the momenta px and py are renormalized particle by particle by the total momentum of each one of them. That means that the canonical variables that are transported are x, px=PX/P0, etc. with P0 related to the reference energy, however, the variables that are tracked within the routines (see quadrupole for example), are x, px' = PX / (P0 * (1+deltaP/P), etc.

This allows to take into account the chromatic effect of the quadrupoles in an exact manner. My point is that this could/should be done for the fringe fields as well.

Let me know if this unclear, even if I'm clear I might still be wrong.

[tpersson]

I can't really follow exactly where you point to in the code. If we take the multipole element in track which is similar to the same as dipedge you will see that there is no dependency on the delta p or pt. As a matter of fact a thin quadrupole will change the px with the same amount even with a pt different from zero. However, the angles will be different since xp = px/(1+deltap) (where you of course have to convert from pt to get deltap)..

It is possible I am missing something so feel free to pass by and we can have a chat about this.

[ldeniau]

Andrea, could you please clarify and eventually close this issue?

[alatina]

Dear All,

Sorry for getting back so late to this.

I believe that @chernals 's proposal to introduce chromatic effects in the edge fields makes sense.

For example, as chromaticity isn't naturally part of the quadrupole transfer matrix, but it can be reintroduced into the matrix (like it's done in ttcfd() and explained in Wolski's lecture 5), I think it is legitimate to do the same with the map of the dipedge's thin quadrupole kick.

I have created a branch called 'chromatic_dipedge' to implement the change. I have needed to update a few tests after this change, but the differences were minimal.

Also, I have modified ttcfd() and tttdipole() to remove the variable 'beta' and replace it explicitly with trackfi :: bet0. This is in line with what's done in ttdft() for example.

[tpersson]

Hi Andrea, I still don't understand that logic. In that case I think we should do the same for all the elements, e.g. multipoles, no?. The reason we do it in TWISS is that the drift with a deltap (not pt) is not chromatic and hence the cromaticity must come from the elements. Actually when there is a pt in TWISS we don't do this scaling. In TRACK the chromatic effect is coming from the drift and my feeling is that doing it also in dipedge is to do it twice.

In fact if we look at this line (copyed from your proposal): track(2,jtrk) = track(2,jtrk) + RW(2,1) * track(1,jtrk) / delta_plus_1

is then effectivley in my understanding saying px _new = px_old + x'_change

but maybe I am missing something here..

Any thoughts?

[rdemaria]

It is not clear to me if the disagreement comes from the fact that twiss and track use a different coordinate definitions, or Andrea is effectively changing formalism.

In TWISS, delta introduce an energy error in the machine (e.g. the closed orbit changes), while pt is energy error of a particle with respect to P0*(1+delta). In TRACK delta is translated in PT, therefore it is not possible to track particles in a machine with an energy error (e.g. around a different closed orbit).

I would suggest to treat the subject in a section meeting with equations justifying the change.

Indeed I think it will be useful to reintroduce delta (as used in TWISS ) in TRACK in such a way the two commands will be consistent, although it is a big change (...as big as when delta in track was redefined about 15 years ago...). Clearly this change has to be done consistently for all elements.

[tpersson]

If I look at the multipole and the drifts it seems to me that the coordinate definitions are the same between TRACK and TWISS except from the fact as you said the lack of a equivalent deltap in TRACK. Indeed it is a very nice feature to have also for track and would make studies of say off-momentum DA easy but some work to introuce it correctly and test it. Just out of curiousity, does SixTrack lib has this feature?

[rdemaria]

Neither sixtrack or sixtracklib have a delta parameter. Indeed, in a tracking code (differently from TWISS) there are several alternative ways to introduce an energy error: a phase modulation in the cavities, or patching time, or using totaltime mod RF period. The delta parameter introduced in TWISS is only needed to keep PT small because the maps are expanded around PT=0. The time patching (in TWISS is distributed in all drifting elements) or the phase modulation needs to be adjusted to get the desired energy chsnge, and both sixtrack and sixtracklib do not have code that helps with this. In mad-x track I would however follow what TWISS does for consistency.

[alatina]

I don't think it makes too much sense to ensure "consistency" between TWISS and TRACK.

TWISS and TRACK have very different purposes, and I believe we should ensure that both modules fulfill their purpose, rather than enforcing a behavior which misses important physics.

The fact that they use the same dynamic variables is great and simplifies our life significantly, but we don't need more consistency.

Having the DELTAP option in TRACK would be nice, and we can certainly discuss how to implement it at best, but I think we should first fix other inconsistencies which are present throughout the module. For instance, these two variables are used pretty much randomly:

  betas  = get_value('probe ','beta ')   bet0    =  get_value('beam ','beta ')

Which one should really be used?

On 2/16/21 7:46 pm, tpersson wrote:

If I look at the multipole and the drifts it seems to me that the coordinate definitions are the same between TRACK and TWISS except from the fact as you said the lack of a equivalent deltap in TRACK. Indeed it is a very nice feature to have also for track and would make studies of say off-momentum DA easy but some work to introuce it correctly and test it. Just out of curiousity, does SixTrack lib has this feature?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/MethodicalAcceleratorDesign/MAD-X/issues/847#issuecomment-780042538, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHFPOUSP6YU7JZZIECVUFCDS7K4PHANCNFSM4JFZJHHQ.

[ldeniau]

On 17 Feb 2021, at 10:12, Andrea L notifications@github.com wrote:

I don't think it makes too much sense to ensure "consistency" between TWISS and TRACK.

I agree. Nevertheless understanding how to introduce deltap in TRACK would allow faster convergence of chromaticity in studies (e.g. in MAD-NG) while actually it is handled through coupling between transverse and longitudinal planes in various maps (e.g. drifts-kicks) and hence required one more order of integration to get it right (order 4 instead of 2), i.e. get enough iterations between planes to get it effective.

TWISS and TRACK have very different purposes, and I believe we should ensure that both modules fulfill their purpose, rather than enforcing a behavior which misses important physics.

The fact that they use the same dynamic variables is great and simplifies our life significantly, but we don't need more consistency.

Having the DELTAP option in TRACK would be nice, and we can certainly discuss how to implement it at best, but first I think we should first fix other inconsistencies which are present throughout the module. For instance, these two variables are used pretty much randomly:

betas = get_value('probe ','beta ')

Beta of cloned beam, in principle the one to use everywhere.

bet0 = get_value('beam ','beta ')

User defined beta, should be the same as the cloned one since in MAD-X we never change the energy or the reference frame (no acceleration).

Which one should really be used?

On 2/16/21 7:46 pm, tpersson wrote:

If I look at the multipole and the drifts it seems to me that the coordinate definitions are the same between TRACK and TWISS except from the fact as you said the lack of a equivalent deltap in TRACK. Indeed it is a very nice feature to have also for track and would make studies of say off-momentum DA easy but some work to introuce it correctly and test it. Just out of curiousity, does SixTrack lib has this feature?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/MethodicalAcceleratorDesign/MAD-X/issues/847#issuecomment-780042538, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHFPOUSP6YU7JZZIECVUFCDS7K4PHANCNFSM4JFZJHHQ.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MethodicalAcceleratorDesign/MAD-X/issues/847#issuecomment-780414572, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJILT4ZVBYQMTYFEKAZF73S7OB7HANCNFSM4JFZJHHQ.

[alatina]

If we never change the energy of the reference frame, then I propose we replace all 'betas' with 'bet0' in TRACK, until we really implement acceleration through the probe beam.

[ldeniau]

I would go the other way around and always use the probe beam, because it contains other adjustments that are need. So let’s unify the usage and stick to the probe beam, not the user beam.

On 17 Feb 2021, at 10:27, Andrea L notifications@github.com wrote:

If we never change the energy of the reference frame, then I propose we replace all 'betas' with 'bet0' in TRACK, until we really implement acceleration through the probe beam.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MethodicalAcceleratorDesign/MAD-X/issues/847#issuecomment-780423032, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJILT2RCQT33BM633JDFVDS7ODWPANCNFSM4JFZJHHQ.

[alatina]

OK. I agree. I will implement it in the brunch 'chromatic_dipedge'

[chernals]

Thanks for the follow-up. I don't understand why a change of formalism was mentioned. What I initially proposed in the dipole edges is the same as what's done for the quadrupole map: the map (matrix) itself is not chromatic (because it is as higher order effect), however MAD-X has this "trick" (also from Wolski) of making it "exact" in the delta p by rescaling the variables. In essence, the linear (symplectic) tracking is first order in the transverse variables, but "exact" in dpp, because it is done particle by particle, something which is usually not done.

[ldeniau]

On 17 Feb 2021, at 12:20, Cédric Hernalsteens notifications@github.com wrote:

Thanks for the follow-up. I don't understand why a change of formalism was mentioned. What I initially proposed in the dipole edges is the same as what's done for the quadrupole map: the map (matrix) itself is not chromatic (because it is as higher order effect), however MAD-X has this "trick" (also from Wolski) of making it "exact" in the delta p by rescaling the variables.

I guess that by variables you mean the strengths. This is true but only 5D and the time becomes more complicated to compute (and not given in the book of Wolski AFAIK). In Twiss we don’t care because we have anyway a first order approximation of the time through the phase slip factor compensation in each element. But in Track it matters.

In fact we again run after the question/discussion I have about MAD-NG, the only valid approach to get the same physics for both Track and Twiss is pt and 6D, and we need to understand what does it mean to have deltap is this framework… With care, as it seems that people seemed to be confused between motion equations and Halmitonian equations when talking about TPSA and symplectic integration.

In essence, the linear (symplectic) tracking is first order in the transverse variables,

but "exact" in dpp, because it is done particle by particle, something which is usually not done.

Tracking is non-linear zero order (orbit), while Twiss is linear second order (matrix code). To get non-linear second order you need TPSA, and without them you need a trade-off. That why I agree with Tobias statement of this morning, Track and Twiss cannot have the same physics, they can only deliver the same observables, but using different models...

Cheers, Laurent.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MethodicalAcceleratorDesign/MAD-X/issues/847#issuecomment-780488462, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJILT6QGCHUYQICQ565U6DS7OQ6JANCNFSM4JFZJHHQ.

[alatina]

Indeed there is no change of formalism. The change w.r.t. TWISS is that the effect of the particle's magnetic rigidity is included in the Hamiltonian from the beginning.

Doing so, the solution of the equations of motion, whether they are integrated or not (thick or thin), will include the particle's momentum - which is necessary to consider the chromatic effects.

[chernals]

@alatina Based on your last comment, I think we are exactly on the same page on the issue.

@ldeniau OK, I see! What I meant by first order is for the thick elements in MAD-X.

[rdemaria]

I think we are not fully understanding each other. In TWISS deltap is a parameter while pt is coordinate. With deltap you change the 6D closed orbit, with PT generate a particle that oscillates around the closed orbit with deltap=0. In TRACK there no deltap option like in TWISS, but delta is put on PT which is quite confusing. Ideally one would like to track particles with a mismatched energy therefore being able to set deltap and PT independently

[chernals]

@rdemaria Yes, I agree, but how does this relate to the issue here?

[ldeniau]

On 17 Feb 2021, at 14:45, Riccardo De Maria notifications@github.com wrote:

I think we are not fully understanding each other.

I agree ;-) In TWISS deltap is a parameter while pt is coordinate. With deltap you change the 6D closed orbit

The 5D closed orbit, dp does not affect pt… The problem is that dp is not defined in 6D neither in MAD-X nor PTC, where it is converted into pt as you say... , with PT generate a particle that oscillates around the closed orbit with deltap=0.

I agree. In TRACK there no deltap option like in TWISS, but delta is put on PT which is quite confusing. Ideally one would like to track particles with a mismatched energy therefore being able to set deltap and PT independently

In 5D, pt and dp can be handled the "same way", with the “drawback” that integration order must be increased for better convergence of chromatic effects (e.g. induced by non-zero pt in the drifts).

I think that one should be able to “emulate” 5D behaviour MAD-X in 6D using the one of the two methods (to be studied):

1- Convert dp to pt and search for the closed orbit with mismatched energy (i.e. ending with a pt=0 since you have RF on). 2- Set pt of damaps/particles to whatever and run around the previous closed orbit.

Step 1 is compatible with 5D.

OR

1- Convert dp to dE to update the beam energy and search for the closed orbit with mismatched energy. 2- Set pt of damaps/particles to whatever and run around the previous closed orbit with previous beam.

Step 1 is NOT compatible with 5D, i.e. interpretation differs.

Cheers, Laurent.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MethodicalAcceleratorDesign/MAD-X/issues/847#issuecomment-780565687, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJILT5KVXNC2OMTMNYZCT3S7PB7VANCNFSM4JFZJHHQ.

[ldeniau]

You are right, I think the discussion is biased by the statements of this morning at the LNO meeting concerning a unification of the physics between Track and Twiss...

On 17 Feb 2021, at 15:03, Cédric Hernalsteens notifications@github.com wrote:

@rdemaria https://github.com/rdemaria Yes, I agree, but how does this relate to the issue here?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MethodicalAcceleratorDesign/MAD-X/issues/847#issuecomment-780577253, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJILT6ESAOQPEV44DSKP2LS7PECPANCNFSM4JFZJHHQ.

[chernals]

You are right, I think the discussion is biased by the statements of this morning at the LNO meeting concerning a unification of the physics between Track and Twiss... …

OK, then I missed that and was surprised by the volume of comments on this issue. But that's good!

[tpersson]

After some more thinking and checking I have been convinced by @chernals and @alatina that introducing the momentum dependency explicity is probably the most correct thing to do. The fringe field used are obtained from the expanded Hamiltonian and introducing the exact dependency off the momentum deviation is fine. The thing that made me most confused was that we don't do this, and should not do this for multipoles, but that is different since we can solve exactly for a thin multipole. The only issue is that it is different from the implementation in TWISS but I don't think we anyway have consistency between the two...

I think the discussion to introduced a "real deltap" in MAD-X TRACK is very interesting but not fully connected to this discussion but something we should have at some point.

[rdemaria]

Let's define PX, PY, PS, E, Q, M the position, momenta, energy, charge and mass of a particle not normalized. T is the time in the laboratory frame. Then we define P0 to a reference momentum which is used to normalize all the fields (magnets and RF-mutipoles) and delta_s a momentum error such that Ps=P0*(1+delta_s) is the desired momentum of a particle on the closed orbit. Let's also define beta_s, gamma_s, Es such that Ps=beta_s Es=beta_s gamma_s M. We also introduce eta as the momentum compaction factor defined by Cs=(1+eta delta_s) C where C is reference machine length corresponding to P0.

Twiss uses the following 6D normalized canonical coordinates: px=PX/Ps, py=PY/Ps, pt=(E-Es)/(cPs), x=X,y=Y, t=(1 + eta delta_s)/beta_s s - cT

one can define delta= sqrt(pt^2 + 2 pt/beta_s +1), but in general delta it is not equal to delta_s which is an independent parameter. Thanks to eta delta_s in the definition of t, the closed orbit will be x=delta_s Dx, y=delta_s Dy, ..., pt=0 even in presence of an RF cavity.

Track instead uses the same coordinates but with strictly delta_s=0 px=PX/P0, py=PY/P0, pt=(E-E0)/(cP0), x,y, t=s/beta_0 - cT

The closed orbit will be always 0 in the presence of an RF cavity, unless one uses a trick of increasing RF phase linearly as a function of turn.

This implies that the map of a thin quadrupole of a integrated gradient B1 L = k1 L * P0c / Q in TWISS is : px_final= px_initial + k1L/(1+delta_s) x

while in TRACK we have px_final= px_initial + k1L x

This should be the same for the dipole edge.

Do we agree on this?

When I mentioned the unification of twiss and track, I meant introducing in track the delta_s dependence, as it was in MAD-8, but without loosing the symplecticity gained in MAD-X. The cost of it is to add a term (1+delta_s) every time there is a normalized field and add eta delta_s L /beta_s every time there is a thick map and clearly remove the redefinition of pt.

[alatina]

@rdemaria A very brief comment: take the drift for example. The map in TWISS is not exact. For this reason the map in TRACK was replaced with the exact one. which assumes the use of the trace space variables xp = px / pz yp = py / pz and not of the canonical variables, px and py.

If we do as you suggest, the chromatic effects of the dipedge will disappear from tracking. This is unphysical...

[rdemaria]

You could define an exact drift using TWISS coordinates. See mad-8 physics guide (unfortunately the published version has a typo, the screen shot is the version in overleaf):

This can be further simplified the sqrt is simply pz which is sqrt( pt^2+2 pt/beta_s + 1 - px^2 -py^2). Please note both pt and delta_s are part of the map, with different meaning.

Under the usual approximation a field change PX therefore regardless of the energy of the particle. Clearly x'(s)=px/pz(px,py,pt) ~ PX/P = px/(1+delta(pt)). Now if px=PX/Ps=PX/(P0(1+delta_s)) and the field B1/P0c*Q, as in TWISS, you need to add the delta_s dependency. But in TRACK we have delta_s=0.

[alatina]

Sure, one can write the exact drift using the TWISS coordinates (or any other coordinates), it's just a substitution of variables. Yet, this is not what's implemented in TWISS. And for a very specific reason: TWISS performs optics calculation up to second-order max. In fact, the drift is implemented as transfer matrix + 2nd order terms.

So I insist: let's decouple TWISS from TRACK. They are different modules, with clearly different purposes...

[ldeniau]

On 17 Feb 2021, at 18:31, Riccardo De Maria notifications@github.com wrote:

You could define an exact drift using TWISS coordinates. See mad-8 physics guide (unfortunately, the published version has a typo, the screenshot is the version in overleaf):

https://user-images.githubusercontent.com/54369/108241592-4b513b00-714c-11eb-93b2-7ce15ef4730e.png This can be further simplified the sqrt is simply pz which is sqrt( pt2+2 pt/beta_s + 1 - px2 -py**2). Please note both pt and delta_s are part of the map, with different meanings.

Under the usual approximation a field change PX therefore regardless of the energy of the particle. Clearly x'(s)=px/pz(px,py,pt) ~ PX/P = px/(1+delta(pt)). Now if px=PX/Ps=PX/(P0(1+delta_s))

Could clarify the difference with the method 2 I explained before which basically integrate (1+delta_s) into P0 here? and the field B1/P0c*Q, as in TWISS, you need to add the delta_s dependency.

Which already the case in method2.

My feeling is that we are mixing two things, motion equations in a reference frame and "some" features needed to study perturbations around these equations. PTC doesn’t have any delta_s still you can do all perturbations studies that you want. It is possible that MADX-PTC (remember my naming convention) takes some shortcuts to ease users' life, but this is not necessarily the best approach.

But in TRACK we have delta_s=0.

Did you try to play with separate orbits like in method 2 (6D)? I guess that it is possible to do it with any tracking code and this is maybe why the previous generation who wrote these codes didn’t need to introduce it. The case is very different for matrix code like Twiss where derivatives are explicit…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MethodicalAcceleratorDesign/MAD-X/issues/847#issuecomment-780722179, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJILTYTPKPC6ONBXUHBCV3S7P4Q5ANCNFSM4JFZJHHQ.

[rdemaria]

@tpersson if you introduce a PT dependence in the kick of track, you must also have a change in T and check that everything is symplectic.

[tpersson]

@rdemaria Good point, in order to do it correctly I agree that one would have to introduce a time compensation. So my conclusion at the moment would be: It is possible to do and should give more correct results, if the time compensation is include. However, for our cases the impact is negligeable and it would take some effort to include this correctly into TRACK. Do you agree?