Setting more solver parameters e.g. CPLEX #150
Replies: 2 comments 3 replies
-
|
Tim, You could either
I would say a Pull Request for 2. seems easiest. Thoughts? anybody? |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
So far I have on my list some pretty uncontroversial things: OsiIntParam.OsiNodeLimit 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 |
Beta Was this translation helpful? Give feedback.
-
|
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.
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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
Beta Was this translation helpful? Give feedback.
All reactions