Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Solution attr "status" VS solution not found #105
I identified a problem when I imposed a time limit to Rsymphony with add_cuts_portfolio: when none solution was found when the time limit was reached, I got in my solution list:
So I looked at the solving display and identified the “solutions not found” to exclude them manually from my selection frequencies. But this can be a bit tedious work if you have, let’s say, 50 scenarios with 100 solutions for each.
Thanks for reaching out. I've tried to respond to each of your points/questions below, but please let me know if I've missed anything.
Yeah, the current portfolio methods tend to produce very similar solutions, and so you need a lot of solutions to compute "meaningful" selection frequencies. That said, in my opinion, selection frequencies don't provide much useful information. They don't tell you which planning units are more or less irreplaceable (since they don't include cost data, instead replacement cost values would be more useful, see
Yeah, the status codes are different between Gurobi and SYMPHONY. I refer to the ROI.plugin.symphony R package for descriptions of the SYMPHONY status codes (i.e. https://github.com/cran/ROI.plugin.symphony/blob/master/R/plugin.R#L79-L193). I'm sure there's an official write-up somewhere, but I haven't found it yet (so please let me know if you do find it).
Yeah, planning unit values should only be zero or one when you've specified binary decisions (the default), so getting a value of 658 is a bug. Could you please share a reproducible example, either with your data or the example data, that results in this bug?
I would (generally) recommend setting the gap instead of a maximum time limit. For reproducibility (e.g. if you run the same code on a better system, you might get different results when using time limits) and quality assurance (e.g. knowing how good the solutions are without removing highly suboptimal solutions afterwards), I think it's better to set a minimum level of performance rather then a maximum run time. If you only need solutions that are within a certain threshold of optimality (e.g. with the SYMHPONY solvers, a gap of 50 means that solution(s) need to be within 50 cost units of the optimal solution), then I would recommend setting the gap accordingly. If you set a higher gap, then this will generally reduce the run time considerably (e.g. see Figure 1 in https://doi.org/10.1016/S0006-3207(02)00042-3).
In terms of filtering out solutions using status codes, would something like this work?
Also, if there's any way that you can get access to Gurobi, I'd strongly recommend it. It's much, much faster and the pool search portfolio methods also return multiple solutions in a much shorter period of time.
Thank you Jeffrey for your really quick and useful answer,
It actually stores a “fake” solution (with sometimes weird values) and its status code is “228”. So I recommend, as you said, to advise prioritizr users to use only the "231" solutions to be sure.
I'm just about to upload a patch which will mean that prioritizr throws an error instead of returning invalid solutions from Rsymphony which should address this issue, so I'll close this issue in a minute or so. If you have any further questions, or if you find that the new version doesn't fix this problem, please feel free to reopen this issue.