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

APERTURE is indefinitely busy when provided apertype is not on the reference orbit #866

Closed
roman-martin opened this issue Dec 17, 2019 · 2 comments

Comments

@roman-martin
Copy link

I am trying to find out if my kicked beam is going through the extraction channel of a septum, hence the off-reference-orbit aperture.

!----EXAMPLE-----------------------------------------------------------------------
mk1: hkicker, hkick:=kmk1;
!---marker with an aperture file with an aperture not on the reference orbit
TDI1: MARKER, apertype="offset_apertype.txt";
//TDI1: MARKER, apertype="offset_apertype_cheat.txt";

testseq: SEQUENCE, l = 20.0;
mk1, at = 5;
TDI1, at=20;
ENDSEQUENCE;

!---the usual stuff
BEAM, PARTICLE=PROTON, ENERGY=7000.0, EXN=2.2e-6, EYN=2.2e-6;
USE, SEQUENCE=testseq;

! turn on kicker
kmk1 = 0.02;

! twiss and aperture calculations
TWISS, BETX=1.0, bety=1.0, file=twiss.out;
APERTURE;
!---/EXAMPLE-----------------------------------------------------------------------

The content of offset_apertype.txt is
0.2 0.1
0.4 0.1
0.4 -0.1
0.2 -0.1

With this setting, the aperture command will just be busy indefinitely, never coming to any result but also never stopping. It is however possible to avoid this problem by introducing a little channel to the reference orbit, e.g in the offset_apertype_cheat.txt with the content
0.2 0.1
0.4 0.1
0.4 -0.1
0.2 -0.1
-0.01 -0.1
-0.01 0.1
0.01 0.1
0.01 -0.99
0.2 -0.99

It is interesting to note that the problem does not occur if the aperture is not too far off-reference-orbit, e.g.
0.1 0.1
0.4 0.1
0.4 -0.1
0.1 -0.1

@tpersson tpersson added the MAD-X label Dec 18, 2019
@tpersson
Copy link
Contributor

Thanks for the report.
I can reproduce your error and I have found where in the code it gets stuck. However, I am still not sure why it get's stuck. I will investigate further during the day and get back with more information.

@roman-martin
Copy link
Author

I just removed my workaround and this issue is still present in MAD-X 5.08.01

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