Setting more solver parameters e.g. CPLEX

[TimChippingtonDerrick]

Hi

I have been using OSI on a few projects, mostly with CBC, but a few needing CPLEX. I don't see any way of setting parameter values for CPLEX other than a very few that are specified in e.g. OsiCpxSolverInterface.
I have been adding my own support for some more parameters by extending the set that is covered in the current interface, e.g. node and time limits and relative mip gap tolerance for solving MIPs. Is this the right way to go, or am I missing something in how I am reading and using OSI?
FWIW, I now mainly use OSI through the Sonnet library from C# code, but have been using CPLEX for abut 25 years, mostly through the Concert API from C++ and C#.

Tim

[jhmgoossens]

Tim, You could either

1. Extend the OsiDblParam enum to include something like OsiTimeLimit (in seconds). The problem with extending the enum is that this should then be implemented for all existing Osi implementations, or at least a "throw NotImplementedException".
2. Add get/set in OsiCpx, similar to OsiSpx with setTimeLimit(double) and getTimeLimit().
3. Expose the underlying (CPX) solver instance. This, however, means that the caller has to know how to interact with it, and makes it difficult also to use from .NET or other higher levels.

I would say a Pull Request for 2. seems easiest.

Thoughts? anybody?
Jan-Willem

[TimChippingtonDerrick]

Actually, the approach I have taken so far is more like 1 as per Jan-Willem's list. I think it makes sense for the parameters that are likely to be common across all or most solvers.

I am very willing to look at other options if there is a better approach

Tim

[tkralphs]

There has been a lot of discussion around this over the years. It can be tricky to support parameters across all solvers. The set of parameters that exist and behave roughly the same way in all solvers is not very big, though it is probably bigger than what we currently have. I believe the OS project made a deeper attempt at this and there was some effort to port some of that over to Osi. I'm not sure where that stands. If you want to make a serious attempt, there are a number of people around who would probably be willing to give you advice.

I would suggest first compiling a list of parameters of interest and then we could brainstorm issues that any of us see with implementing them.

[TimChippingtonDerrick]

So far I have on my list some pretty uncontroversial things:

OsiIntParam.OsiNodeLimit
OsiDblParam.OsiTimeLimit
OsiDblParam.OsiTickLimit
OsiDblParam.OsiRelativeMipGap
OsiIntParam.OsiClockType
OsiIntParam.OsiParallelMode

I guess the ones that might be a bit controversial there are the 'tick' limit (for e.g. CPLEX's deterministic time limit), the clock type (wall-clock vs CPU time) and parallel mode (deterministic vs opportunistic). With that small numberof parameters it would be reasonably easy to implement something sensible for most all the solvers, even if it doesn't actually change anything for some of them. Maybe give some warning where a parameter doesn't mean anything useful for any particular solver that is being used? I don't want to make anything that is too tied to any single specific solver.

Exposing access to the underlying solver itself to give access to other features is a whole different question - how would we go about that e.g. for allowing callbacks? It's probaby outside the remit for OSI.

Tim

[tkralphs]

I think all the interfaces provide a way to get a pointer directly in to the solver, so there is nothing to do to enable that possibility, it's just that you want to avoid doing very many solver-specific things if your goal is achieve portability. The more solver-specific things you have, the harder it is to add new solvers. For example, if you look at the code here, we are using OSI, but dropping down into the direct CPLEX interface for setting a range of parameters before going back to OSI to make the actual solve call. It's not ideal, but there are a lot of parameters you end up wanting to play with.

The parameters you have listed are relatively uncontroversial, but all of them will be handled slightly differently by different solvers and it is difficult to make a well-defined promise to the user about what the behavior will be with almost any of them. One could argue that this is OK and that as long as the behavior is documented per solver, it is "user beware," but this is where we've usually punted in the past.

Just some quick comments.

• OsiIntParam.OsiNodeLimit: I suppose all solvers have some such limit, but the number of nodes enumerated is not always well-defined. Some solvers can partially process nodes, then put them back in the queue, some may count nodes that are found infeasible and pruned during strong branching, while others don't, etc. The details probably don't matter in most use cases, but you can't really compare node counts across solvers too easily.
• OsiDblParam.OsiTimeLimit: This should be OK, but it's not clear whether all solvers support time limits in both CPU or wall time and this could be different on different platforms. CPU time limits would generally not be supported on Windows, for example. I would imagine that a wall time limit is always available and pretty well-defined, but not all solvers can stop exactly on the time limit. Cbc, for example, can't be interrupted in the middle of a call to the LP solver and this can mean it overshoots substantially in some cases, if I'm not mistaken. As long as the user is willing to live with this and only needs wall time, it should be OK.
• OsiDblParam.OsiTickLimit: I guess few solvers support this. Cbc does not, as far as I know, but it should be fine to report a warning if it's not supported.
• OsiDblParam.OsiRelativeMipGap: The gap is calculated differently by different solvers, so this one is tricky. It could be implemented, but it may behave differently on different solvers.
• OsiIntParam.OsiClockType: I don't know if all solvers support this, could be OK, but I guess there are platform issues. I'm not sure, but I could imagine some solvers using a "parallel wall time" on Windows, meaning that if you run for 10 seconds wall time on 4 cores, it's counted as 40 seconds.
• OsiIntParam.OsiParallelMode: I guess most (but certainly not all) solvers support multiple parallel modes and this is one that could be ignored if the mode doesn't exist.