Elegant users forum

Hello All,

I am confused on what the "-" operator does in the beamline definition. I am trying to backtrack a given "final-ideal" distribution to find out the initial distribution parameters I need for a given beamline.

I define my beamline as "Beamline" and track my final desired distribution in a beamline defined as "rev_Beamline: line= (-Beamline)".

As a consitency check, I used the final output distribution from the tracking in rev_Beamline, as a input for tracking in Beamline. I would have then expected that the final distribution would match the final-ideal distribution I started with. It does not...

Am I misunderstanding the use of the "-" sign in the beamline definition? Note that my beamline incooprates a deflecting cavity supplied as a MATRIX element.

Thanks for any help and suggestions, -- Philippe.

Philippe,

Elegant doesn't provide a way to perform backtracking. Speaking in matrix terms, the '-' operator reverses the beamline and matrix, whereas what we need for backtracking is the inverse matrix. This is easiest to explain for a drift:

D1: drift,l=1
BL: line=(D1)
BLR: line=(-D1)

BL and BLR are in fact identical because the drift is identical when reversed. What we'd need for backtracing is a drift with L=-1, which is the inverse operation.

I'm thinking about how this might be done.

--Michael

Philippe,

To backtrack through the beamline BL, try the following:

ref: magnify,mxp=-1,myp=-1,ms=-1
blr: line=(ref,-bl,ref)

Seems to work in my simple tests.

--Michael

Philippe,

It works exactly for default_order=1 using matrix transport only, but otherwise it isn't quite right. Not sure why...

--Michael

Hello Michael,
Thank you very much for your answer. I realized I misundersttod what the "-" operator in front of a beamline was doing. I have tested your suggestion and it works fine on several simple example. However it turn out not to be working for the system I was studying a fully-coupled beamline; see attached tar file.
The file listed in this tar file are
latticeTEST.lte the beamline description file
TCAV0length.MATRIX a file with the matrix of a deflecting cavity
backwardtrackingTEST.ele the command file to do the backtracking,
normaltrackingTEST.ele the command file to do the "forward tracking"; this file uses an sddsbeam input distribution corresponding to the output of backwardtrackingTEST.ele .

What puzzle me is that if a chop part of the beamline (say only keep half of it) it works very well (the ouput of normaltrackingTEST.ele give the input distribution I use in backwardtrackingTEST.ele)...

Thanks for any help (if I find what was wrong I will let you know!). Best, -- Philippe.

Philippe,

I'm not entirely sure why your run doesn't work as expected, but it is related to the fact that the s coordinate is not a differential quantity in elegant. For that reason, I don't really recommend using MATRIX or EMATRIX in a case like yours. A better approach is to use RFDF or SCRIPT.

Here's an example that seems to work, using RFDF.

--Michael

Michael,
Thanks for all the details, now I understand the issue (could you elaborate on what is the problem with having s not a differential element -- I did not get this). Because of what I am trying to do, I want to use the transfer matrix of a cavity (or of the full beamline) -- this has to do with the fact that the matrix I want to eventually use was obtained from 3D tracking in realistic field.
I therefore decided to do my reverse tracking by simply using the inverse matrix of the beamline. What surprises me is that is works in one plane but does not in the other plane. Attached is a set of files to test what I doing. I reduce my problem in forcing elegant to track in matrices (this is just for testing purpose). The file EEX.MATRIX is the matrix of my beamline whereas EEXINV.MATRIX is the inverse matrix. I would expect if I track in a beamline define as line=(PEXINVMAT, PEXMAT) the input and output phase space distribution would be dead on. This is the case for (x,xp) and (y,yp) planes but not for (t,p)...
Thank you for any help! All the best, -- Philippe.

Hello,
OK, I still have a problem that if I track in a beamline that consist of two matrix element which are inverse of each other the final output does not match the initial input distribution; see attached tar file. I try to simplify my simulation to a simple dogleg.
I track in the beamline dogl_D=line=(W0, DD, PIPE,b1,PIPE, W1, b1_b2,PIPE, W2, b2, PIPE) , I record the matrix computed by elegant and save it in the file
EEX.MATRIX, I compute the inverse matrix *using the EEX_Rinv.m file and save it as EEXINV.MATRIX. I then track in the beamline dogl_DInv: line=(W0, PEXINVMAT, W1, PEXMAT) [which total transfer matrix should be identity] and obverse discrepancies between the input and output distribution longitudinal phase space (the transverse phase space are dead on]. Thank you for any help! -- Philippe.

Philippe,

The problem is the non-zero C5 value in EEX.MATRIX and the zero C5 value in EEXINV.MATRIX. Since there is energy spread, this drift results in time-of-flight dispersion. If you set the C5 values to equal but opposite in sign, it works fine.

--Michael

Michael,
This is a "companion post" to my recent post on the RFDF element issues. I would like to track a distribution through a beamline, rematch the output to my desired value and backtrack it to figure out what should be my initial distribution.
I am including an simplified example of what I am doing (in this example I actually do not rematch the distribution and just track it forward, backward and forward again). Here I simply
-1 generate a bunch and track it using fowardtrack.ele (I have a deflecting cavity and I model it with a MATR element (with C5 set to zero -- thin lens) because I do not understand what RFDF element is doing -- see my companion post of earlier today).
-2 take the output of forwardtrack and "backtrack" it through the same beamline using backtrack.ele [I define my inverse beamline using the multiply element (as we discussed few weeks ago) and the inverse matrix of the cavity
- take the output, backtrack.out, and track it forward in my forwardtrack_rematched.ele

I am attaching my file, and they can be run with ./runTest . I notice two puzzling things:
First, the final phase space of (2) backwardtrack.out does not match with the intial bunch forwardtrack.bun, but insepecting the evolution of the rms properties seems to indicate that my forward and backward tracking works properly.
Second, the final phase space of (3) forwardtrack_rematched.out does not match with my first pass forward tracking forwardtrack.out

When I initially was doing the rematch operation, I suspected the disagreement was due to my mishandling of the t coordinate (I tried to recenter the distribution, add an offset but nothing appear to correct my puzzling observations). In the attached simplified example I would expect "t" to be properly handled (as I am not externally modifying any of the distributions).

Thanks for your help!

-- Philippe.