desy-ml / cheetah

Fast and differentiable particle accelerator optics simulation for reinforcement learning and optimisation applications.
https://cheetah-accelerator.readthedocs.io
GNU General Public License v3.0
33 stars 13 forks source link

Add space-charge effects in Cheetah #137

Open RemiLehe opened 6 months ago

RemiLehe commented 6 months ago

It would be valuable to add space-charge effects in Cheetah.

This could be done by adding space-charge to existing elements by using the standard technique of sub-stepping through an element (used in other accelerator codes). For instance, a drift without space-charge

Drift(length=L)

would be replaced (here with 3 substeps) by

Segment(
    elements=[
        Drift(length=L/6),
       SpaceChargeKick(length=L/3),
       Drift(length=L/3),
       SpaceChargeKick(length=L/3),
       Drift(length=L/3),
       SpaceChargeKick(length=L/3),
       Drift(length=L/6)
  ]
)

One could use the integrated Green function method for SpaceChargeKick, described here: https://journals.aps.org/prab/abstract/10.1103/PhysRevSTAB.9.044204

This could then be benchmarked with examples from https://inspirehep.net/literature/1690374, as well as the example from the section "Free Expansion of a Cold Uniform Bunch" in https://inspirehep.net/files/178e98af93e0aaf3838a175835781aa0

ax3l commented 4 months ago

Small comment: I'll take a look at #142 :rocket:. Just for the above, technically, the space-charge kick is modeled like a thin element (always length=0) - but we do not see it as an element itself.

RemiLehe commented 4 months ago

Yes, we are aware that the space charge kick does not add length to the element (see for instance this comment). In SpaceChargeKick(length=L/3), length is the equivalent of slice_ds in ImpactX.

As suggested by @jank324, the above length argument should probably be renamed (e.g. effec_length), maybe as part of a follow-up PR to #142 .

ax3l commented 4 months ago

Yes. One aspect I forgot to mention and related to your link, it's not fully equivalent to our ds in ImpactX because we do not model space charge kicks conceptionally as elements. I stead, we slice elements (slice_ds=ds/N) and add collective effects between slices. For that reason, our space charge kick is not even a subclass of our thin elements (where we define ds=0), because it is not an element (in our concept).

As I said, just a comment. There are many ways to express this. Maybe we could make collective effects thin elements as well in ImpactX :)