Criterion for lost or unstable particles

[ilkyoung.shin]

Hello,

What is the ELEGANT's criterion for "lost particle" or "unstable motion" in calculations of Dynamic Aperture. How the program determine that the particle is "lost" or the motion is "unstable" after tracking? I just want to know the algorithm identify "lost particle" or "unstable motion".
I tried to find the definition of "lost" or "unstable" particles in many books, but I could not. No book explains that clearly. I think this forum is a good place to ask.
Thank you.

Ilkyoung

[michael_borland]

Ilkyoung,

Elegant doesn't classify particles as "unstable." It only knows whether they are lost or not.

In the context of ring simulations, a particle can be lost in several ways. First, it may exceed an aperture, as defined by ECOL, RCOL, MAXAMP, or SCRAPER elements, or using the aperture_data command. In addition, there are limits on the maximum position and slope, of 10 m and 1 rad, respectively; if a particle exceeds these, it is considered lost.

--Michael

[ilkyoung.shin]

I really appreciate your time and kind answer. I have two more questions.

1. There are several modes to generate initial particles like "many-particle", "single-particle","one-line", and so on. Only positions X and Y are varied. How about momentum? Are the momenta Px, Py zeroes for initial particles? Do we launch zero momentum particles for tracking to evaluate the dynamic aperture?

2. Where does ELEGANT evaluate the conditions of lost particles in beamline? Does the program judge lost particles at one specific position or every beamline element in a beamline?

Thank you so much.

Ilkyoung

[michael_borland]

Ilkyoung,

In answer to your questions:

1. For dynamic apertures, the transverse momenta (px and py) are always 0. This is the standard assumption of dynamic aperture determination. In reality it is a simplification because the injected beam has a spread in transverse momenta.

2. If you use a specific local aperture element, like ECOL, RCOL, or SCRAPER, then elegant checks for lost particles only at the locations of those elements. If you use MAXAMP, elegant checks at the exit of all downstream elements. If you use the aperture_data command to define the aperture, then elegant checks at the exit of all elements (assuming you define the aperture in the region of the element in question), but also at interior points for KQUAD and KSEXT elements.

--Michael

[SDastan]

Hello all,
I have some difficulties in DA tracking. I consider field harmonic error for quadrupole and dipole in my lattice, when I put tracking-mode in "many-particle" the DA has area but when I change the mode to "n-lines" DA becomes zero. Could it possible?
Thanks for your help,
Sara

[michael_borland]

Sara,

That's an odd result and shouldn't happen. Can you share the settings you used for both modes?

--Michael

[SDastan]

Sara,

That's an odd result and shouldn't happen. Can you share the settings you used for both modes?

--Michael

Dear Michael,
I have attached the lattice and results.
Thanks for your help.

Sara

[michael_borland]

Sara,

After a few adjustments of the settings, I get similar results for both methods. In addition to changing parameters of the &find_aperture command, I changed the values for N_KICKS on your CSBEND and KQUAD elements, since they seemed very low.

I compared both methods to a third method, namely, tracking a "dynamic-aperture" beam generated by the &bunched_beam command. This is much more time-intensive but provides a gold standard for checking the others. I strongly recommend using the n-lines method over the others. For one thing, it will use parallel resources if you use Pelegant instead of elegant.

--Michael

[SDastan]

Dear Michael,

I search a lot about the mis-matching in DA with bunched-beam method and two other methods when I put initial real value of lattice. The initial value of ESR ring is
emit_x = 2.014e-07
beta_x = 12.83
emit_y = 2.014e-08,
beta_y = 13.37
when I put these parameters in the bunched-beam method it doesn't match with other methods. I see these post and I understand that when we don't define charge, It means that we don't consider CSR. In addition by increasing and decreasing emittance we can zoom in or out for DA. Am I understand correct?
https://www3.aps.anl.gov/forums/elegant ... h+beam#p21
https://www3.aps.anl.gov/forums/elegant ... beam#p1203
If I am correct then the initial value for emittance and beta function shouldn't matched with real value, is it correct? But how we can put these values that you put in example which you sent for me?

Regards,
Sara

Sara,

After a few adjustments of the settings, I get similar results for both methods. In addition to changing parameters of the &find_aperture command, I changed the values for N_KICKS on your CSBEND and KQUAD elements, since they seemed very low.

I compared both methods to a third method, namely, tracking a "dynamic-aperture" beam generated by the &bunched_beam command. This is much more time-intensive but provides a gold standard for checking the others. I strongly recommend using the n-lines method over the others. For one thing, it will use parallel resources if you use Pelegant instead of elegant.

dynapComparison.png

--Michael