Added Elegant-like pass methods for several elements

[IharLobach]

This PR adds five pass methods intended to reproduce the behavior of selected Elegant element models:

• ElegantCsbendPass
• ElegantDriftPass
• ElegantEkickerPass
• ElegantKquadPass
• ElegantKsextPass

It also adds Python tests covering the new methods.

The implementations are independent AT integrators inspired by the corresponding Elegant element behavior. Source-level provenance/license notes are included in the new integrator files where appropriate.

Additional notes:

• The KQUAD pass method includes fringe-field treatment following the corresponding Elegant model. The Elegant-style fringe-field treatment for CSBEND elements is also included.
• Higher-order multipole treatment is included for the added CSBEND, KQUAD, and KSEXT pass methods.
• With these added pass methods, I was able to obtain PyAT/Elegant agreement to machine precision in test lattices where I could not achieve the same agreement with the existing PyAT pass methods.
• The motivation for this work came from observing a sizable vertical chromaticity disagreement between PyAT and Elegant for the Beam Accumulator Ring for the Electron-Ion Collider, a small accumulator-ring lattice with large dipole bend angles of 45 degrees. In that case, PyAT with the default pass methods returned vertical chromaticity around -2.7, while Elegant returned around -4.0. With the added Elegant-compatible pass methods, the chromaticities agree perfectly.
• I added these five element types because they cover all elements used in the Beam Accumulator Ring lattice. My goal was to obtain agreement to machine precision between PyAT and Elegant everywhere in the ring when tracking a test particle. There is only one redundancy: instead of ElegantDriftPass, it would be possible to use AT's ExactDriftPass.
• I asked Michael Borland whether it would be acceptable to make these methods public in this form. He said that this is acceptable as long as Elegant's license is properly mentioned. I have therefore included Elegant provenance/license comments directly in the new C source files for these pass methods.

I would like to make these methods publicly available directly through the AT GitHub repository, since several colleagues at BNL are already interested in using them. Having them available through the official AT repository would make it much easier to share and maintain them than relying on my github fork.

Thank you for considering this contribution.

[lfarv]

Hello @IharLobach, thanks for this contribution.
This looks safe since it does not change any existing part. But I have a few questions concerning the integration in AT, since we have at the same time a significant refactoring of magnet integrators in the "magnet_integrators" branch.

for ElegantKquadPass:

You are using the codes 0, 1 2 and 3 for fringe field. Codes 0, 1 and 2 are equivalent to what is done for existing AT multipoles. Code 3 may conflict with the upcoming multipole fringe expansion using Forest's formulae currently implemented in the "magnet_integrators" branch. If you keep 3, we can switch to 4.
You are proposing a flag to select the integration order, while for efficiency we are using in the new branch different passmethods (see here).

for ElegantDriftPass:

As you wrote, it is strictly equivalent to ExactDriftPass. I may be puzzling for users to offer two different passmethods.

For all methods:

There is a problem with error handling in python. The check_error() function must be used at the top level of the Python extension: it triggers a premature return of the top-level function, returning NULL with the python error code positioned. This will not work when used in a sub-function like initialize_elem(). In any case, the element structure should be allocated only if there is no error the avoid a memory leak.

Otherwise, this looks very interesting. I'll be away for a moment, let's wait for other comments!

[IharLobach]

Hello @lfarv
I wanted to follow up and ask whether you have received any additional input on this contribution.

I would be happy to address the concerns you raised, including the fringe-field code and integration-order interface for ElegantKquadPass, the redundancy of ElegantDriftPass, and the Python error handling and allocation issues. Would you prefer that I update this pull request accordingly, or prepare a new adjusted pull request?

Thank you!

[swhite2401]

@IharLobach thanks for this contribution!
Just as a side note @lfarv is going through a refurbishment of the C integrators right now (see #1083 ).
Would it make sense to match the new architecture instead? And potentially take the occasion to integrate the new features as much as possible into existing passmethods?
This could possibly address redundancy issues.