Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved CSR modeling #120

Open
jonasbjorklundsvensson opened this issue Dec 15, 2021 · 3 comments
Open

Improved CSR modeling #120

jonasbjorklundsvensson opened this issue Dec 15, 2021 · 3 comments

Comments

@jonasbjorklundsvensson
Copy link

Hi,

I was wondering whether it is possible to implement an enhanced CSR model compared to the 1D case, as the 1D model results seem to (sometimes) be quite different from full 3D simulations, updated analytic theory, and experiments (see for example https://iopscience.iop.org/article/10.1088/1367-2630/abed6c and https://iopscience.iop.org/article/10.1088/1367-2630/aad21d and references therein). Is it possible to adapt the "new" analytical models in the code somehow?

I would be interested in using Ocelot for tracking for PWFA and such, which is very sensitive to bunch tilts (which is where I assume at least a good deal of the emittance growth comes from since the slice emittances in the references above are a bit smaller than the projected values). I have been using Elegant in the past, which also uses a 1D CSR model and evidently overestimates the emittance growth by quite a lot. I have seen the comparison between Ocelot and CSRTrack, but I guess the comparison is between 1D cases? It would also be interesting to see comparisons between something like x-t and/or x'-t projections for different codes/implementations, to me this is more important than the pojected emittance on its own.

It would be quite nice to be able to do the full simulation in one code and not have to switch between multiple codes while still getting relatively correct results (full 3D will mostly be "more" correct, I suppose).

Best regards,
Jonas

@jonasbjorklundsvensson
Copy link
Author

Hi,

Just a friendly reminder about this post :)

  • Jonas

@st-walker
Copy link
Collaborator

st-walker commented Mar 15, 2022

Hello Jonas,

It is very nice to hear from you. I was wondering what exactly you have in mind regarding implementing something additional in OCELOT? I am familiar with the paper you link and this method involving storing the full history of the slices and then using this to directly evaluate the Liénard–Wiechert potentials. This is implemented in GPT as I understand it. I've never implemented such an algorithm myself, but I am sure in principle it would be possible to do so in OCELOT. However I must add that such an algorithm is really quite computationally intensive though compared to 1D models, including the one implemented in OCELOT. It's not trivial.

It would also be interesting to see comparisons between something like x-t and/or x'-t projections for different codes/implementations

Yes, perhaps you can try OCELOT and compare with GPT and Elegant, a few codes, to see what is going on.

I have seen the comparison between Ocelot and CSRTrack, but I guess the comparison is between 1D cases?

When you say this, which comparison are you referring to? there is something relatively nice regarding comparisons here here for the Zeuthen benchmark chicane. Perhaps this is helpful.

Let me know what you think.

@jonasbjorklundsvensson
Copy link
Author

Hi again Stuart,

Sorry for dropping this for so long - other things came in between. I'll reply a bit out of order:

When you say this, which comparison are you referring to? there is something relatively nice regarding comparisons here here for the Zeuthen benchmark chicane. Perhaps this is helpful.

I was referring to the comparison between Ocelot and CSRTrack in the CSR tutorial (https://nbviewer.org/github/ocelot-collab/ocelot/blob/master/demos/ipython_tutorials/5_CSR.ipynb). I checked out the resource you linked, and this was a quite interesting read.

Yes, perhaps you can try OCELOT and compare with GPT and Elegant, a few codes, to see what is going on.

This is unfortunately too time-consuming for me for the foreseeable future, perhaps sometime further down the line.

I was wondering what exactly you have in mind regarding implementing something additional in OCELOT? I am familiar with the paper you link and this method involving storing the full history of the slices and then using this to directly evaluate the Liénard–Wiechert potentials. This is implemented in GPT as I understand it. I've never implemented such an algorithm myself, but I am sure in principle it would be possible to do so in OCELOT. However I must add that such an algorithm is really quite computationally intensive though compared to 1D models, including the one implemented in OCELOT. It's not trivial.

As performing this type of calculations and implementing them in simulations is beyond my competence, perhaps I underestimated the difficulty of extending the CSR model. It was my impression from the paper (see for example the 'Conclusions' section) that the 1D model could be extended to better agree with reality - this led me to believe that it was perhaps possible, and even relatively simple, to integrate these results in the 1D model in Ocelot, decreasing the need to use higher-dimensional simulations that include for example the transverse wake.

The reason I'm interested in this is that for plasma-wakefield acceleration, which is what I'm working on, the slice centroid offsets are of great importance for the bunch behavior in the plasma - hence being able to simulate them better is very interesting to me. However, I am also getting into optical CSR cancellation/mitigation schemes (for example a la Di Mitri, Cornacchia and Spampinati (https://journals.aps.org/prl/pdf/10.1103/PhysRevLett.110.014801)), and for this the model in Ocelot is perhaps sufficient. For a more or less constant bunch length, whatever the exact kick is in each dipole, the kicks should be the same and could be made to cancel out. Would you think that this also applies in cases where the bunch length changes through the dispersive section, or would this require a higher-dimensional code?

Best regards,
Jonas

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants