SBEND3D - Off Momentum beam

Valeria: can you add the graphs if possible I need to catch the train to my vacation :) Thx

I have repeated the same analysis with a simplified field map of a Combined Function Magnet.

Field map

Dipole angle: 120°
Nominal energy: 230 MeV (P0 = 0.74186 BetaGamma)
Hard-Edge model

1 - First analysis: nominal energy

Edes = 230 MeV
Beam distribution from file: track of a special particle -> dispersion function with 1% dp/p from the reference momentum

0.000 0.0000 0.0000 0.0074186 0.0000 0.0000

The result is

2- Second analysis: off-momentum beam

Edes = 230 MeV
Beam distribution from file: All the particles (except 2) have a shift in momentum (py = 0.100151) that corresponds to an energy of 288 MeV. The two not-shifted particles are:
Reference particle

0.0 0.0 0.0 0.0 0.0 0.0

Dispersion function defined as before. The 1% dp/p is calculated with respect to the nominal energy (230 MeV) and not to the off-energy (288 MeV)

The trajectory for the dispersion and the reference particle is shown here

Comments

In case of an off-momentum beam, the mean energy differers from EDES (set in the input file) and is correctly displayed in the cout.
The reference trajectory in the plot is not a straight line as supposed to be, but behaves as a particle with a certain momentum shift with respect to the mean evaluated energy.
In the same way, the dispersion function is supposed to be referred to the 230 MeV and to have a same behavior in both simulation.

changed title from SBEND3D Local global problem to SBEND3D - Off Momentum beam

For this sort of analysis I usually consider particles in the global frame; for analysis I handle any transformations to the local frame by hand. E.g. for the ring work I do, I usually do a transformation into cylindrical coordinate system. OPAL does all tracking in the global frame (RK4 in Cartesian coordinate system).

You hope that whatever output code will transform into some other coordinate system, maybe the coordinate system of some reference particle? How are you doing the output? What coordinate system do you want the output to be in?

For this kind of analysis, I use only the H5file: TH5Dataset data("SCGantry.h5");

For each time step t, I access to the NTuple, containing the position and the coordinates in Local Frame of a specific particle (reference or dispersion)

TNtupleD *nt = data.GetNtuple(t);
double POS = data.GetSpos(t);
               
nt->SetBranchAddress("x",&x);

Then I plot

Track->SetPoint(t, POS,x*1000);

I was thinking to do the transformation in the data analysis too, because something is not really clear to me in the local frame statistics (see also Issue #25 (closed)).

The global frame works fine if the beam has no momentum shift and only few particles have some py-offset. In this case:

the beam energy evaluated from the distribution coincides with EDES (design energy)
the particle 0.0 0.0 0.0 0.0 0.0 0.0 corresponds to the reference particle
I could use the two or three off-momentum particles to test the achromaticity of the system. As first analysis, this is perfectly fine since I get something like Global-Frame

When I want to simulate the effect of a completely off-momentum beam and study some beam properties (beam size, position, divergence, emittance ...) then

the beam energy evaluated from the distribution does not coincides with EDES (design energy)
the particle 0.0 0.0 0.0 0.0 0.0 0.0 does not corresponds to the reference particle (as you can see from Off-Momentum-Reference)
it seems that the tracking of the particles is refererred to the new evaluated energy and not to EDES.

How would you set your input file for this kind of analysis? Assuming that 230 MeV is your nominal energy and 288 MeV the shifted beam:

Option 1
EDES = 0.230
Particle distribution with shifted py
Option 2
EDES = 0.288
Particle distribution with no shifted py

Thanks, I will have to see what is going on. Could you post the files I need to run your example?

I cannot upload the file here in gitlab. The field map is too huge.

I could copy them in a shared directory on Dropbox or give you access to the afs directory where I run my simulation. Please, tell me what you prefer. If you have a PSI account, then Achim could easily give you access.

Dropbox works best for me.

In case of Option 1, the plot of the REFR vs SPOS shows a reasonable result only with the Local Cartesian Offset sets to zero.

In the normal configuration, the Local Cartesian Offset is set in order to create 1 m drift space before the map

offset: LOCAL_CARTESIAN_OFFSET, end_position_x=1000.0, end_position_y=0.0, end_normal_x=0.0, end_normal_y=0.0;

Plot REFR vs SPOS

With LCO: end_x = 1000
Without LCO: end_x = 0.0

REMARKS

Units should be added to the H5root GUI for the REFR
SPOS indicates the bunch position always in LOCAL FRAME
It is better to keep the LCO in the beamline definition (even if it set to zero) since it create an infinite space where the particles survive -> beam is not lost at the end of the field map.

changed milestone to %12

changed milestone to %OPAL 1.5.2

mentioned in issue #25 (closed)

added Bug label

I think this is now closed. Let me know if you have any further questions.

closed

Dear Chris,

before closing the issue, I would like to understand the Reference trajectory plot. I will briefly summarize my simulation.

The plot shows the trajectory of the particle ID1 with:

(x,px,y,py,z,pz) = (0.0, 0.0, 0.0, 0.0, 0.0, 0.0)

where py = 0.0 indicates that the longitudinal momentum of ID1 corresponds to the nominal beam energy Edes. So for a beam with energy Edes, the particle ID1 would be the reference particle.

However, this plot refers to a particular simulation: all the particles in the beam (except ID1) have a non-zero py. The resulting beam energy is hence different from Edes -> OPAL evaluated it properly.

After reading the particle distribution from a file, I load the magnetic field map of my beamline. The value of the magnetic field has been set in order to bend a beam with energy Edes. What I am trying to test is the effect of an off-momentum beam on the beamline.

In summary:

The magnetic field values are fixed because reading from an external field map.
The beam energy is different from the nominal Edes because of the particles shift in the py-component.
However the definition of the particle ID1 should be unchanged.

In conclusion:

Particle ID1 has the right energy, or better, the design energy of the field map.
Therefore, I don't understand why the trajectory of the ID1 is not a straight line (as, I think it should be) but this

What do you think about? I hope the situation is clear. If it is not, please, ask me again. I will try to explain it better.

Thanks a lot for your help

I think the plot shows the position of particle with ID1 relative to the mean position and momentum of the bunch. You could try plotting the mean position of the bunch in Global coordinates, compared with the position of particle ID1, and demonstrate that they are different.

Yes, you are right. Here attached the plot in global frame:

where:

the centroid (green line) reflects the trajectory of the off-momentum beam -> OK
the ID1 (red line) reflects the trajectory of the reference particle -> OK

I think I got why in the local frame the plot is wrong: it is related on what you wrote in the Issue25: I noted that the "transform to local coordinates" algorithm transforms to the coordinate system of the ensemble mean R and P.

Of course in my case, the meanP and meanR were updated to the new shifted-beam energy and this means that the transformation global -> local returns not the expected result.

Good!

I think the better solution is to use a reference trajectory for the local frame. I can put it on my job list to change the global-to-local coordinate transform but at the moment I am full for most of the year!

I think this issue is not solved. We get a different answer depending on global/local frame.

Here I how I understand the issue:

a) in case of tracking in global frame, as shown above (https://gitlab.psi.ch/OPAL/src/uploads/ca3ee675adc5dcdc585c95fc9aae573b/Track_GlobalFrame.png) we get the expected results. b) in case of tracking in the local frame, the user comping from TRANSPORT, COSY etc. expect for the reference trajectory a straight line https://gitlab.psi.ch/OPAL/src/uploads/56ebd77ae7c665afc74f5aede71ca805/OffMomentum_Dispersion.png. In the local frame this is not the case because the centroids energy is used and NOT P0 from the beam. In case of degraded simulation for example this poses problem.

A simple solution could be adding an OPTION to switch from centroids energy to P0.

I think we should discuss this in depth and provide a sound solution.

reopened

added ~47 ~48 labels

Andreas asked me to add a change so that we can do a coordinate transformation to the reference particle frame. I just pushed this to the master.

Nb: I defined a new control parameter like

Option PSDUMPFRAME REFERENCE

documentation says: \item[PSDUMPFRAME] \index{OPTION!PSDUMPFRAME} Control option that defines the frame in which the phase space data is written for h5 and stat files. \begin{itemize} \item \verb|GLOBAL|: data is written in the global Cartesian frame; \item \verb|BUNCH_MEAN|: data is written in the bunch mean frame or; \item \verb|REFERENCE|: data is written in the frame of the reference particle. \end{itemize}

I also added the changes to 1.6 branch

@rizzoglio_v can you test asap so we can possible close the issue.

@rizzoglio_v if we can not test this within one day, I will move this to OPA 1.6.1

added ~51 and removed ~47 labels

changed milestone to %OPAL 1.6.1

Test:

cloned and compiled the OPAL-1.6 branch
adapted and used the input file 120_deg_CFM.in:
reference energy Edes = 0.230 MeV
beam energy (due to momentum shift) = 0.288 MeV
added the option: OPTION, PSDUMPFRAME = "REFERENCE"
performed data analysis with root scripts -> trajectories of:
reference particle ID1 @ 230 MeV
off-momentum: ID14 @ 288 MeV
other momentum offset: ID11 Dp/p = 10%

Summary:

In the local frame, the trajectory of a reference particle does not follow a straight line as expected. Due to #102 (closed) or to a problem related to the defined reference particle in OPAL?
In the global frame, the tracking of a reference particle follows the reference orbit as expected.

Is this issue now closed with release of 1.6?

This issue still open and scheduled for 1.6.1. However we do a have a rc-1 so an eventuall fix can still sneak in

mentioned in issue #23 (closed)

Was there still something wrong in 1.6? I just checked that it ran and thought it looked okay.

I think no pls check the post of Valeria Rizzoglio above ...

I think that the code is working. I attach 2017-04-22_local-coords.tar.gz. This file contains a lattice with 500 mm drift only. When I run the lattice in reference/bunch_mean/global mode, I get the h5 files in the tarball like

PSDumpTest_bunch_mean.h5
PSDumpTest_reference.h5
PSDumpTest_global.h5

I found a python library to load h5 files, which I have used for testing. It's in the script load_h5.py. I print the x position for each setting at step 1 and step 3 respectively:

PSDumpTest_global.h5
Step#0 
    x        1.001
    x        1.001
    x        1.01
    x        1.1
    x        1.12
    x        1.15
Step#3 
    x        1.001
    x        1.001
    x        1.01
    x        1.1
    x        1.12
    x        1.15

PSDumpTest_reference.h5
Step#0 
    x        0.001
    x        0.001
    x        0.01
    x        0.1
    x        0.12
    x        0.15
Step#3 
    x        0.001
    x        0.001
    x        0.01
    x        0.1
    x        0.12
    x        0.15

PSDumpTest_bunch_mean.h5
Step#0 
    x        -0.0625
    x        -0.0625
    x        -0.0535
    x        0.0365
    x        0.0565
    x        0.0865
Step#3 
    x        -0.0625
    x        -0.0625
    x        -0.0535
    x        0.0365
    x        0.0565
    x        0.0865

I note that even in Reference mode, the "0" particle does not get x = 0. This is because a new feature has been implemented that creates a special "reference" particle automatically to have radius corresponding to the RING_DEFINITION BEAM_RINIT and momentum corresponding to the BEAM PC. Does that help any?

The fact that in a drift space the ID0 particle does not get x = 0 was suspicious to me. I had the feeling that the #ID0 particle stored in h5 file has been removed and replaced with a copy of #ID1. This was an artificial way to fix the problem with the "old reference particle ID0".

So I ran your input file: PSDumpTest.in with OPAL-1.6, set OPTION, PSDUMPFRAME=REFERENCE; and changed the first three particles of your beam in the following way:

6
0.000 0.00 0.000 0.00 0.00 0.00
0.150 0.00 0.000 0.00 0.00 0.00
0.000 0.00 0.000 0.00 0.00 0.00
--- original beam from Chris

Here the plot of the horizontal position of these three particles:

The black line of #ID0 is hidden by the purple line of #ID1. This is confirmed looking at the content of the first step of PSDumpTest.h5. It shows that the first two particles are identical: the particle #ID0 has been removed and replaced with a copy of #ID1, as suspected.

You could check yourself if this is the case also for you... it could be that I did a mess with the OPAL versions.

I see. @winklehner_d - do you know what the deal is with the new reference particle stuff? Is the reference trajectory taken to be ID1 (not ID0)?

Hi, I will have to read through this long post more carefully, I think, but to answer your last question @ext-rogers_c, I did not yet upload any changes w.r.t. the reference particle stuff. @adelmann wrote a nice little class for tracer particles that will replace the reference particle within the bunch completely soon. But for now, as far as I know - and this is cyclotron tracker only! - for > 2 particles, the particle with ID0 is artificially set to have local position 0, 0, 0 and momentum 0, 0, 0 at the very beginning, during initialization, and is supposed to be the reference particle. I was not aware of it being overwritten with ID1 at any point. The particle with ID1 is an arbitrary other particle from the bunch, or presumably the second particle in the file when TYPE=fromfile.

Is all of this using OPAL-cycl? Or are you seeing the same behavior in OPAL-T? Which tracker are you using (MTS, RK4, LF2)?

You can compare the particle data with the *-trackOrbit.dat file which is written by a different method and only stores particles ID0 and ID1.

Best, Daniel

A short note: the new tracer particles are first for OPAL-cycl and OPAL-2.0.0. There is NO plan (so far) to add them to OPAL-1.6.x

@adelmann: please check if ID0 is still replaced in the h5.

The situation concerning this issue is clear:

if PSDUMPFRAME = REFERENCE the conversion global frame -> local is done using a reference particle with coordinates (0,0,0).
if the beam OFFSETZ >0.0, the beam and the reference particle have different position since the vertical coordinate of the reference particle is not updated in the same way.
The different position of the beam and reference particle leads to a wrong conversion global->local frame.

A possible solution would be:

shift the field map and place the mid-plane to z = 0
the beam and the reference particle have the same vertical position
however it seems that there are problems in reading a field map with negative vertical coordinates (@adelmann further tests are needed)

The immediate solution for this issue would be performed the conversion global->local autonomously in the post processing analysis.

shift the field map and place the mid-plane to z = 0

3D field map placement is possible, but it would take a bit longer. Getting the coordinate transformation right may be fiddly.

the beam and the reference particle have the same vertical position

Implementing capability to have reference trajectory off the midplane would be a new feature. It would not be too difficult to implement.

however it seems that there are problems in reading a field map with negative vertical coordinates

I think negative vertical coordinates are not implemented. I could make the error message clearer. The code assumes that 0 is the midplane, and gets confused if it is not.

added OPAL-cycl label

changed milestone to %OPAL-2.2.0

@gsell I have almost implemented a fix which would enable PROBE-like output in the coordinate system of the reference trajectory, which I think addresses this issue. I need to do some testing and debugging. I thought we agreed not to target OPAL2.2 for this feature. Do you want me to try to get it done for 2.2?

@ext-rogers_c if possible: yes otherwise it should go into version 2.4

changed milestone to %OPAL 2.4.0

@ext-rogers_c can we close this?

@adelmann I would love to - it isn't done yet however. This is effectively a feature request (PROBE in frame of reference particle). I have proto-code but not got the proper level of testing.

removed 1 deleted label

@ext-rogers_c do you have time to get this done for 2.4.0 (end of July)? Or should we postpone it till 2.6.0 (end of October)?

Please postpone. Sorry!

changed milestone to %OPAL 2021.1

changed the description

added Feature request label and removed Bug label

removed milestone

changed weight to 4

assigned to @adelmann

changed due date to June 14, 2021

changed the description

SBEND3D - Off Momentum beam

Designs

Child items ...

Activity