Implementing LOA and its infinite version.#137
Conversation
…_M_objective and raw_M in InfGDP
Updated InfiniteOpt version from 0.6.2 to 0.6.3.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #137 +/- ##
==========================================
+ Coverage 99.51% 99.60% +0.09%
==========================================
Files 17 18 +1
Lines 2061 2560 +499
==========================================
+ Hits 2051 2550 +499
Misses 10 10 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
@pulsipher good for review. |
pulsipher
left a comment
There was a problem hiding this comment.
This took a lot of work. My main concern is that LOA is not really a reformulation method and we are trying to force it through the reformulation API, which has some gotchas. I suspect we will need a different workflow like how Pyomo.gdp does for methods like LOA.
| new{T}(ϵ) | ||
| # Internal: LOA installs a Dict here to collect the disaggregation | ||
| # map during reformulation; `nothing` for every other use. | ||
| disaggregation_map::Union{Nothing, AbstractDict} |
There was a problem hiding this comment.
This seems like something to avoid, is it not possible to only store it in `_Hull'?
| _set_solution_method(model, method) | ||
| _set_ready_to_optimize(model, true) |
There was a problem hiding this comment.
The problem I see with this workflow is that instead of reformulating, this actually just solves the problem as a solver. What happens if the user then calls optimize! afterward?
Implements LOA with two main components.
For the infinite implementation, the flow is as follows.
Starting from Infinite GDP,