convert madx class to module
coldfix opened this issue · comments
Objects of type cern.madx.madx within a single process scope are not independent. Because of the global design of the MAD-X library, calls on any of these objects will have side effects on every other madx object in the same process scope.
I would rather have this more explicit (it already fooled me more than once) by removing the class and making all of its functions module level.
This would also make the usage more natural
Instead of:
from cern.madx import madx
m = madx(histfile, recursive_history=True)
m.command(...)Rather:
from cern import madx
madx.set_history_file(histfile, recursive=True) # optional
madx.command(...)For cern.cpymad.model this would imply to import the module like so:
class _modelProcess(...):
def run(self):
from cern import madx
...rather than importing it on global scope.
Hmm, maybe you are right, but I would ideally like that Mad-X would be able to close correctly so that you could do stuff like:
m=madx()
m.command(..)
...
del m
m=madx() # clean new mad-x instance
That's the reasoning behind the current structure. I agree that since Mad-X is a beast as far as memory management goes, this is perhaps more confusing than anything. But in the altrnative suggestion from you, where would the initialization of Mad-X go? If it is during import, I am concerned that this would not anymore be allowed:
from cern import madx
from cern import cpymad
lhc=cpymad.model('lhc')
madx.command(..) # does not interfere with the lhc instance
Maybe it is not useful, but I need to think a bit longer about it.
About your first point: deleting a madx instance does not reset the library state in the current implementation. It only resets the history file. So I think, this is even more confusing. To explicitly control the library state, I would suggest module level functions start, finish, reset or similar.
Yes initializing madx at import time will probably be the easiest thing to do. Another possibility is to wait for the first library call.
The second code example will be possible without any interference: cern.cpymad.model does not even import cern.madx (it is imported only in the peer subprocess).
Humm, not sure if I see the complete scope of this. Need to think some more. Feel free to make a branch with the proposed change if it is not too much work.
I have had some more thought about this. It is probably cleaner to leave the madx functionality as a class.
BUT: In this case all madx instances should work independently, meaning that the multiprocessing logic should be moved from cern.cpymad.model to cern.madx.
EDIT: If you agree with this suggestion, I can start to implement it. I have some thoughts on improvements with the multiprocessing backend. Furthermore, there are some issues with the usage of the multiprocessing module, that I would like to solve.
When trying to simplify and generalize the interfacing code using proxy objects, I discovered that the usage multiprocessing has some drawbacks, see #43.
Therefore, I have looked into some RPC libraries which can deal with sockets: Pyro4, RPyC.
I have started example implementations which I will upload in the next days.
RPyC has support for SSL connections and other IPC transports than sockets, which makes it especially interesting.
What do you think about using external libraries for this problem?
By the way: Do you know if there are any plans to resign from using globals in MAD-X?
Sorry that I don't have time to answer all your questions, your work is very much appreciated! Just purge me in case some of it is urgent.
For future plans of Mad-X I am not fully up to speed. There are many plans, which are defined in several stages (one is a complete rewrite into Mad-11 I think). I think they are trying to close down all the global stuff to get the code more modular and get the code into a "safer state". I would suggest to contact mad@cern.ch for these questions. You could also have a look at the meeting minutes
External libraries are generally fine by me, if the need is reasonable. My requirement is as always, have to work on current Scientific Linux CERN (which currently has Python 2.6, sorry).