-
Notifications
You must be signed in to change notification settings - Fork 59
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
Handle process externally in ModelicaSystem.simulate and ModelicaSystem.linearized #230
Comments
@kiroorooki The suggestion looks fine, can you update your OMPython to the latest master and make a PR with your changes |
I guess we could also add some facility to OMPython similar to what we have for Library Testing in parallel. Basically we first build the model, then run it in parallel with the Python Parallel jobs feature. |
The only problem with the suggestion might be conflicting generated files and result file names. If those are different for each parallel simulate command then it should work fine. |
ModelicaSystem() creates a separate working directory for each session, so there should not be a problem in conflicting files with same names. We can use python's |
This would be very interesting, e.g., to run massively parallel black-box optimization on the cloud. |
Hello!
I've noticed that we could run simulations in parallel if we handled the process outside the simulate() method.
It is useful to me because I need to run a log of simulations, and running them in parallel saves me a lot of time.
In order to keep the same functionality, I added a boolean handleProcessOutside, and if set to true, I don't wait() and terminate() the process, I simply return it, so the user can handle the process themselves. That way people can use the library the same way, or get extended functionality if needed with just a boolean.
In my case, I run all my simulations, and I make sure all of them are done later when I save my results (opening .mat file, converting things to csv...).
I just realized the library changed quite a bit, but I believe the same functionality can still be implemented in _run_cmd and propagated to the methods using it (simulate and linearized).
Thanks for your hard work, I hope my suggestion makes sense!
This is how I currently implemented it in my version for reference (quite outdated):
`
`
The text was updated successfully, but these errors were encountered: