Page 1 of 1

optimization of R56 for non ultra-relativistic energies

Posted: 11 Jan 2012, 07:42
by Philippe Piot
Hi,
I have been struggling with imposing lattice constraints involving matrix elements that contain the longitudinal coordinate "s" while dealing with low energies beams. After some exchange with Michael Borland, I introduced a R76=d\delta/dt and try to impose a constrain on this element. Right now I derived R76 as a function of R56 (check my attached pdf file for the "recipe" I use -- it is detailed so anybody can point out any mistake/ wrong assumption I hope).
I code my eq. (9) in the attached pdf as the optimization term

&optimization_term
term="299792458 sto c; pCentral pCentral * 1 + sqrt sto gamma ; -1 gamma gamma * / 1 + sqrt sto beta; beta c * R56 sto numer; -R56 Cs * pCentral * pCentral / 1 + sto denom; numer denom /"
&end

It seems to work well (=it runs). I am just not sure whether I should use Cs for the total pathlength "s"? Plus I hope somebody who might have done similar things would double check what I did. Finally in my calculations the velocity remain constant over the beamline and I am wondering how would one generalize to varying velocity (in case a accelerating cavity is introduced). I am afraid one would have to introduce R76 in elegant?

Thank you for any comments! -- Philippe.

Re: optimization of R56 for non ultra-relativistic energies

Posted: 11 Jan 2012, 17:56
by michael_borland
Philippe,

I think there's a problem with your derivation: you use R56=ddelta/ds, whereas R56=ds/ddelta (5=s, 6=delta).

Taking R76=dt/ddelta and using t=s/(beta*c), I get

dt/ddelta = R56 -s0/(c*p0*gamma0)

This can be expressed in rpn as

R56 Cs c_mks / pCentral / pCentral sqr 1 + / -

I agree with your suggestion to add this to elegant internally. Otherwise, it will be hard to accommodate beamlines with varying energy.

--Michael

Re: optimization of R56 for non ultra-relativistic energies

Posted: 12 Jan 2012, 06:42
by Philippe Piot
Thank you Michael,
You are right I got confused and actually mistyped my indices (I am actually interested in constraining both R76 and R67 too). However for R67 I think my formula should indeed be:

"pCentral pCentral * 1 + sqrt sto gamma ; -1 gamma gamma * / 1 + sqrt sto beta; beta c_mks * R65 sto numer; -R65 Cs * pCentral * pCentral / 1 + sto denom; numer denom /"


Now regarding R76, I think there is a dimensional problem with your equation R76=dt/ddelta = R56 -s0/(c*p0*gamma0)? (BTW I could not figure out how you converted this equation to the rpn notation you have -- I believe you have an extra sqr? ). Shouldn't the equation be R76=dt/ddelta = R56/(beta*c) -s0/[c*(beta0*gamma0)^2] and the corresponding rpn equation.

"pCentral pCentral * 1 + sqrt sto gamma ; -1 gamma gamma * / 1 + sqrt sto beta; R56 beta c_mks * / Cs c pCentral sqr * / +"

Sorry for bringing more confusion... Thank you for your help/comments! -- Philippe.

Re: optimization of R56 for non ultra-relativistic energies

Posted: 12 Jan 2012, 09:47
by michael_borland
Philippe,

Sorry for the confusion, I did indeed leave of a factor in the R56 term in R76. The equation for R76 should be

R76 = R56/(beta*c) - Cs/(c*p*gamma)

I derived this with Maxima.

beta=p/gamma, so
R76 = R56*gamma/(p*c) - Cs/(c*p*gamma)

So the RPN version is
pCentral sqr 1 + sqrt = R56 * pCentral / swap pCentral * rec Cs * - c_mks /

--Michael

R71, R72 optimization of R56 for non ultra-relativistic ener

Posted: 03 Apr 2012, 14:52
by Philippe Piot
Hi,
I have been fighting on and off with imposing constraints on matrices used to track a non-relativistic beam (beta*gamma~2.7). I think there is still something I am not getting...
I would like to impose a constraint of the form
A*R51+B*R52=0,
where A and B are constants. Since R51=ds/dx_0 and I am dealing with non-relativistic beam I introduced R71=dt/dx_0=1/(beta*c)*R51 and likewise for R72. So my constraint takes the form
A*R71+B*R72=1/(beta*c)*(A*R51+B*R52)=0
which is the same as A*R51+B*R52=0 since the 1/(beta*c) is in factor.
When I impose this constraint for a relativistic beam (with special incoming correlation), it works as expected but if I decrease my momentum to my desired value ~2.7 it does not give the results I expect. So I think there is still something wrong in my reasoning. I hope somebody can let me know what I still do not get... Thank you very much, -- Philippe.

Re: optimization of R56 for non ultra-relativistic energies

Posted: 04 Apr 2012, 06:36
by Philippe Piot
Hi,
I am attaching a file that demonstrates what I am trying to do. With momentum set to 1000.72 it all work as I would expect (final longitudinal phase space is upright). If I decrease the momentum (say to 10) the fitting satisfies the matching condition but the tracking results in a final distribution which has a large longitudinal phase space chirp. Thanks! -- Philippe.

Re: optimization of R56 for non ultra-relativistic energies

Posted: 05 Apr 2012, 08:07
by michael_borland
Philippe,

FYI, I'm looking into this but so far don't have an answer.

--Michael

Re: optimization of R56 for non ultra-relativistic energies

Posted: 05 Apr 2012, 09:54
by Philippe Piot
Thank you Michael. I have also played more and noticed that altering my condition and setting the condition so that the right-hand-side is not zero allows me to bring back my final phase space up right. The value I have to set changes with pCentral. Best, -- Philippe.

Re: optimization of R56 for non ultra-relativistic energies

Posted: 09 Apr 2012, 08:18
by michael_borland
Philippe,

It took a while, but I understand now what the problem is. Unfortunately, there's no straightforward solution. The basic issue is that elegant uses (s, delta) as the longitudinal coodinates. This means that variation in particle velocities can't be incorporated into the matrix formalism. When tracking, elegant handles this correctly by using t=s/(beta*c) to compute arrival time at elements (e.g., RFCA) that have time-dependence. For gamma>>1, of course, things agree very well.

Two suggested solutions when gamma is not large:
1. Do the optimization by tracking particles, not using matrices. If you set DISABLE=1 on the WATCH elements (to reduce I/O) and reduce the number of particles, this can be reasonably fast.
2. Try MAD8, which uses (c*t, delta) as the longitudinal coordinates. If you look, e.g., in the MAD8 Physical Methods Manual, you'll see that the equations for matrices have beta and gamma in them, so the time of flight variation is included.

--Michael