Dear Dr. Borland and all,
Recently I have been using a component called “WAKE” to compare with the analytical results of energy spread caused by the resistive wall effect. First, I calculated and derived the wakefield file named “wake_monopole_resistive_wall.sdds” using an analytical formula, then used this wakefield to calculate the energy spread induced in a relatively long beam bunch. Subsequently, we compared this calculated result with the corresponding analytical result mentioned below, which is given by A.Chao in his book named “Physics of Collective Beam in High Energy Accelerators” page 113. However, we find there are some discrepancies between the two.
The equation and comparasion picture are attached, and the lattice I used is also attached.
As can be seen from the Figure, although the trend of the line formed by the blue points calculated by Elegant is similar to that of the green solid line from the analytical formula, there are still significant deviations. In particular, the two results differ drastically in terms of the overall parasitic loss.
I don’t know where the problem is. Maybe, it is because I made an error in using the Elegant. Here is the Files I use when I do the tracking.
Thanks a lot if anyone also encountered such a problem like me and can help me to find the bug.
calculation of parasitic loss by resistive wall
Moderators: cyao, michael_borland
calculation of parasitic loss by resistive wall
- Attachments
-
- lattice.rar
- (16.29 MiB) Downloaded 117 times
-
- formula.png (10.23 KiB) Viewed 8906 times
Re: calculation of parasitic loss by resistive wall
If you can supply your files in a different format, I will try to help. I tried decompressing them with the Linux unrar utility but I got the error 'Unrecognized archive format.' Thanks-
Ryan
Ryan
-
- Posts: 2
- Joined: 06 Oct 2025, 11:06
Re: calculation of parasitic loss by resistive wall
Hi Ryan,
Thanks a lot for your help. I have changed the format of the files, I hope this will work. Looking forward to your reply.
Best wishes.
Tang Jiazhen
Thanks a lot for your help. I have changed the format of the files, I hope this will work. Looking forward to your reply.
Best wishes.
Tang Jiazhen
- Attachments
-
- lattice.tar.gz
- (104.37 MiB) Downloaded 19 times
Re: calculation of parasitic loss by resistive wall
Hello Tang-
First, I used your files to make the following plots of the longitudinal phase space before and after your beamline. The plot in elegant's output variable of (t,p/mc) looks like Then I converted to z = -vt and (p - p_0)/mc by subtracting by p_0 (which is included as a parameter in the data file), which looks like Note that this is slightly different then the \gamma that you assume, since \gamma = sqrt((p/mc)^2 + 1). I believe that is part of the "DC" discrepancy, although part of it may be due to differences in the definition of the mass of the electron in elegant. elegant uses data from some time ago under the belief that it is better to keep the code self-consistent than to make corrections on the 10^{-7} level -- if accelerator physicists are ever relying on that level of precision then I will declare victory. Regardless, quantities that we will compare with theory can be found by, e.g., evaluating \delta \gamma from the p/mc that is output and the p_0 that is supplied as a parameter. So hopefully we understand the described DC difference: by looking at the initial distribution and/or using the reference momentum that elegant provides this difference can be resolved.
One may still have concerns regarding the agreement between the theory and elegant: the simulated points more or less follow theory line, but show significant spread and some additional features at the tails of the distribution. These features are numerical, and come from two related sources. First, the wakefield provided has sharp features at very small length scales, so that it needs to be resolved using a very fine grid that you chose to have dt ~ 3.33 fs. This length scale is much smaller than the rms bunch length ~29 ps, such that even in the center of the Gaussian distribution that has 10^6 macroparticles, there are on average only 46 macroparticles per temporal bin. One could consider increasing the number of particles, but this would be difficult to use for any real application. Rather, I would suggest using the knowledge that the relevant length scales are probably no shorter than \sigma_t/10 to improve numerical robustness and subsequent results. As an example, we could consider convolving the provided wake by a Gaussian of rms width \sigma << 29 ps. The resulting smoothed wake potential is equivalent to what we would get if we applied a Gaussian filter of width 1/\sigma to the impedance, and should predict the correct physics provided it occurs over a time much longer that \sigma. Now we include the elegant results using a wake potential that is the provided resistive wall wake convolved with Gaussian of sigma = 1 ps (the wake itself looks very similar to your analytic formula involving modeified Bessel functions with sigma = 1 ps). Note that to get this to run in elegant requires adding the option ACAUSAL_ALLOWED=1 to the WAKE element. Finally, I would suggest not setting CHANGE_P0=1 (i.e., leave it to its default or set CHANGE_P0=0). Usually, one does not want a wake element to change the reference momentum of a lattice (the one counter-example may be for wakefield accelerators). Note that with either option a WAKE element can change the mean momentum/energy of the beam, and the option only changes what elegant considers to be the reference.
First, I used your files to make the following plots of the longitudinal phase space before and after your beamline. The plot in elegant's output variable of (t,p/mc) looks like Then I converted to z = -vt and (p - p_0)/mc by subtracting by p_0 (which is included as a parameter in the data file), which looks like Note that this is slightly different then the \gamma that you assume, since \gamma = sqrt((p/mc)^2 + 1). I believe that is part of the "DC" discrepancy, although part of it may be due to differences in the definition of the mass of the electron in elegant. elegant uses data from some time ago under the belief that it is better to keep the code self-consistent than to make corrections on the 10^{-7} level -- if accelerator physicists are ever relying on that level of precision then I will declare victory. Regardless, quantities that we will compare with theory can be found by, e.g., evaluating \delta \gamma from the p/mc that is output and the p_0 that is supplied as a parameter. So hopefully we understand the described DC difference: by looking at the initial distribution and/or using the reference momentum that elegant provides this difference can be resolved.
One may still have concerns regarding the agreement between the theory and elegant: the simulated points more or less follow theory line, but show significant spread and some additional features at the tails of the distribution. These features are numerical, and come from two related sources. First, the wakefield provided has sharp features at very small length scales, so that it needs to be resolved using a very fine grid that you chose to have dt ~ 3.33 fs. This length scale is much smaller than the rms bunch length ~29 ps, such that even in the center of the Gaussian distribution that has 10^6 macroparticles, there are on average only 46 macroparticles per temporal bin. One could consider increasing the number of particles, but this would be difficult to use for any real application. Rather, I would suggest using the knowledge that the relevant length scales are probably no shorter than \sigma_t/10 to improve numerical robustness and subsequent results. As an example, we could consider convolving the provided wake by a Gaussian of rms width \sigma << 29 ps. The resulting smoothed wake potential is equivalent to what we would get if we applied a Gaussian filter of width 1/\sigma to the impedance, and should predict the correct physics provided it occurs over a time much longer that \sigma. Now we include the elegant results using a wake potential that is the provided resistive wall wake convolved with Gaussian of sigma = 1 ps (the wake itself looks very similar to your analytic formula involving modeified Bessel functions with sigma = 1 ps). Note that to get this to run in elegant requires adding the option ACAUSAL_ALLOWED=1 to the WAKE element. Finally, I would suggest not setting CHANGE_P0=1 (i.e., leave it to its default or set CHANGE_P0=0). Usually, one does not want a wake element to change the reference momentum of a lattice (the one counter-example may be for wakefield accelerators). Note that with either option a WAKE element can change the mean momentum/energy of the beam, and the option only changes what elegant considers to be the reference.
Re: calculation of parasitic loss by resistive wall
I tried to attach the smoothed wakefield that I used above, but encountered difficulties. Here it is if you are interested.
- Attachments
-
- convWake1ps.sdds
- (79.11 KiB) Downloaded 8 times
-
- Posts: 2
- Joined: 06 Oct 2025, 11:06
Re: calculation of parasitic loss by resistive wall
Hi Ryan,
Thank you so much for your kind help; it has been extremely useful to me. Indeed, I didn’t realize the difference between the data in Elegant and the latest current data, and this issue has been bothering me for a long time. Additionally, your ideas on low-frequency filtering have given me great inspiration and really helped me gain a lot. Finally, I also want to thank you very much for your explanation of the "CHANGE_P0" parameter—otherwise, this would have bothered me for a long time later on.
In short, thank you so much again for your kind help, and wish you a wonderful day.
Tang Jiazhen
Thank you so much for your kind help; it has been extremely useful to me. Indeed, I didn’t realize the difference between the data in Elegant and the latest current data, and this issue has been bothering me for a long time. Additionally, your ideas on low-frequency filtering have given me great inspiration and really helped me gain a lot. Finally, I also want to thank you very much for your explanation of the "CHANGE_P0" parameter—otherwise, this would have bothered me for a long time later on.
In short, thank you so much again for your kind help, and wish you a wonderful day.
Tang Jiazhen