Solver options for scip using pyomo

[kdheepak]

I was wondering if there was any way to set solver options such as mipgap for scip. This is a list of all the parameters that scip accepts.

[blnicho]

Please see the online documentation for setting solver options:
Using the Pyomo command: https://software.sandia.gov/downloads/pub/pyomo/PyomoOnlineDocs.html#_passing_options_to_a_solver
Using a script: https://software.sandia.gov/downloads/pub/pyomo/PyomoOnlineDocs.html#SolverOpts

In general you can specify any option a solver accepts, you just have to make sure you are setting the appropriate option name for a particular solver.

[kdheepak]

I get the following error if I try running the command --solver-options='limits/gap=0.01'

ERROR: cannot open file <limits/gap=0.01> for reading

I've been able to add a mipgap with glpk and gurobi, but not scip

[ghackebeil]

Our solver plugin to SCIP uses the ASL interface. You need to have the scipampl executable built, and you need to be using option names that are available through that interface. You can see the list of available options for most ASL based solvers using a command like:

scipampl -=

Gabe

On Sep 27, 2016, at 11:44 AM, Dheepak Krishnamurthy notifications@github.com wrote:

I get the following error if I try running the command --solver-options='limits/gap=0.01'

ERROR: cannot open file <limits/gap=0.01> for reading
I've been able to add a mipgap with glpk and gurobi, but not scip

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[kdheepak]

This post seems to suggest that scipampl does not support solver options. And when I run scipampl -= I get the following. I'm not sure if that's what you supposed it'd say? Thoughts?

SCIP version 3.2.1 [precision: 8 byte] [memory: block] [mode: optimized] [LP solver: SoPlex 2.2.1] [GitHash: c7c6c02]
Copyright (c) 2002-2016 Konrad-Zuse-Zentrum fuer Informationstechnik Berlin (ZIB)

External codes:
  Readline EditLine w  GNU library for command line editing (gnu.org/s/readline)
  SoPlex 2.2.1         Linear Programming Solver developed at Zuse Institute Berlin (soplex.zib.de) [GitHash: 267a44a]
  cppad-20140000.3     Algorithmic Differentiation of C++ algorithms developed by B. Bell (www.coin-or.org/CppAD)
  ZLIB 1.2.5           General purpose compression library by J. Gailly and M. Adler (zlib.net)
  GMP 6.1.1            GNU Multiple Precision Arithmetic Library developed by T. Granlund (gmplib.org)
  ZIMPL 3.3.3          Zuse Institute Mathematical Programming Language developed by T. Koch (zimpl.zib.de)
  ASL                  AMPL Solver Library developed by D. Gay (www.netlib.com/ampl)


number of parameters = 1886
non-default parameter settings:

file <-=.nl> not found

no problem exists

[src/reader_nl.c:1694] ERROR: No AMPL problem read, cannot write AMPL solution then.

[blnicho]

According to this post, another way to set options is to write a 'scip.set' file and specify options using the scip parameter names. Just make sure this file is in the same directory as your model file.

I'm pretty sure there is a way to set the options directly from the Pyomo command line but this might be a good work around in the meantime. It also might be a better solution if you plan on changing many of the options or repeatedly specifying certain options.

[kdheepak]

Great! That works. However, (as I understand it) this will not work if I want to do the following, is that correct?

from pyomo.environ import *                                    # import pyomo environment
from ReferenceModel import model                               # import model

instance = model.create_instance('model.dat')

solver = SolverFactory('scip')                                 # create the scip solver
results = solver.solve(instance)                               # solve

[blnicho]

It should work in that case as well. I've never tried it with scip but I've done the exact same thing with an ipopt options file.

[ghackebeil]

If SCIP doesn't accept command-line options like other solvers compiled against ASL, we should consider writing this file for the user. The current SCIP plugin is simply going to confuse people if setting any options on the solver plugin just causes the solver to fail (because we try to set them on the command-line).

This also brings up the question of whether or not we should do the same thing for Ipopt. I know that the set of options exposed through the command-line for the Ipopt executable is a subset of the options that can be set using an options file (some of the options have different names as well). I think it would make a lot of sense to make the full set of options available to the user through Pyomo. This would involve creating a very lightweight Ipopt solver plugin that changes how the solver options are handled.

On the other hand, I know many users that expect the options file to work independent of Pyomo, so this might break their workflow. @carldlaird: What do you think?

[whart222]

I like this suggestion. Add a ticket!

On Wed, Sep 28, 2016 at 7:51 PM, Gabriel Hackebeil <notifications@github.com

wrote:

If SCIP doesn't accept command-line options like other solvers compiled
against ASL, we should consider writing this file for the user. The current
SCIP plugin is simply going to confuse people if setting any options on
the solver plugin just causes the solver to fail (because we try to set
them on the command-line).

This also brings up the question of whether or not we should do the same
thing for Ipopt. I know that the set of options exposed through the
command-line for the Ipopt executable is a subset of the options that can
be set using an options file (some of the options have different names as
well). I think it would make a lot of sense to make the full set of options
available to the user through Pyomo. This would involve creating a very
lightweight Ipopt solver plugin that changes how the solver options are
handled.

On the other hand, I know many users that expect the options file to work
independent of Pyomo, so this might break their workflow. @carldlaird
https://github.com/carldlaird: What do you think?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#48 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAsb-G67ClQlFxUVmPSVLyXQxTtywhzCks5quv2TgaJpZM4KHwC3
.