first_is_fiducial and p_central

[JoelFrederico]

I think I have a misunderstanding on how first_is_fiducial and p_central work together. I have a bunch with high energy (<p>=4e4) feeding into a lattice with just a bend, where p_central=2e4 in run_setup. With first_is_fiducial=1, the resulting x-centroid is -2.3e-7, which doesn't make sense. It seems to imply that elegant is somehow reading the input's momentum, even though I've specified a different momentum. With first_is_fiducial=0, the x-centroid is 6.0e-3, which makes more sense - it should be way off in x since the bend is designed for a bunch with half the energy.

I would expect that p_central would override first_is_fiducial at least in terms of momentum expansion. What is the correct way to look at this?

[JoelFrederico]

Also, with first_is_fiducial=1, I changed p_central, and the centroid never changed.

[michael_borland]

Joel,

When you set first_is_fiducial=1, elegant redefines the reference momentum (p_central) to match the first beam that it sees. That means the beam has Cdelta=0.

What are you trying to achieve by using first_is_fiducial? The intended use is when you are going to send in a series of beams and want the first one to establish a reference momentum and arrival-time profile. If you don't have acceleration or rf systems, it really doesn't serve much function.

--Michael

[JoelFrederico]

Michael,

Thanks for the info!

I'm actually trying to split a jitter simulation into parts. The first part works as expected. But then I dump the particles and notch collimate them, changing their average momentum. I want to reload the particles and simulate the second part of the beamline, without changing the beamline, so that all the fiducialization would be exactly as if I had never collimated. So I thought, use first_is_fiducial=1 and define momentum in p_central, and load in all of the particles. I didn't think it would make a difference to do it that way. It was just easier to not change first_is_fiducial from the initial run, since I use the same ele file and comment sections of it to turn things on and off. And then when I did that, the R56 of the beamline was off, since the fiducialization was done with a momentum that the beamline wasn't designed for.

My solution, I think, will be to use sddscombine to add on an untouched version of the fiducial bunch for the first part to the collimated bunches I load in the second part. That way, the second part will fiducialize correctly to the first part and the following collimated cases with "incorrect" energy will be simulated correctly.

Joel

[michael_borland]

Joel,

Yes, your solution is the right thing to do.

--Michael