-
Notifications
You must be signed in to change notification settings - Fork 47
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
Ensemble viz #565
Ensemble viz #565
Conversation
…have an easier was to save ensemble predictions later one
Codecov Report
@@ Coverage Diff @@
## develop #565 +/- ##
============================================
- Coverage 89.81% 34.27% -55.54%
============================================
Files 75 79 +4
Lines 4878 5117 +239
============================================
- Hits 4381 1754 -2627
- Misses 497 3363 +2866
Continue to review full report at Codecov.
|
Shall I just also add an engine and create a task to be executed for predictions? I just found out that multi-processing within the amici objective doesn't work without an engine... |
What is "ICB objective"? If you want to multi-process the execution, a first thing would be to check whether you can formalize this as an "EnsembleTask" derived from https://github.com/ICB-DCM/pyPESTO/blob/master/pypesto/engine/task.py, similar to for optimization and profiling. If that does not work (e.g. because you need more dynamic scheduling or interprocess communication), one would need to write the full Engine anew. |
amici objecive... Too much distraction due to icb (com health) orga retreat... 😂 |
Nice! ICB objective is a classical example of failed multitasking 😆 |
No objections to anything from my side ;) |
No super big rush there... Just found out that mutlithreading within AmiciObjective also works well for the AmiciPredictor... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will review the rest in a little bit, sorry for delays
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There are no tests that assert that the new methods work as intended, only tests that ensure that errors are not produced during a standard workflow.
f.create_group(base + f'{LOWER_BOUND}s') | ||
for i_cond, lower_bounds in enumerate(ensemble_prediction.lower_bound): | ||
condition_id = \ | ||
ensemble_prediction.prediction_results[0].condition_ids[i_cond] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If ensemble_prediction.prediction_results[i].condition_ids
is equal for all i
then maybe the condition_ids
could be stored independently of ensemble_prediction.prediction_results
to avoid duplication, e.g. ensemble_prediction.condition_ids
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In principle yes, but we store a multitude of PredictionResults here. As PredictionResult also must work as a class of its own, it makes sense to also store the conditionIds in there. One could now either reduce what's stored, therefore introduce a new class... or storing something redundant... What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the purposes of e.g. plotting by condition or observable, it would be nice to automatically ensure that all PredictionResults
share the same condition IDs, and the prediction for the same condition between different PredictionResults
contains the same observable IDs. And also to provide methods to easily get all data by condition or observable, from an EnsemblePrediction
. Maybe a wrapper for SampleEnsemblePrediction
? Anyway, I can do this, let me know what you think
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would actually suggest to open 3 issues:
- wishes and stuff we can use the ensemble functionality for (e.g., what you just wrote)
- wishes and stuff we can use the prediction functionality for (e.g., prediction profiles)
- wishes and stuff we can use the dimesnion reduction functionality for (e.g., analyzing optimization runs from a multi-start visually)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But yes: Asserting these things are equal would be good. Currently, they must be equal, just by the way the predict functions creates things...
Co-authored-by: Dilan Pathirana <59329744+dilpath@users.noreply.github.com>
Co-authored-by: Dilan Pathirana <59329744+dilpath@users.noreply.github.com>
Co-authored-by: Dilan Pathirana <59329744+dilpath@users.noreply.github.com>
Co-authored-by: Dilan Pathirana <59329744+dilpath@users.noreply.github.com>
Co-authored-by: Dilan Pathirana <59329744+dilpath@users.noreply.github.com>
Co-authored-by: Dilan Pathirana <59329744+dilpath@users.noreply.github.com>
Co-authored-by: Dilan Pathirana <59329744+dilpath@users.noreply.github.com>
Co-authored-by: Dilan Pathirana <59329744+dilpath@users.noreply.github.com>
Co-authored-by: Dilan Pathirana <59329744+dilpath@users.noreply.github.com>
Co-authored-by: Dilan Pathirana <59329744+dilpath@users.noreply.github.com>
Co-authored-by: Dilan Pathirana <59329744+dilpath@users.noreply.github.com>
This PR should complete very most of the ensemble functionality, including nice plotting and some more convenience things, such as storing ensemble_predictions directly to h5 files