[Scip] Using knapsack constraint in standalone solver

[Gerald Gamrath]

Hi Nick,

first, you registered for the SCIP mailing list with a different address 
than you used for your last two mails. The problem with this is, that 
your mails are blocked by the list, if your address is not registered. 
Thus please use your registered email address, if you want to write to 
the list, or tell us, if you want us to change your registered email 
address.

Now to your questions:
> I'm sorry to Daniel that my suggestion didn't turn out to be any use,
> no doubt it would be a fairly simple matter to implement that routine,
> or perhaps make it call the integer routine since presumably a
> knapsack constraint looks pretty much like an integer constraint?  I
> tend to use presolve off and try to control things myself so this
> could be useful to me in the future.
We are working on finishing the parse methods for all constraint types. 
Each single one is not so much work, but there are many different 
constraint types (for some of them, there already are parsing methods 
available), and implementing all of them costs some time.
> One thing that would be really good for the standalone solver mode
> would be a bit more control over which plugins to use, if you are
> writing in C you simply initialize the plugins you want, but the
> standalone solver loads all plugins (I forget which C file does this,
> it was a few levels in), I wanted to see which heuristics/cutting
> planes/etc work the best on my problem so I had to change the C file
> of the scip executable to contain a massive lot of nested #ifdef's to
> let me put blocks of plugins in and out (sort of like a binary
> search).  It would be best if plugins were loaded from dll or so files
> on demand, and maybe not load all plugins by default (only a subset
> which performs well on miplib instances, say?)  I understand that most
> plugins have an option or options to disable them but the problem is
> that there is no uniform method so it takes ages to work through them
> all and also you could easily misunderstand the settings and think it
> was disabled when it wasn't.
Well, except for that you might misunderstand the settings, I would 
prefer to disable a plugin by one single parameter instead of not 
loading it. Instead of having lots of #ifdef's, and compiling the code 
again for each set of plugins you want to use, I would suggest, you just 
use setting files. After you switched some settings in the interactive 
shell, you can save the setting by "set save xyz.set" (stores all 
settings) or by "set diffsave xyz.set" (stores only non-default 
settings). By using the latter alternative, you can define different 
settings for groups of plugins like heuristics, separators, etc., and 
combine them by just reading in one setting for each group by "set load 
xyz.set".
For each type of plugins, the parameter you have to change in order to 
disable a plugin of that type should be the same (except for the plugin 
name). For example, you disable heuristic xyz by setting 
"heuristics/xyz/freq" to -1, you disable separator xyz by setting 
"separating/xyz/freq" to -1,and you disable presolvers by setting their 
maxrounds parameter to 0. You can also write the settings by hand into 
the settings file, just have a look at how the parameters are named.

Just another hint: There are emphasis settings for heuristics, 
separators, and presolvers that you can use, e.g., if you want to 
disable them all.
> This brings me to another point:  The
> interface for configuring all plugins is basically collected into a
> massive C file (at least according to my memory) whereas it would be
> better if it was located in the plugin's actual source code.  I
> understand that many people just link to scip and have no interest in
> the standalone command line interface but surely it would be a small
> price to pay to just include it in each plugin anyway?  It is a while
> since I worked on this so please do correct me if I'm wrong but I just
> thought I should get a few thoughts out while we are discussing the
> standalone solver.
Due to the modular design of SCIP, it is actually as you propose. Each 
plugin adds its own parameters to the core, by calling 
SCIPaddIntParam(), SCIPaddBoolParam(), etc. In most cases, this is done 
in the SCIPincludePlugintypePluginname method.

Best,
Gerald