Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standardize aperture function API #21

Open
DavidSagan opened this issue Oct 24, 2024 · 7 comments
Open

Standardize aperture function API #21

DavidSagan opened this issue Oct 24, 2024 · 7 comments

Comments

@DavidSagan
Copy link
Member

Generally the different tracking methods will be using the same aperture function(s) so there needs to be a standardized API for this. Something like:

function aperture(ele::Ele, particle_coords::??)

Another issue is in what package the aperture funciton should live. Putting it in BeamTracking.jl would tie the aperture calculation to the element tracking which makes things less flexible.

@mattsignorelli
Copy link
Contributor

What is aperture doing? calculating the dynamic aperture?

@DavidSagan
Copy link
Member Author

DavidSagan commented Oct 24, 2024

No. This is a calculation of whether a particle has hit an aperture. This function will potentially be called for each lattice element during tracking.

@mattsignorelli
Copy link
Contributor

Ah, ok. One idea I have is that for elements that have an aperture specified, the low-level tracking lattice that we produce inserts an aperture element after said elements and checks the particle coordinates. This is the simplest and most elegant way in my opinion, however this would of course not work in the case when an aperture is reached internally before finishing traversal of the element.

@DavidSagan
Copy link
Member Author

The case where there are apertures that are not at an element end are a special case which I don't think we need to worry about just now.

@mattsignorelli
Copy link
Contributor

Then I think, just as all misalignments would be patches at the lower-level, all apertures would be aperture elements placed after each element at the low-level. Then when you have a Vector{LowLevelEle} it is handled automatically by the MD

@DavidSagan
Copy link
Member Author

Yes this sounds reasonable but an API is still needed.

@DavidSagan
Copy link
Member Author

Note: An element will have a misalignment_moves_aperture bool that with determine the relative order of the patches with respect to the aperture checking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants