Summary
We need more consistent handling of solver configs.
Rationale
The challenge: there are many options that should be common to several, but not all, solvers. For example, warm_start_discrete_vars is an option in the BranchAndBoundConfig. Another example would be initializing nonlinear programming solvers (see #3833). How can we get consistent naming across solvers but also indicate what users should expect to work across multiple solvers?
Description
A few things that have been discussed:
- Use hierarchical configs. An example might be
solver.config.branch_and_bound.warm_start_discrete_vars or solver.config.ipopt.foo for something specific to Ipopt. We could maybe also use aliases to shorten these?
- One thing we have already done, which may not be a great idea, is to create more classes. For example, we have both a
SolverConfig and a BranchAndBoundConfig which inherits from SolverConfig.
- We could just put things in the names. For example,
solver.config.knitro_use_start.
Did I miss anything from the discussion yesterday, @jsiirola, @blnicho, @mrmundt?
Additional information
None
Summary
We need more consistent handling of solver configs.
Rationale
The challenge: there are many options that should be common to several, but not all, solvers. For example,
warm_start_discrete_varsis an option in theBranchAndBoundConfig. Another example would be initializing nonlinear programming solvers (see #3833). How can we get consistent naming across solvers but also indicate what users should expect to work across multiple solvers?Description
A few things that have been discussed:
solver.config.branch_and_bound.warm_start_discrete_varsorsolver.config.ipopt.foofor something specific to Ipopt. We could maybe also use aliases to shorten these?SolverConfigand aBranchAndBoundConfigwhich inherits fromSolverConfig.solver.config.knitro_use_start.Did I miss anything from the discussion yesterday, @jsiirola, @blnicho, @mrmundt?
Additional information
None