Really not trying to be cheeky... but why? Who is the audience here? I can see maybe academics with small grants and want to do the absolute minimum spend on compute... But that is an audience you will have to fight for every cent.
This doesn't solve or provide guidance for the subtle problems in these otherwise opensource solvers... The first example requires the client to manually disambiguate equivalent variables to get a stable solution... Sure that's a pretty common problem everyone working with optimizers should be familiar with but they're also one of the hardest things to track down in a complex derived model.
I'm not a potential customer for this, but i have worked on a few commercial projects involving combinatorial optimisation.
Misc thoughts:
- I'm not familiar with the LABS problem, but the LABS benchmark page is interesting & compares against Gurobi. I'd be curious to see how an existing commercial non-mip approximate solver such as Hexaly (formerly LocalSolver) compares here.
- the other two benchmarks aren't very convincing as they don't compare against other methods or show running times
- the front page mentions peer reviewed methodology - consider linking to the publications
- good idea to have case studies of applications. I was a bit confused to see this listed under 'References' but on comparison the Gurobi & Hexaly marketing websites also do this (references -> case studies & references -> customer stories, respectively)
- re the client API, you may want to make the server URL have a default, so your trial users / customers don't have to specify it. It may be easier for you to roll out changes to your server URL in future if you can do it by changing the default server URL in a new version of your client library rather than requiring your customers to update their source code.
This may be useful for small demos. For large scale MIP with millions of variables, one needs to have the solver at hand to support custom algos with techniques such as column generation, etc. to achieve time to solution and economics of compute resources. A remote API will not fit.
NEOS will let you run this stuff on cplex/gurobi/etc (IE much faster than the backends behind quicopt), for free, is integrated with pyomo/etc, and has like an 8 hour time limit.
Often, the difference on "harder" problems is 10x or more.
I have problems that gurobi solves in 30 seconds that take 15 minutes or more for ~every non-commercial solver (or-tools, HIGHS, ipopt, etc).
But right now, this wouldn't even be interesting to me to use even if they actually were fronting commercial solvers, because they can't actually run it any faster and having this ".solve" API does nothing - pyomo already does that for me in practice.
This could be interesting, but it badly needs systematic benchmarking results. It is not difficult to get Claude Code or Codex to install and run a solver locally, so the tool’s current value proposition is fairly muddled.
If there were evidence that it offered better performance, I might consider running larger workloads on it.
As I understand it, the value proposition is that it can deal with a spiky stream of problems to solve better than buying a bunch of on-prem hardware and running local solvers on them would -- similar to why it often makes sense to spin up cloud VMs on demand to handle spiky web traffic.
Performance on an individual problem is still interesting of course, but maybe not the main focus.
Sounds similar to Timefold Platform: app.timefold.ai
That's our Solver as a Service for scheduling problems (vehicle routing problem, shift scheduling, job scheduling, etc). It runs scheduling problems implemented with our open source solver: solver.timefold.ai
But this post is such a service for formula problems instead (think master capacity planning, portfolio optimization, etc), due to the choice of MILP solvers underneath. Similar to NextMv, Neos, etc.
For whatever its worth I built this about a decade ago because I am a non academic who can't think in tableaus, but still wanted to solve optimization problems.
I created a json like schema/struct/whatever to describe the problem. Maybe adopt something like this and more people will be able to see how they could use your tool:
15 comments
[ 2.8 ms ] story [ 54.1 ms ] threadThis doesn't solve or provide guidance for the subtle problems in these otherwise opensource solvers... The first example requires the client to manually disambiguate equivalent variables to get a stable solution... Sure that's a pretty common problem everyone working with optimizers should be familiar with but they're also one of the hardest things to track down in a complex derived model.
Misc thoughts:
- I'm not familiar with the LABS problem, but the LABS benchmark page is interesting & compares against Gurobi. I'd be curious to see how an existing commercial non-mip approximate solver such as Hexaly (formerly LocalSolver) compares here.
- the other two benchmarks aren't very convincing as they don't compare against other methods or show running times
- the front page mentions peer reviewed methodology - consider linking to the publications
- good idea to have case studies of applications. I was a bit confused to see this listed under 'References' but on comparison the Gurobi & Hexaly marketing websites also do this (references -> case studies & references -> customer stories, respectively)
- re the client API, you may want to make the server URL have a default, so your trial users / customers don't have to specify it. It may be easier for you to roll out changes to your server URL in future if you can do it by changing the default server URL in a new version of your client library rather than requiring your customers to update their source code.
All the best!
Often, the difference on "harder" problems is 10x or more.
I have problems that gurobi solves in 30 seconds that take 15 minutes or more for ~every non-commercial solver (or-tools, HIGHS, ipopt, etc).
But right now, this wouldn't even be interesting to me to use even if they actually were fronting commercial solvers, because they can't actually run it any faster and having this ".solve" API does nothing - pyomo already does that for me in practice.
https://plato.asu.edu/guide.html
Their website has just 3 cherry picked instances and claim complete dominance.
If there were evidence that it offered better performance, I might consider running larger workloads on it.
Performance on an individual problem is still interesting of course, but maybe not the main focus.
That's our Solver as a Service for scheduling problems (vehicle routing problem, shift scheduling, job scheduling, etc). It runs scheduling problems implemented with our open source solver: solver.timefold.ai
But this post is such a service for formula problems instead (think master capacity planning, portfolio optimization, etc), due to the choice of MILP solvers underneath. Similar to NextMv, Neos, etc.
I created a json like schema/struct/whatever to describe the problem. Maybe adopt something like this and more people will be able to see how they could use your tool:
https://github.com/JWally/jsLPSolver/blob/master/API.md
I need to re go through the docs, but you get the gist.
Here is the Berlin Airlift problem for example:
const model = { optimize: "capacity", opType: "max", constraints: { plane: { max: 44 }, person: { max: 512 }, cost: { max: 300000 }, }, variables: { brit: { capacity: 20000, plane: 1, person: 8, cost: 5000 }, yank: { capacity: 30000, plane: 1, person: 16, cost: 9000 }, }, };