Closed Joao-Dionisio closed 2 weeks ago
Attention: Patch coverage is 0%
with 35 lines
in your changes missing coverage. Please review.
Project coverage is 53.99%. Comparing base (
23e00b3
) to head (53627d2
). Report is 81 commits behind head on master.
Files with missing lines | Patch % | Lines |
---|---|---|
src/pyscipopt/recipes/primal_dual_evolution.py | 0.00% | 35 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
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.
you can capture the final state using the exitsol
callback.
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.
I think in recipes is ok but without the plotting and with good documentation :)
and thanks a lot João!
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?
@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.