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

Use multiple cores #178

Open
Yuri05 opened this issue Jan 10, 2019 · 5 comments
Open

Use multiple cores #178

Yuri05 opened this issue Jan 10, 2019 · 5 comments

Comments

@Yuri05
Copy link
Member

Yuri05 commented Jan 10, 2019

Use multiple CPU cores for simulation and comparison
(maybe also possible for report creation?)

@msevestre
Copy link
Member

  • Comparison is almost instantaneous
  • Report Creation: No. The creation of the tex code is also instantaneous. Compiling with miktex takes forever.
  • Run simulation in //. Theoretically possible. We tried however and it did not work as expected. We had some issues with SimModel instantiated more than once (in population or PI calculation, we only have one instance that we use)

We could try to reproduce the issue with SimModel but this might not be worth our time

@Yuri05
Copy link
Member Author

Yuri05 commented Jan 10, 2019

We had some issues with SimModel instantiated more than once

Do you have a reproducible example for this?

in population or PI calculation, we only have one instance that we use

I cannot follow. One SimModel Instance can run only sequentially, not parallel.

For my understanding, e.g. in a PI: N SimModel instances are created, 1 per simulation:
https://github.com/Open-Systems-Pharmacology/OSPSuite.Core/blob/5c9987e8354888ce588c65a88dc6863830679a7b/src/OSPSuite.Core/Domain/Services/ParameterIdentifications/ParameterIdentificationRun.cs#L105-L107

@msevestre
Copy link
Member

No no example. This was a long time ago and not worth investigating. Some issues with xml that could not be parsed when instantiating more than once. Again, because the batch tool was used internally only at the time, no big deal. It was also not based on snapshot and the PI stuff was not implemented. Maybe the issue is fixed

However the problem with // computing would be that the log info would be completely nonsensical. Right now it is sequential. I am not sure how anyone could understand a NON sequential log file..or what needs to be done to support sthg like that

@msevestre msevestre added this to the Version 7.5.0 milestone Jan 10, 2019
@msevestre
Copy link
Member

@Yuri05 Do you want to look at that for 7.5.0?

@Yuri05
Copy link
Member Author

Yuri05 commented Jan 11, 2019

yes

@msevestre msevestre modified the milestones: Version 8.0, Version 9.0 Jun 18, 2019
@msevestre msevestre removed this from the Version 9.0 milestone Nov 20, 2019
@Yuri05 Yuri05 removed the type: task label Feb 11, 2025
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