[PEP] Redesign of Pyomo Solvers

[michaelbynum]

I would like to start redesigning the solver interfaces in Pyomo.

Motivation

1. The current solver interfaces are more complex than necessary.
2. The current solver interfaces have many inconsistencies.
3. The current solver interfaces do not allow the solution of a model/block with constraints that use variables which live elsewhere.

Preliminary Design Decisions (to be updated with time)

• When solving a model/block, the model is defined by the set of active components and any components used by those active components. This means that variables are handed to the solver if and only if they are used in an active constraint or objective.

Implementation

• I intend to develop new solver interfaces alongside the existing ones. I do not intend to remove existing solver interfaces. Once the new solver interfaces are sufficiently mature, we can rename/archive the old interfaces.
• I intend to start with a couple simple solver interfaces and get feedback before proceeding further.

Thoughts? Concerns?

Related Issues

• Baron does not work with the Pyro solver manager #7
• MIP solver option - Resolve with fixed integer variables #19
• Incorrect behavior with the relax_integrality solver option  #22
• With cplex, solver_io='python' is much slower than solver_io='nl' or default #51
• Extend log saving to sol and lp saving #175
• Solver output should be logged through the logger instead of stdout/print #296
• Document solvable blocks #312
• Fix confusing semantics of model.solutions.load_from #371
• Implement parsing of GLPK interior-point solution #380
• Solver interface consistency with warmstart=True/False #387
• return final Ipopt values in solution object #548
• Promote ipopt_solver_wrapper to a general utility #728
• Get access to symbol_map of GAMS solver #768
• Persistent solver interfaces do not support non-persistent options #798
• Pyomo test-solvers errors #861
• Improve IPOPT interface to provide solver-consistent error reporting #868
• Retrieve multiple feasible from BARON result file #915
• The cplex solver interface returns a mipgap, but Gurobi's does not #1023
• [PEP] Solving Blocks with variables that do not live on the Block #1032
• [PEP] Checking available() on an unavailable solver should not throw an exception by default #1074
• Better error reporting when solver is killed or cannot be found #1088
• with cplex, solver_io='python' is much slower than executable=(solver_path)  #1169
• BARON Unicode Decode Error #1275
• CPLEX's mip.limits.solutions parameter results in SolutionStatus.error #1333
• References to constraints cause duplicate constraints to go to solvers #1401
• Baron writer error for LinearExpression with fixed variables #1466
• [PEP] Raise exceptions for unknown Solvers, Writers, Transformations #1487
• Unused variables are added to Direct solvers #1490
• Pyomo Gurobi solver parallel problems (indirect) #1567
• SCIP Solver Results undefined/unknown/inf #1615
• Fall back to direct interface if shell is not available #1776 🇺🇸
• Incomplete optimisation data with CPLEX solver #1811
• Temporary .log file seems to be always created in CPLEXDirect solver #1900
• Enable additional features for CBC solver #1926
• Can't solve subblock with gurobi_direct #2130
• Add the relative mipgap reached after optimization in SolverResults object #2167
• cyipopt does not support symbolic_solver_labels or load_solutions=False #2218
• Does APPSI solver support warmstart? #2362
• Add isv_key_support for gurobi #2401
• GAMS solver sets incorrect termination condition on timeout for MIP model solved with CPLEX #2452
• Pyomo solvers could use a consistent "time limit" interface #2484
• Writers and solver interfaces should (could?) ignore trivially satisfied constraints #2485
• Pyomo 6.4 can't use scip 8.0.1 #2545
• CPLEX Solver result termination message type UndefinedData #2564
• Pyomo + GLPK does not return a certificate of optimality for simple LP? #2611
• Multiple solvers are missing a config_block method #2703
• SolverFactory('gams', **kwds) ignores keyword arguments #2757
• tee=True doesn't work with solvers that buffer stdout #2785
• CBC initialSolve option ignored due to cmd line construction #2807
• BUG: stopping the default log of appsi_highs #2845
• Problem when using io_options in solver.solve keyword arguments. #2908
• List index out of range error for GAMS solutions #2955
• cyipopt fails with load_solutions=False #2958
• persistent_solver set_instance fails with variable in deactivated block #3000
• ["scip.exe", "--version"] timed out after 1 second #3064
• SCIPAMPL fails to get primal bound from log file #3107
• SCIPAMPL solver does not assign values to all variables #3110
• Using Windows version of gams from WSL #3147
• Don't pass -stat=1 option to CBC to avoid slowdown #3191

[ghackebeil]

I think you should reduce the scope of this PEP. The third bullet point is an orthogonal and controversial issue. There is no need to have it possibly get in the way the other (much needed) changes.

[jwatsonnm]

Regarding the third bullet Gabe references, can you clarify? Is said variable at least below the current block in the model component hierarchy? If it's not in the hierarchy, then I agree with Gabe that this is highly controversial.

[carldlaird]

I updated the motivation in the pep to have numbers.

It would be good to document the cases where "Bullet 3" is required. I also admit that the first time I heard that we needed to support solves where variables live outside the hierarchy, I thought this was very strange because it breaks encapsulation of sub-models. Having said that, I would like to see a use case where this is required to be convinced one way or another.

[michaelbynum]

@ghackebeil @jwatsonnm I will open a separate PEP for (3).

[michaelbynum]

@ghackebeil @jwatsonnm @carldlaird Let's move the discussion of (3) to #1032.

[DLWoodruff]

Now that the controversy has moved to #1032, I predict that everyone will think the new PEP with only items one and two is non-controversial great idea and that you should proceed with your plan to create a couple of examples.

[jsiirola]

I am adding a performance label to this PEP. I believe that a redesign of the base solver API is a prerequisite before we can (effectively) tackle things like reworking the writers / readers / persistent APIs.

[jsiirola]

Archived on the master Performance Proposals Issue (#1430). Not closing as this is also marked as a PEP.

[alexchandel]

It would be very useful to users to define one or more base protocols or base classes that all solvers inherit from. Many solvers like the BARON shell interface inherit from opt.base.solvers.OptSolver. However, several solver managers including GAMS and AsynchronousActionManager and MindtPySolver do not. This causes problems like #2757, where users expect options= to work and it doesn't.

It would be best to factor out some standard behavior, like supporting the options= keyword to set .options.

Also, for example, all solvers seem to implement a solve method, and many have a license_is_valid method. Defining such methods in an abstract base class or protocol would help users keep track of what solvers can even do.

[mrmundt]

@alexchandel - Agreed. All of those considerations are on our list.

[alexchandel]

I would add to this—because the "results" of a Pyomo solver are part of the solver's API—to standardize at least SOME of the SolverResults structure across all solvers.

In particular, indicate in universal fashion whether the result was a solution, or infeasible/failure. See #2942 for an example where this behavior is inconsistent between solvers, preventing universal client code from being written.

[alexchandel]

I would add an additional motivation for base classes is the recent emergence of powerful Python type checkers like Pylance/Pyright and mypy. Unfortunately some of Pyomo is extremely dynamic, and currently difficult for type checkers to work out (e.g. #2078, #2821, #2938). However, it would be nice for the construction SolverFactory(backend.str()) to be known to return a subclass of a known base class with a .solve() method, and similarly for SolverManagerFactory(backend.str()).

[alexchandel]

Additionally, the Pyomo solver interface needs a common exception for when a Solver is not available. Observe the extremely different behavior when calling solve() on two solvers, neither of which is available:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/alex/test/test.py", line 3370, in start
    main()
…
  File "/Users/alex/test/.venv/lib/python3.11/site-packages/pyomo/solvers/plugins/solvers/GAMS.py", line 766, in solve
    self.available()
  File "/Users/alex/test/.venv/lib/python3.11/site-packages/pyomo/solvers/plugins/solvers/GAMS.py", line 654, in available
    raise NameError(
NameError: No 'gams' command found on system PATH - GAMS shell solver functionality is not available.

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/alex/test/test.py", line 3370, in start
    main()
…
  File "/Users/alex/test/.venv/lib/python3.11/site-packages/pyomo/opt/base/solvers.py", line 533, in solve
    self.available(exception_flag=True)
  File "/Users/alex/test/.venv/lib/python3.11/site-packages/pyomo/opt/solver/shellcmd.py", line 141, in available
    raise ApplicationError(msg % self.name)
pyomo.common.errors.ApplicationError: No executable found for solver 'baron'

[blnicho]

Linking to issue #728. It would be nice if this utility for extracting info from the Ipopt log could be incorporated into the redesigned Ipopt interface.

[mrmundt]

Linking to issue #7

[mrmundt]

To do for Part 2:

• Adjust pyomo.contrib.solver.sol_reader to be an actual parser (e.g., not pass back and forth Results objects)
• Address the idea of shifting solver_options and name to two different values such as interface and algorithm (see Solver Refactor Part 1: Introducing the new solver interface #3137 (comment), Solver Refactor Part 1: Introducing the new solver interface #3137 (comment))
• Explore changing configs to be MixIns rather than inherit from a base class
• Move _VarAndNamedExprCollector to inherit from StreamBasedExpressionVisitor (see Solver Refactor Part 1: Introducing the new solver interface #3137 (comment))
• Explore making Availability its own class rather than a class-level enum (see Solver Refactor Part 1: Introducing the new solver interface #3137 (comment))
• Create a general SubprocessXXX system (see Solver Refactor Part 1: Introducing the new solver interface #3137 (comment))
• (ipopt) Do not make directory if we don't need it (see Solver Refactor Part 1: Introducing the new solver interface #3137 (comment))
• Remove hard-coded constants for time_limit (Solver Refactor Part 1: Introducing the new solver interface #3137 (comment))
• Avoid using TeeStream (see Solver Refactor Part 1: Introducing the new solver interface #3137 (comment))
• Refactor Ipopt.solve into not such a horribly monstrous method (already underway in mrmundt:solver-refactor-pt2)
• Clear up confusion about abstract methods vs. their implementations
• Standardize solver options (see Consistent handling of solver config options #3154 )

[emma58]

I think the second bullet should be two different things:

1. shift name and type to two different values such as interface and algorithm, and
2. Generalize (and perhaps rename?) solver_options to handle case where multiple subsolvers are involved, all of which could have their own options.