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

Proper closing of MAD-X Instances #92

Open
JoschD opened this issue Jul 9, 2021 · 2 comments
Open

Proper closing of MAD-X Instances #92

JoschD opened this issue Jul 9, 2021 · 2 comments

Comments

@JoschD
Copy link

JoschD commented Jul 9, 2021

Hey, I just stumbled upon this behaviour, that the madx instance still accepts commands even after it was closed.
Is this a known "bug"?

Code example:

from cpymad.madx import Madx
madx =  Madx()
madx.input("quit;")
madx.print(text="Still Printing")

with madx.exit() and madx.quit() everything is nicely ended (from the python side),
but a quit, exit, stop in the madx-code or madx.stop() only stops the madx run but still accepts commands.

This can be very annoying when quit is called within a file or macro, the cpymad run continues and runs fine (even reading and setting variables) , sporadically one can find messages like this in the output:

+++ memory access outside program range, fatal +++

but the program still continues to run until you do something fancy,
like a twiss, which fails then with a very non-distinct error message:

++++++ Error: seterrorflag : Errorcode: 1   Reported from pro_twiss:
++++++ Error: seterrorflag : Description: TWISS failed

Not sure if it would make sense to check in the output for:

++++++++++++++++++++++++++++++++++++++++++++
+          MAD-X finished normally         +
++++++++++++++++++++++++++++++++++++++++++++

I understand that this is probably not easy to fix, but maybe it should be included into the known issues.

@JoschD JoschD changed the title Closing MAD-X Instances Proper closing of MAD-X Instances Jul 9, 2021
@coldfix
Copy link
Member

coldfix commented Jul 10, 2021

Hey,

yeah, I'd probably consider this a user mistake. But you're right, I think adding it to known issues is definitely worth, and we can see later if we want to do anything else about it.

@coldfix
Copy link
Member

coldfix commented Jul 10, 2021

In principle, we could check for the variables final_message or stop_flag before each command and then raise an Exception if they contain a 1.

automatic restarting would probably be a bad idea (makes it harder for user to find the cause the problem), and automatic cleanup of the MAD-X process + python process by checking the stop condition after each command might also be unexpected (you can probably still retrieve some data from MAD-X, even after a quit was executed, and that might be an important use case for some users)

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