Open ax3l opened 1 year ago
For users that want a purely 2D space charge solution, @WeiqunZhang suggests we can already quick-hack this by:
Furthermore, it might be useful for this solver to limit domain decomposition to be purely longitudinal.
solving in 3D We have to modify the solver so that the stencil is 2D only. So it's essentially solve multiple 2D problem at the same time.
Does the charge density need to updated too?
I'm not sure about this approach. My concern is how best to handle the longitudinal variation of the charge density, and in the resulting transverse fields.
The fixed Z - fixed T transformation can have a large effect on the charge density for long bunches, and can result in significant errors in the beam's longitudinal density. Also, theoretical models for long bunches often assume that the space charge fields are truly 2D (eg, a self-consistent K-V beam), and it is useful to capture this in simulations.
One approach that I used with some success in IMPACT-Z is:
1) Turn off the fixed Z - fixed T transformation. 2) At each step, project the 3D charge density into the 2D x-y plane by summing over the longitudinal bins. 3) Solve the 2D Poisson equation using the projected density. 4) Apply the appropriate transverse kick to all particles with the same (x,y), independently of the the longitudinal coordinate.
This re-uses the data structure for the 3D grid, but the Poisson solve and push are based on the 2D self-fields. However, it's not clear how best to modify this for the case of a non-uniform grid.
Another option is to use a periodic boundary condition in the longitudinal coordinate. However, in practice this requires a high longitudinal grid resolution in order to avoid numerical instabilities, so it can be slow.
For clarification: Ji's symplectic spectral solver does not use open boundaries. Instead, it assumes a rectangular conducting boundary. It is best for cases in which the (2D) charge density is smooth, and for many-turn simulations (in which the symplectic property and low noise are important).
Thank you for the clarification and sorry for mixing things up! 👍
We currently implement a 3D space charge solver, but for many cases a 2D (transverse) solver would be sufficient.
There are two options we are interested in, for different science cases: