Primal-dual evolution event handler recipe #916
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #916 +/- ##
==========================================
+ Coverage 52.29% 53.99% +1.70%
==========================================
Files 20 21 +1
Lines 3991 4380 +389
==========================================
+ Hits 2087 2365 +278
- Misses 1904 2015 +111 ☔ View full report in Codecov by Sentry. |
| from pyscipopt import Model, Eventhdlr, SCIP_EVENTTYPE, Eventhdlr | ||
|
|
||
| def get_primal_dual_evolution(model: Model): | ||
|
|
There was a problem hiding this comment.
I think we need a good docstring here. Describing most importantly where the data is saved and how one would read it
There was a problem hiding this comment.
What do you think of this, Mo?
Attaches an event handler to a given SCIP model that collects primal and dual solutions,
along with the solving time when they were found.
The data is saved in model.data["primal_log"] and model.data["dual_log"]. They consist of
a list of tuples, each tuple containing the solving time and the corresponding solution.
A usage example can be found in examples/finished/plot_primal_dual_evolution.py. The
example takes the information provided by this recipe and uses it to plot the evolution
of the dual and primal bounds over time.
you can capture the final state using the
I think in recipes is ok but without the plotting and with good documentation :) and thanks a lot João! |
Co-authored-by: Mohammed Ghannam <[email protected]>
Co-authored-by: Mohammed Ghannam <[email protected]>
|
Thanks for the suggestions, Mo! I ended up copying the gas transportation model for the plotting example because importing stuff with python from different folders is somewhat finicky. I could have added a couple of lines using sys, but I feel like it would potentially complicate things for inexperienced users. Also Mo and @Opt-Mucca, what do you think of creating an issue asking users to give us some of their pyscipopt models so that we can expand on the utils? |
| from pyscipopt.scip import is_memory_freed | ||
|
|
||
|
|
||
| def is_optimized_mode(): |
There was a problem hiding this comment.
Why are we removing this test?
There was a problem hiding this comment.
It annoyed me having this test in utils.py, since at the time the test seemed useless. I only realized after I read your comment that just constructing the model might somehow alter the result of is_memory_free. Still, I would prefer to have this test in a different place.
There was a problem hiding this comment.
All for it being moved if you want, but I don't see if it actually being copied somewhere else.
tests/test_heur.py
Outdated
| @@ -106,7 +106,7 @@ def test_heur(): | |||
| assert round(sol[y]) == 0.0 | |||
|
|
|||
| def test_heur_memory(): | |||
| if is_optimized_mode(): | |||
| if is_memory_freed(): | |||
There was a problem hiding this comment.
These should not be completely equivalent?
|
@Joao-Dionisio I strongly support asking users to contribute models! That would be super helpful for our testing. For this MR: I like the recipe and the example's fine (even if it does have a lot of duplicate code). My issue is with the changes in the tests, and I'm a bit curios from the design POV. |
Based on #881, I think it's helpful to include the answer as a recipe.
It's a bit scuffed, I think one needs to capture the final state of the problem, as the event handler is not called when the solving stops.
I'm also unsure about the best way to separate things, I decided just to include the event handler in the recipe and the user would need to optimize the model themselves, as well as plot the solutions afterward. I'd be happy with better suggestions, though.