[SCIP] SCIP solver parameter optimization

[Leona Gottwald]

Dear Nils,


Since you use SCIP as a library one thing apart from the parameters that
you can try is to formulate your prolem in different ways. E.g. use the
specialized constaint types like SOS1, or use a different formulation
which relies on more general constraints. Sometimes performance can be
better with more general linear constraints because it gives SCIP
freedom to exploit different structures which are sometimes more
important than the ones enforced by modelling a certain way.


Apart from that some tips for tuning SCIP parameters in general:


- Have a look at the statistics after soving ("display statistics" on
the SCIP shell). You can see which plugins take what amount of the
solving time. Then you can play with disabling plugins that take a lot
of time and/or do not seem to be successful on your type of problem.


- SCIP provides emphasis settings "fast", "default", "aggressive", and
"off" for the categories "presolving", "heuristics", and "separating".
E.g. you can set presolving to aggressive on the SCIP shell with the
command set "set presolving emphasis aggressive". With those emphasis
setting you can quickly explore if some of the implemented techniques
work especially well on your type of problems. It is good to not only
look at the solving time in this case but also use the statistics
because the emphasis setting might enable one technique that is helpful
and another that takes too long.


- Depending on your type of problem separation can be very good or
taking too much time. You can see a trend with the emphasis settings. If
separation is important for your type of problem these are some
parameters that can have a big impact.


Limits for separators and amount of cuts can be too low/high for some
problems. Especially it is worthwhile to look at the limits in the
separators that seem to perform well in the statistics. Important ones
for MIPs are often gomory, zerohalf, strongcg, aggregation. The
separator "aggregation" is the one that actually finds the cuts listed
under the separators cmir and flowcover. Limits should be adjusted in
the former and not the latter separators, they are only for statistic
purposes. They can be disabled though (e.g. separating/flowcover/freq =
-1), then the aggregation separator will only separate the enabled type
of cuts (cmir or lifted flowcover cuts).

separating/maxcuts(root)

separating/maxrounds(root)

separating/<separator>/maxrounds(root)

separating/<separator>/maxsepacuts(root)


This rarely works much better for certain types of problems

separating/efficacynorm = 'd'


For some problems a value of 1.0 can be much faster, for others too many
cuts are discarded and a much lower value of 0.1 or 0.5 can be better.

separating/minortho(root)


A higher value can sometimes help if too many cuts are found

separating/minefficacy(root)


the cut selection score is a linear combination using weights that can
be tuned by these parameters:

separating/efficacyfac

separating/dircutoffdistfac

separating/intsupportfac

separating/objparalfac


There are certainly more settings that can have a considerable impact on
performance.

To find them it is important to know what is the bottleneck for a
problem at hand.

Sometimes it is the LP solving, sometimes solutions are not found fast
enough, and sometimes too much or not enough time is spent with certain
techniques.

I hope this gives you a start to find out what settings work good for
your problem type.


Best
Leona



On 3/16/20 6:58 PM, Speetzen, Nils wrote:
>
> Dear SCIP team,
>
>
> I am currently using SCIP as a branch-and-cut solver for an integer
> linear problem. Since the nature of the problem I want to solve using
> SCIP always stays the same, I want to optimize the configuration
> parameters to achieve better runtimes and wondered whether You can
> give me some hints towards which settings are usually the most
> impactful, since I found the number of parameters to be very large. I
> am guessing that most likely some of the "branching/" parameters such
> as "branching/firstsbchild" are useful in my case, but I am not sure.
>
>
> My problem consists of only binary decision variables and very
> systematic constraints. First, equally sized subsets of the variables
> have the constraint, that only one of them can be true, which I
> implemented as an SOS1 constraint. Secondly, every binary variable
> either enables or disables a matrix, all of the matrices of the
> enables variables are then summed up and have to be less than a
> constraint matrix at every entry. The constraint matrix roughly allows
> for each SOS1 group to activate one matrix such that the sum stays
> below it (e.g. 621 of 624 SOS1 constraints have an active members in
> my solutions so far). The objective is to maximize the sum of the
> entries in the summed up matrix.
>
> The problem scales with the number of binary variables and the size of
> the matrices, all of which are of the same size.
>
>
> I hope it is possible for you to take a look at my problem and maybe
> propose some settings.
>
> Kind regards,
>
>
> Nils Speetzen
>
>
> p.s.: I am using SCIP as a library for C++, the runtime for a
> reference problem is currently about 20 seconds long.
>
>
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> https://listserv.zib.de/mailman/listinfo/scip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.zib.de/pipermail/scip/attachments/20200330/831213d7/attachment.html>