transverse wake implementation

Moderators: cyao, michael_borland

Post Reply
jzemella
Posts: 8
Joined: 27 Nov 2013, 11:23

transverse wake implementation

Post by jzemella » 30 Jun 2015, 13:39

Hello,

I have a question concerning the implementation of transverse wake fields.
I like to simulate a corrugated structure consisting of two jaws (like the LCLS1 type).

How an off axis particle is treated?
I was asked if on an off axis particle acts a gradient and an extra kick due to the structure?
As I can see from manual there are two transverse wakes (horizontal and vertical)
which in my understanding refers to the gradient wakes.


Best regards, Johann

michael_borland
Posts: 1927
Joined: 19 May 2008, 09:33
Location: Argonne National Laboratory
Contact:

Re: transverse wake implementation

Post by michael_borland » 30 Jun 2015, 14:01

Johann,

I assume you are referring to the TRWAKE element here. By default, this provides a dipole wake, meaning that the kick depends on the coordinate offset of the driving particle but not on the coordinate offset of the trailing particle. If you want a quadrupole wake, set X_DRIVE_EXPONENT=0, Y_DRIVE_EXPONENT=0, X_PROBE_EXPONENT=1, and Y_PROBE_EXPONENT=1. In addition, one would typically give the same column name for WXCOLUMN and WYCOLUMN, but set XFACTOR=1 and YFACTOR=-1. This corresponds to a chamber with up-down and left-right symmetry. See A. Chao et al., PRSTAB Vol. 5, 111001 (2002).

--Michael

jzemella
Posts: 8
Joined: 27 Nov 2013, 11:23

Re: transverse wake implementation

Post by jzemella » 30 Jul 2015, 15:46

Hi Michael,

once again a question about transverse wake field implementation.

I have a question about how the field is applied to the particles.
Let's assume I have a Green's function for my problem in units [V/C/m] for both planes x,y.
I do not like evolve the field into dipole and quadrupole like fields. In fact it contains all multipole orders.

It this possible to apply such a transverse gradient, I calculated, to the beam?

And another question:
Does the solver calculates the forces acting on a trailing particle depending on the position difference of each particle ahead of the trailing particle and then summed up?


Best Johann

michael_borland
Posts: 1927
Joined: 19 May 2008, 09:33
Location: Argonne National Laboratory
Contact:

Re: transverse wake implementation

Post by michael_borland » 30 Jul 2015, 16:55

Johann,

If you mean that you have a Green's function G(x,y,z) that you'd like to use, without doing any multipole analysis to turn it into several functions Gi(z), then the answer is that elegant doesn't do that. It is of course possible to do that, but I imagine it would be very slow. One would have to do a 3d convolution instead of the 1d convolutions elegant uses now.

Right now, what elegant does is a convolution of the Green's function with the specified time-dependent moment of the particle distribution. E.g., for X_DRIVE_EXPONENT=1, elegant makes a histogram of the arrival times of all particles weighted by x. It then convolves that histogram with the Green's function, giving the wakefield. The wakefield is then used to compute the effect on each particle in the beam; this may involve the transverse coordinates of the trailing particle if, e.g., X_PROBE_EXPONENT is nonzero. Since the Green's function 0 for t<0, particles are only affected by particles in front.

--Michael

jzemella
Posts: 8
Joined: 27 Nov 2013, 11:23

Re: transverse wake implementation

Post by jzemella » 30 Jul 2015, 17:08

Hi Michael,

my wake field is splitted in the coordinates Gi(t) separately.
But I do not want to decompose my transverse field into a dipolar and a quadrupolar field etc.

I like to apply my however looking field gradient to the beam.

Am I right that I have to switch on both X_DRIVE_EXPONENT=1 and X_PROBE_EXPONENT=1 to get a linear dependence on the trailing part driven by the leading part of the bunch?


Best, Johann

michael_borland
Posts: 1927
Joined: 19 May 2008, 09:33
Location: Argonne National Laboratory
Contact:

Re: transverse wake implementation

Post by michael_borland » 31 Jul 2015, 11:25

Johann,

If you want the kick to the trailing particle to depend linearly on the x position of the leading particles, then use X_DRIVE_EXPONENT=1 and X_PROBE_EXPONENT=0. If you also use Y_DRIVE_EXPONENT=1 and Y_PROBE_EXPONENT=0, and supply Green's functions such that Wx=-Wy, then you'll have a quadrupole wake.

If you want a more general wake, I suggest writing a small program or script to implement the wake and calling it via elegant's SCRIPT element.

--Michael

Akhyani
Posts: 16
Joined: 26 Jun 2018, 08:09

Re: transverse wake implementation

Post by Akhyani » 07 Jul 2019, 03:04

Dear Michael and all,

As I understood from the previous replies in this post, ELEGANT does the convolution for the bunch distribution defined in the code. So, the wake input file must be the point-charge (Green) wake function. Is that right?
My second question is about transverse instabilities, in which the local beta function must be multiplied to each transverse kick of the particles. Does ELEGANT do this multiplication in tracking or I have to include this calculation in the wake input file?
Are there any other prerequisites for preparing the wake input file that should be taken into account?

Kind Regards,
Mina

michael_borland
Posts: 1927
Joined: 19 May 2008, 09:33
Location: Argonne National Laboratory
Contact:

Re: transverse wake implementation

Post by michael_borland » 08 Jul 2019, 09:08

Mina,

You are correct in thinking that elegant implicitly assumes that the wake input is the point-particle wake or Green function. In reality, this is hard to obtain except in those limited cases where an analytical expression is available, so most of the time we must make due with a result for a very short probe bunch. The issue here is that such data will have non-zero values for (i.e., for t<0, where t=0 is the center of the probe bunch). Thus, it will appear to be a-causal. Elegant's WAKE and TRWAKE elements will normally reject this, unless you set ACAUSAL_ALLOWED=1. Although distasteful, it is probably better than the other options (e.g., ignoring the t<0 part of the data, or folding it over). If your probe bunch is short compared to the time scales that are relevant in your bunch, this shouldn't matter. It is equivalent to using a low-pass filter on the bunch spectrum. See this presentation by Ryan Lindberg for more discussion:
https://indico.cern.ch/event/772326/con ... resent.pdf

One can equivalently use the ZLONGIT and ZTRANSVERSE elements to work in the impedance framework. In this case, elegant does not check the causality condition, so the fact that the input doesn't correspond to an actual Green function is essentially ignored.

As for beta-function weighting, you need to ensure that the transverse impedance contribution from each source (e.g., transition, BPM, flange gap) is multiplied by betaSource/beta0, where beta0 is the beta function at the location of the TRWAKE or ZTRANSVERSE element and betaSource is the beta function at the actual location of the impedance source. See Eq. 1 and discussion in
http://accelconf.web.cern.ch/AccelConf/ ... pje077.pdf

--Michael

Post Reply