[SCIP] Infeasible with C-API but feasible with Interactive Shell

Levinson, Richard J. (ARC-TI)[SGT, INC] richard.j.levinson at nasa.gov
Mon Dec 17 23:43:52 CET 2018


Hello Gerald, et. al.,

I have attached solver logs with statistics, model cip files, and solution sol files for two cases: false optimal result, and false infeasible result. 

Context: This is a job scheduling problem with several machines, optional activities and additional scheduling constraints. I am trying to use the optcumulative constraint, but since I cannot read that constraint from a file, it's not included in the older variants of my model which I used for these examples. The two cases described here are very slight variants of the same model. 

* In the false optimal case, I first get a result labeled "optimal" when it is suboptimal (objective function not minimal and one "unscheduled job"), and then I read the same model file and get a correct optimal solution with a much smaller objective value and all jobs are scheduled. 

* In the false infeasible case, I first get a result labeled "infeasible", and then I read the same model file and get the expected feasible solution. 

But there's a new twist: I generated these examples without using the SCIP interactive shell at all!  Instead of reloading the C model into the Shell, I now reload the cip model file back into C and get the expected results when I load the problem from a file into C, compared to when I solve the problem while the model created by my C code is still "in-memory". So instead of a difference between the results from C vs. the shell, it now seems to be a difference between solving the problem directly from the model I create in C, compared to solving it after loading the exact same model from a file. 

Specifically, here is the process I can follow to reproduce both problems without using the Shell:

Step 1) Start my C code, Create problem and save as cip file, solve model, then the C code exits.  This produced the suboptimal and/or feasible results.

Step 2) Restart my C-code, Read the cip model file produced during step 1, solve problem. This produced the expected optimal and/or feasible results. 

The attached zip folder contains 2 folders:

infeasibleExample contains these files:
* problemInfeasible.cip - The cip file written out before calling solve and getting the false infeasible solution, and the same file read in before getting the true feasible solution. 
* scipLogInfeasble.txt - The scip solver log (with statistics) when I get the incorrect infeasible result 
* scipLogFeasible.txt - The scip solver log (with stats) when I get the correct result. 
* solutionFeasible.sol - The correct solution file produced when I reload the model and solve it. 

suboptimalExample contains these files:
* problemSuboptimal.cip - The cip file written out before calling solve and getting the false suboptimal solution, and the same file read in before getting the true optimal solution. 
* scipLogSuboptimal.txt - The scip solver log (with stats) when I get the incorrect results.
* scipLogOptimal.txt       - The scip solver log (with stats) when I get the correct results.
* solutionSuboptimal.sol - The solution file produced for the false optimal result. 
* solutionOptimal.sol       - This is the solution file produced for the correct optimal result. 

Notes about looking at the false optimal data:
I have a binary var for each job indicating if it has been scheduled on any machine. In the case of the "false" optimal result. It says its optimal, but one of the jobs (name "r5d") remains unscheduled which is not the case when I reload the model and solve again.

If you look at the first solution in file scipLogSuboptimal.txt, you can it is says "[optimal solution found]", and the objective is -3.81162200000000e+07 and the binary var r5d.isscheduled  = 0. Those values are also reflected in the associated solution file solutionSuboptimal.sol.

If you look at the first solution in file scipLogOptimal.txt it shows a much smaller objective of -7.82324400000000e+07 and the binary var r5d.isscheduled = 1. Those values are also reflected in the associated solution file solutionOptimal.sol. 

I would appreciate any help to resolve my issue of strange results when I solve directly from the "in-memory" model without having to reload the model file, especially since I plan to use optcumulative which cannot be read in.

Thank you,

   Rich Levinson
________________________________________
From: Gerald Gamrath [gamrath at zib.de]
Sent: Friday, December 14, 2018 1:26 AM
To: Levinson, Richard J. (ARC-TI)[SGT, INC]; Matthias Miltenberger; Ambros Gleixner; scip at zib.de
Subject: Re: [SCIP] Infeasible with C-API but feasible with Interactive Shell

Dear Richard,
> Thanks, you were right that I was calling an old version by accident. Taking your suggestion and running './scip' does now start the shell with SCIP 6.0. So at least now the Shell and my C code are both running 6.0. I wrote out the settings from the shell using 6.0 and then reloaded them into C and found they were the same (no "non-default" settings in the C version after loading the 6.0 shell settings).
>
> However my main problem is that I frequently get suboptimal and infeasible answers in C which differ from the shell results (this problem first occurred when both C and shell were both running 4.0, so don't think running the 6.0 shell will make the difference).
It would be good to check this though, perhaps this was just caused by a
but that we fixed in between versions 4.0 and 6.0.

> To verify/debug my model, I save the cip file created by C and load into the shell, but I cannot load my cip file containing the optcumulative cons into the shell.  Is there a way to read a model file containing optcumulative cons into the shell?
>
> Here's my shell output showing the error:
> SCIP> read jigsawModel.cip
> read problem <jigsawModel.cip>
> ============
>
> WARNING: constraint handler <optcumulative> doesn't exist in SCIP data structure
This warning means that the optcumulative constraint handler is not
included in your binary. The constraint handler is not included in the
SCIP default plugins, but only comes with the Scheduler application. How
do you add it to SCIP via the API? Did you implement your code within
the application? You should compile the Scheduler application after
compiling SCIP so that you can start bin/scheduler from within the
applications/Scheduler directory to get a binary with optcumulative
constraint included.

Unfortunately, though, the optcumulative constraint handler does not
support reading of its own constraints in cip format (yet).

You mentioned that you saw the differences in the solution also before
you used the optcumulative constraint? What kinds of constraints do you
have in your problem? Can you send me the statistics after solving with
both version (API and shell) for a case where the results differ?

By the way, what do you mean by:
 > suboptimal or infeasible when I don't think either is the case

in particular, suboptimal? SCIP just claims to have found an optimal
solution that is worse than what the shell computes?

Best,
Gerald
> [/Users/richardlevinson/scipoptsuite-6.0.0/scip/src/scip/reader_cip.c:717] ERROR: syntax error when reading constraint (line: 65):
>    [optcumulative] <m55.1.downlinkOptCumulativeCons>: <r5d>[8300,22700](7200,1)<r5d.isOn.m55.1>, <r4d>[8300,22700](7200,1)<r4d.isOn.m55.1>, <r6d>[13100,16700](2400,1)<r6d.isOn.m55.1>, <r52d>[19400,21200](3600,1)<r52d.isOn.m55.1>, <r46d>[25400,38000](3600,1)<r46d.isOn.m55.1>, <r7d>[28100,31700](1800,1)<r7d.isOn.m55.1>, <r58d>[29150,30050](1800,1)<r58d.isOn.m55.1>, <r9d>[36500,47300](7200,1)<r9d.isOn.m55.1>, <r8d>[37100,47900](7200,1)<r8d.isOn.m55.1>, <r43d>[39498,41748](3600,1)<r43d.isOn.m55.1> [0,2147483647]<= 4;
> error reading file <jigsawModel.cip>
>
>
> - Rich
> ________________________________________
> From: Matthias Miltenberger [miltenberger at zib.de]
> Sent: Thursday, December 13, 2018 2:34 PM
> To: Levinson, Richard J. (ARC-TI)[SGT, INC]; Gerald Gamrath; Ambros Gleixner; scip at zib.de
> Subject: Re: [SCIP] Infeasible with C-API but feasible with Interactive Shell
>
> Dear Richard,
>
> most likely, you are calling an older SCIP from a previous
> global/system-wide installation. Please try running `./scip` from within
> `scipoptsuite-6.0.0/build/bin` or check which binary is called by
> running `which scip`.
>
> Cheers
> Matthias
>
> On 13-Dec-18 21:40, Levinson, Richard J. (ARC-TI)[SGT, INC] wrote:
>> Hmmm...that is strange indeed since I am calling the shell from the scipoptsuite-6.0.0/build/bin/ directory.  It's inside the sciptoptsuite-6.0.0 bundle so I would have expected it to be 6.0, but sure enough, when I look closely I see the shell clearly prints out it is using scip 4.0 and SoPlex 3.0.0 as shown below:
>>
>> cd ../scipoptsuite-6.0.0/build/bin
>> $ scip
>> SCIP version 4.0.0 [precision: 8 byte] [memory: block] [mode: optimized] [LP solver: SoPlex 3.0.0] [GitHash: a80a247]
>> Copyright (C) 2002-2017 Konrad-Zuse-Zentrum fuer Informationstechnik Berlin (ZIB)
>>
>> Why would calling the shell from the SCIP 6.0.0 build/bin/ directory result in launching SCIP 4.0?
>>
>> On the C side I am definitely using SCIP 6.0 on with SoPlex 4.0.0. Calling SCIPprintVersion() prints out this:
>>
>> SCIP version 6.0.0 [precision: 8 byte] [memory: block] [mode: optimized] [LP solver: SoPlex 4.0.0] [GitHash: 77d3bc8]
>> Copyright (C) 2002-2018 Konrad-Zuse-Zentrum fuer Informationstechnik Berlin (ZIB)
>>
>> So this indicates to me that that I'm getting more reliable results with SCIP 4.0 in the shell compared to SCIP 6.0 with the C-API?   Now I'm even more confused about the path forward.
>>
>>
>> - Rich
>> ________________________________________
>> From: Gerald Gamrath [gamrath at zib.de]
>> Sent: Thursday, December 13, 2018 2:30 AM
>> To: Levinson, Richard J. (ARC-TI)[SGT, INC]; Ambros Gleixner; scip at zib.de
>> Subject: Re: [SCIP] Infeasible with C-API but feasible with Interactive Shell
>>
>> Dear Richard,
>>
>> the parameter conflict/usemir was removed in SCIP release 5.0. Thus, I
>> would guess that you are using an old SCIP library (4.0.1 or older). You
>> can check this by calling SCIPprintVersion().
>>
>> Best,
>> Gerald
>>
>> Am 12.12.18 um 23:46 schrieb Levinson, Richard J. (ARC-TI)[SGT, INC]:
>>> Hello,
>>>
>>> I am still running into the issue where I get very different results when I solve via C-API compared to when I solve via interactive shell. Sometimes it's infeasible with the C version while feasible with the shell, and sometimes the C version finds only suboptimal solutions while the shell finds optimal sols.
>>>
>>> I have gotten used to using the C++ to create the scip model and write it out as a cip file, then loading it into the shell to solve it (as "ground truth" to see if there is a problem with the model or not), then writing out the solution file from the shell, and reloading the sol into C so I can pretty-print the results (painful but doable).
>>>
>>> However, now I am using the OptCumulative constraint from the "scheduling" application in the scip bundle.  It seems to generally work but is giving strange results when I solve in C (suboptimal or infeasible when I don't think either is the case), so I want to write out the model and reload it into the shell, but found that the shell cannot read the optcumulative constraint.
>>>
>>> My questions are:
>>>
>>> 1) Is there a reader for the optcumulative cons that will let me read that type of constraint in the shell? Or should I be writing out the model is some format other than ".cip" if it includes optcumulative constraints.
>>>
>>> 2) Are there any suggestions about how to get my c++ solutions to match those I see in the interactive shell?  It's very disconcerting to not know if there is a problem with my model vs. an issue with solving via the C-API.
>>>
>>> I have wondered if there is some difference in the settings between the shell and the C-API context.
>>> I have written out the SCIP settings into a file from the shell and then read that file into the C-API before solving, but still seems to produce suboptimal solutions.
>>>
>>> Here is info about the settings which may shed light on the issue:
>>>
>>> I am using Scip 6.0. Here is the top of the scip output showing I'm suing SCIP 6.0.0 with SoPlex 4.0.0:
>>>
>>>        SCIP version 6.0.0 [precision: 8 byte] [memory: block] [mode: optimized] [LP solver: SoPlex 4.0.0] [GitHash: 77d3bc8]
>>>        Copyright (C) 2002-2018 Konrad-Zuse-Zentrum fuer Informationstechnik Berlin (ZIB)
>>>        Initial Params
>>>        # SCIP version 6.0.0
>>>
>>> ***************
>>> Copied below is the console output showing what happens when I load the settings from the shell into the C-API. It shows several "unknown" parameters and I wonder if that could be part of the difference between the shell and C.
>>> ***************
>>>
>>> WARNING: unknown parameter <conflict/usemir>
>>> WARNING: unknown parameter <conflict/prefermir>
>>> WARNING: unknown parameter <separating/orthofac>
>>> WARNING: unknown parameter <separating/feastolfac>
>>> WARNING: unknown parameter <constraints/nonlinear/minefficacysepa>
>>> WARNING: unknown parameter <constraints/nonlinear/minefficacyenfofac>
>>> WARNING: unknown parameter <constraints/nonlinear/scaling>
>>> WARNING: unknown parameter <constraints/quadratic/minefficacysepa>
>>> WARNING: unknown parameter <constraints/quadratic/minefficacyenfofac>
>>> WARNING: unknown parameter <constraints/quadratic/scaling>
>>> WARNING: unknown parameter <constraints/quadratic/disaggregate>
>>> WARNING: unknown parameter <constraints/abspower/minefficacysepa>
>>> WARNING: unknown parameter <constraints/abspower/minefficacyenfofac>
>>> WARNING: unknown parameter <constraints/abspower/scaling>
>>> WARNING: unknown parameter <constraints/bivariate/minefficacysepa>
>>> WARNING: unknown parameter <constraints/bivariate/minefficacyenfo>
>>> WARNING: unknown parameter <constraints/bivariate/scaling>
>>> WARNING: unknown parameter <constraints/soc/scaling>
>>> WARNING: unknown parameter <constraints/soc/minefficacy>
>>> WARNING: unknown parameter <presolving/implfree/priority>
>>> WARNING: unknown parameter <presolving/implfree/maxrounds>
>>> WARNING: unknown parameter <presolving/implfree/timing>
>>> WARNING: unknown parameter <heuristics/clique/multiplier>
>>> WARNING: unknown parameter <heuristics/clique/initseed>
>>> WARNING: unknown parameter <heuristics/clique/minfixingrate>
>>> WARNING: unknown parameter <heuristics/completesol/maxunkownrate>
>>> WARNING: unknown parameter <heuristics/vbounds/minfixingrate>
>>> WARNING: unknown parameter <separating/cgmip/allowlocal>
>>> WARNING: unknown parameter <separating/cmir/maxrounds>
>>> WARNING: unknown parameter <separating/cmir/maxroundsroot>
>>> WARNING: unknown parameter <separating/cmir/maxtries>
>>> WARNING: unknown parameter <separating/cmir/maxtriesroot>
>>> WARNING: unknown parameter <separating/cmir/maxfails>
>>> WARNING: unknown parameter <separating/cmir/maxfailsroot>
>>> WARNING: unknown parameter <separating/cmir/maxaggrs>
>>> WARNING: unknown parameter <separating/cmir/maxaggrsroot>
>>> WARNING: unknown parameter <separating/cmir/maxsepacuts>
>>> WARNING: unknown parameter <separating/cmir/maxsepacutsroot>
>>> WARNING: unknown parameter <separating/cmir/maxslack>
>>> WARNING: unknown parameter <separating/cmir/maxslackroot>
>>> WARNING: unknown parameter <separating/cmir/densityscore>
>>> WARNING: unknown parameter <separating/cmir/slackscore>
>>> WARNING: unknown parameter <separating/cmir/maxaggdensity>
>>> WARNING: unknown parameter <separating/cmir/maxrowdensity>
>>> WARNING: unknown parameter <separating/cmir/densityoffset>
>>> WARNING: unknown parameter <separating/cmir/maxrowfac>
>>> WARNING: unknown parameter <separating/cmir/maxtestdelta>
>>> WARNING: unknown parameter <separating/cmir/maxconts>
>>> WARNING: unknown parameter <separating/cmir/maxcontsroot>
>>> WARNING: unknown parameter <separating/cmir/aggrtol>
>>> WARNING: unknown parameter <separating/cmir/trynegscaling>
>>> WARNING: unknown parameter <separating/cmir/fixintegralrhs>
>>> WARNING: unknown parameter <separating/cmir/dynamiccuts>
>>> WARNING: unknown parameter <separating/flowcover/maxrounds>
>>> WARNING: unknown parameter <separating/flowcover/maxroundsroot>
>>> WARNING: unknown parameter <separating/flowcover/maxtries>
>>> WARNING: unknown parameter <separating/flowcover/maxtriesroot>
>>> WARNING: unknown parameter <separating/flowcover/maxfails>
>>> WARNING: unknown parameter <separating/flowcover/maxfailsroot>
>>> WARNING: unknown parameter <separating/flowcover/maxsepacuts>
>>> WARNING: unknown parameter <separating/flowcover/maxsepacutsroot>
>>> WARNING: unknown parameter <separating/flowcover/maxslack>
>>> WARNING: unknown parameter <separating/flowcover/maxslackroot>
>>> WARNING: unknown parameter <separating/flowcover/slackscore>
>>> WARNING: unknown parameter <separating/flowcover/maxrowdensity>
>>> WARNING: unknown parameter <separating/flowcover/dynamiccuts>
>>> WARNING: unknown parameter <separating/flowcover/multbyminusone>
>>> WARNING: unknown parameter <separating/flowcover/maxtestdelta>
>>> WARNING: unknown parameter <separating/gomory/maxweightrange>
>>> WARNING: unknown parameter <separating/strongcg/maxweightrange>
>>> WARNING: unknown parameter <separating/zerohalf/maxcutsfound>
>>> WARNING: unknown parameter <separating/zerohalf/maxcutsfoundroot>
>>> WARNING: unknown parameter <separating/zerohalf/maxdepth>
>>> WARNING: unknown parameter <separating/zerohalf/maxncalls>
>>> WARNING: unknown parameter <separating/zerohalf/relaxcontvars>
>>> WARNING: unknown parameter <separating/zerohalf/scalefraccoeffs>
>>> WARNING: unknown parameter <separating/zerohalf/ignoreprevzhcuts>
>>> WARNING: unknown parameter <separating/zerohalf/onlyorigrows>
>>> WARNING: unknown parameter <separating/zerohalf/usezhcutpool>
>>> WARNING: unknown parameter <separating/zerohalf/delayedcuts>
>>> WARNING: unknown parameter <separating/zerohalf/maxtestdelta>
>>> WARNING: unknown parameter <separating/zerohalf/trynegscaling>
>>> WARNING: unknown parameter <separating/zerohalf/preprocessing/decomposeproblem>
>>> WARNING: unknown parameter <separating/zerohalf/preprocessing/delta>
>>> WARNING: unknown parameter <separating/zerohalf/preprocessing/ppmethods>
>>> WARNING: unknown parameter <separating/zerohalf/separating/forcecutstolp>
>>> WARNING: unknown parameter <separating/zerohalf/separating/forcecutstosepastore>
>>> WARNING: unknown parameter <separating/zerohalf/separating/minviolation>
>>> WARNING: unknown parameter <separating/zerohalf/separating/sepamethods>
>>> WARNING: unknown parameter <separating/zerohalf/separating/auxip/settingsfile>
>>> WARNING: unknown parameter <separating/zerohalf/separating/auxip/sollimit>
>>> WARNING: unknown parameter <separating/zerohalf/separating/auxip/penaltyfactor>
>>> WARNING: unknown parameter <separating/zerohalf/separating/auxip/useallsols>
>>> WARNING: unknown parameter <separating/zerohalf/separating/auxip/objective>
>>>
>>> *******************
>>> After I read the settings, I then print out the new "non-default" settings resulting from reading the shell settings, and this is the output:
>>> *******************
>>>
>>> # SCIP version 6.0.0
>>>
>>> # should bound exceeding LP conflict analysis be used? ('o'ff, 'c'onflict graph, 'd'ual ray, 'b'oth conflict graph and dual ray)
>>> # [type: char, advanced: FALSE, range: {ocdb}, default: b]
>>> conflict/useboundlp = o
>>>
>>> # should infeasible/bound exceeding strong branching conflict analysis be used?
>>> # [type: bool, advanced: FALSE, range: {TRUE,FALSE}, default: TRUE]
>>> conflict/usesb = FALSE
>>>
>>> # maximal fraction of variables involved in a conflict constraint
>>> # [type: real, advanced: TRUE, range: [0,1.79769313486232e+308], default: 0.15]
>>> conflict/maxvarsfac = 0.1
>>>
>>> # minimal absolute maximum of variables involved in a conflict constraint
>>> # [type: int, advanced: TRUE, range: [0,2147483647], default: 0]
>>> conflict/minmaxvars = 30
>>>
>>> # LP solution polishing method (0: disabled, 1: only root, 2: always, 3: auto)
>>> # [type: int, advanced: TRUE, range: [0,3], default: 3]
>>> lp/solutionpolishing = 0
>>>
>>> # minimal efficacy for a cut to enter the LP
>>> # [type: real, advanced: FALSE, range: [0,1e+98], default: 0.0001]
>>> separating/minefficacy = 0.05
>>>
>>> # minimal efficacy for a cut to enter the LP in the root node
>>> # [type: real, advanced: FALSE, range: [0,1e+98], default: 0.0001]
>>> separating/minefficacyroot = 0.001
>>>
>>> # minimal orthogonality for a cut to enter the LP
>>> # [type: real, advanced: FALSE, range: [0,1], default: 0.9]
>>> separating/minortho = 0.5
>>>
>>> # minimal orthogonality for a cut to enter the LP in the root node
>>> # [type: real, advanced: FALSE, range: [0,1], default: 0.9]
>>> separating/minorthoroot = 0.5
>>>
>>> # factor to scale objective parallelism of cut in separation score calculation
>>> # [type: real, advanced: TRUE, range: [0,1e+98], default: 0.1]
>>> separating/objparalfac = 0.0001
>>>
>>> # maximal number of separation rounds per node (-1: unlimited)
>>> # [type: int, advanced: FALSE, range: [-1,2147483647], default: -1]
>>> separating/maxrounds = 5
>>>
>>> # maximal number of separation rounds in the root node of a subsequent run (-1: unlimited)
>>> # [type: int, advanced: TRUE, range: [-1,2147483647], default: -1]
>>> separating/maxroundsrootsubrun = 1
>>>
>>> # maximal number of consecutive separation rounds without objective or integrality improvement in local nodes (-1: no additional restriction)
>>> # [type: int, advanced: FALSE, range: [-1,2147483647], default: 1]
>>> separating/maxstallrounds = 5
>>>
>>> # maximum age a cut can reach before it is deleted from the global cut pool, or -1 to keep all cuts
>>> # [type: int, advanced: TRUE, range: [-1,2147483647], default: 80]
>>> separating/cutagelimit = 100
>>>
>>> # separation frequency for the global cut pool (-1: disable global cut pool, 0: only separate pool at the root)
>>> # [type: int, advanced: FALSE, range: [-1,65534], default: 10]
>>> separating/poolfreq = 0
>>>
>>> # should convex quadratics generated strong cuts via gauge function?
>>> # [type: bool, advanced: FALSE, range: {TRUE,FALSE}, default: FALSE]
>>> constraints/quadratic/gaugecuts = TRUE
>>>
>>> # frequency for propagating domains (-1: never, 0: only in root node)
>>> # [type: int, advanced: FALSE, range: [-1,65534], default: 5]
>>> constraints/orbitope/propfreq = -1
>>>
>>> # priority of heuristic <clique>
>>> # [type: int, advanced: TRUE, range: [-536870912,536870911], default: 5000]
>>> heuristics/clique/priority = -1000500
>>>
>>> # frequency for calling primal heuristic <clique> (-1: never, 0: only at depth freqofs)
>>> # [type: int, advanced: FALSE, range: [-1,65534], default: 0]
>>> heuristics/clique/freq = -1
>>>
>>> # frequency for calling primal heuristic <completesol> (-1: never, 0: only at depth freqofs)
>>> # [type: int, advanced: FALSE, range: [-1,65534], default: 0]
>>> heuristics/completesol/freq = 1
>>>
>>> # whether the one-opt heuristic should be started
>>> # [type: bool, advanced: TRUE, range: {TRUE,FALSE}, default: FALSE]
>>> heuristics/indicator/oneopt = TRUE
>>>
>>> # priority of heuristic <locks>
>>> # [type: int, advanced: TRUE, range: [-536870912,536870911], default: 3000]
>>> heuristics/locks/priority = 2000
>>>
>>> # minimum percentage of integer variables that have to be fixable
>>> # [type: real, advanced: FALSE, range: [0,1], default: 0.65]
>>> heuristics/locks/minfixingrate = 0.25
>>>
>>> # priority of heuristic <vbounds>
>>> # [type: int, advanced: TRUE, range: [-536870912,536870911], default: 2500]
>>> heuristics/vbounds/priority = -1106000
>>>
>>> # frequency for calling primal heuristic <vbounds> (-1: never, 0: only at depth freqofs)
>>> # [type: int, advanced: FALSE, range: [-1,65534], default: 0]
>>> heuristics/vbounds/freq = -1
>>>
>>> # presolving priority of propagator <vbounds>
>>> # [type: int, advanced: TRUE, range: [-536870912,536870911], default: -90000]
>>> propagating/vbounds/presolpriority = 0
>>>
>>> # timing mask of the presolving method of propagator <vbounds> (4:FAST, 8:MEDIUM, 16:EXHAUSTIVE, 32:FINAL)
>>> # [type: int, advanced: TRUE, range: [2,60], default: 24]
>>> propagating/vbounds/presoltiming = 28
>>>
>>> # priority of separator <flowcover>
>>> # [type: int, advanced: TRUE, range: [-536870912,536870911], default: -100000]
>>> separating/flowcover/priority = -4000
>>>
>>> # frequency for calling separator <flowcover> (-1: never, 0: only in root node)
>>> # [type: int, advanced: FALSE, range: [-1,65534], default: 10]
>>> separating/flowcover/freq = 0
>>>
>>> # priority of separator <cmir>
>>> # [type: int, advanced: TRUE, range: [-536870912,536870911], default: -100000]
>>> separating/cmir/priority = -3000
>>>
>>> # frequency for calling separator <cmir> (-1: never, 0: only in root node)
>>> # [type: int, advanced: FALSE, range: [-1,65534], default: 10]
>>> separating/cmir/freq = 0
>>>
>>> # frequency for calling separator <gomory> (-1: never, 0: only in root node)
>>> # [type: int, advanced: FALSE, range: [-1,65534], default: 10]
>>> separating/gomory/freq = 0
>>>
>>> # maximal relative distance from current node's dual bound to primal bound compared to best node's dual bound for applying separator <gomory> (0.0: only on current best node, 1.0: on all nodes)
>>> # [type: real, advanced: TRUE, range: [0,1], default: 1]
>>> separating/gomory/maxbounddist = 0
>>>
>>> # maximal rank of a gomory cut that could not be scaled to integral coefficients (-1: unlimited)
>>> # [type: int, advanced: FALSE, range: [-1,2147483647], default: -1]
>>> separating/gomory/maxrank = 3
>>>
>>> # try to scale cuts to integral coefficients
>>> # [type: bool, advanced: TRUE, range: {TRUE,FALSE}, default: FALSE]
>>> separating/gomory/makeintegral = TRUE
>>>
>>> # should cuts be added to the delayed cut pool?
>>> # [type: bool, advanced: TRUE, range: {TRUE,FALSE}, default: FALSE]
>>> separating/gomory/delayedcuts = TRUE
>>>
>>> # choose side types of row (lhs/rhs) based on basis information?
>>> # [type: bool, advanced: TRUE, range: {TRUE,FALSE}, default: TRUE]
>>> separating/gomory/sidetypebasis = FALSE
>>>
>>> # frequency for calling separator <impliedbounds> (-1: never, 0: only in root node)
>>> # [type: int, advanced: FALSE, range: [-1,65534], default: 10]
>>> separating/impliedbounds/freq = 0
>>>
>>> # maximal relative distance from current node's dual bound to primal bound compared to best node's dual bound for applying separator <impliedbounds> (0.0: only on current best node, 1.0: on all nodes)
>>> # [type: real, advanced: TRUE, range: [0,1], default: 1]
>>> separating/impliedbounds/maxbounddist = 0
>>>
>>> # frequency for calling separator <strongcg> (-1: never, 0: only in root node)
>>> # [type: int, advanced: FALSE, range: [-1,65534], default: 10]
>>> separating/strongcg/freq = 0
>>>
>>> # maximal relative distance from current node's dual bound to primal bound compared to best node's dual bound for applying separator <strongcg> (0.0: only on current best node, 1.0: on all nodes)
>>> # [type: real, advanced: TRUE, range: [0,1], default: 1]
>>> separating/strongcg/maxbounddist = 0
>>>
>>> # maximal number of strong CG cuts separated per separation round
>>> # [type: int, advanced: FALSE, range: [0,2147483647], default: 20]
>>> separating/strongcg/maxsepacuts = 50
>>>
>>> # frequency for calling separator <zerohalf> (-1: never, 0: only in root node)
>>> # [type: int, advanced: FALSE, range: [-1,65534], default: 10]
>>> separating/zerohalf/freq = -1
>>>
>>> # maximal relative distance from current node's dual bound to primal bound compared to best node's dual bound for applying separator <zerohalf> (0.0: only on current best node, 1.0: on all nodes)
>>> # [type: real, advanced: TRUE, range: [0,1], default: 1]
>>> separating/zerohalf/maxbounddist = 0
>>>
>>> # maximal number of zerohalf separation rounds in the root node (-1: unlimited)
>>> # [type: int, advanced: FALSE, range: [-1,2147483647], default: 20]
>>> separating/zerohalf/maxroundsroot = 10
>>>
>>> # maximal number of zerohalf cuts separated per separation round
>>> # [type: int, advanced: FALSE, range: [0,2147483647], default: 20]
>>> separating/zerohalf/maxsepacuts = 50
>>>
>>> # maximal number of zerohalf cuts separated per separation round in the root node
>>> # [type: int, advanced: FALSE, range: [0,2147483647], default: 100]
>>> separating/zerohalf/maxsepacutsroot = 500
>>>
>>>
>>> Thank you,
>>>
>>>        Rich
>>>
>>>
>>> ________________________________________
>>> From: Scip [scip-bounces at zib.de] on behalf of Ambros Gleixner [gleixner at zib.de]
>>> Sent: Thursday, July 12, 2018 8:00 AM
>>> To: scip at zib.de
>>> Subject: Re: [SCIP] Infeasible with C-API but feasible with Interactive Shell
>>>
>>> Hi Rich,
>>>
>>> One natural thing to try would be: write the feasible solution found by
>>> the shell into a sol file and read this in your API code.  If the
>>> solution is rejected, looking at the violated constraint will bring us
>>> closer to the source of the problem.
>>>
>>> Expert mode: compile with cmake -DDEBUGSOL=on and pass the path to the
>>> solfile to parameter "misc/debugsol".  Then SCIP will check and print
>>> where it is cut off.
>>>
>>> Best,
>>> Ambros
>>>
>>>
>>>
>>> Am 11.07.2018 um 05:48 schrieb Levinson, Richard J. (ARC-TI)[SGT, INC]:
>>>> I have now upgraded to SCIP 6.0.0 and still have the same problem.
>>>>
>>>> The solver returns 'infeasible' with the C-API but is feasible with the
>>>> interactive shell.
>>>>
>>>> I am literally copying model text from the scip log of the infeasible
>>>> run into a .cip file and then reading it into the interactive shell,
>>>> where a feasible solution is found and no changes to the model at all.
>>>> Now both cases are using SCIP 6.0.0 so it is not a version issue.
>>>>
>>>> - Rich
>>>> ------------------------------------------------------------------------
>>>> *From:* Levinson, Richard J. (ARC-TI)[SGT, INC]
>>>> *Sent:* Tuesday, July 10, 2018 3:58 PM
>>>> *To:* Scip at zib.de
>>>> *Subject:* Infeasible with C-API but feasible with Interactive Shell
>>>>
>>>> Hello,
>>>>
>>>> I have a SCIP model generated using the C-API. It returns 'infeasible'
>>>> when I call solve() programmatically, but if I copy the SCIP "original
>>>> problem" output from the SCIP log file of the 'infeasible' run, and copy
>>>> it directly into a .cip file and read it back in through the interactive
>>>> shell, then it is 'feasible'.
>>>>
>>>> The C-API is being linked against SCIP 4.0 but the model is feasible in
>>>> the SCIP 4.0 interactive shell (as well as the SCIP 6.0 interactive shell).
>>>>
>>>> Any suggestions about how to diagnose and resolve this discrepancy? I
>>>> need to be able to generate the model and solve via C-API. Is there a
>>>> good way to figure out why it's being marked infeasible via the C-API?
>>>>
>>>> Thank you,
>>>>
>>>>        Rich Levinson
>>>>
>>>>
>>>> _______________________________________________
>>>> Scip mailing list
>>>> Scip at zib.de
>>>> https://listserv.zib.de/mailman/listinfo/scip
>>>>
>>> --
>>> Ambros Gleixner, Research Group Mathematical Optimization Methods at
>>> Zuse Institute Berlin, http://www.zib.de/gleixner
>>> _______________________________________________
>>> Scip mailing list
>>> Scip at zib.de
>>> https://listserv.zib.de/mailman/listinfo/scip
>>>
>>> _______________________________________________
>>> Scip mailing list
>>> Scip at zib.de
>>> https://listserv.zib.de/mailman/listinfo/scip
>> _______________________________________________
>> Scip mailing list
>> Scip at zib.de
>> https://listserv.zib.de/mailman/listinfo/scip
> --
> \__________________
>
> Matthias Miltenberger
> Zuse Institute Berlin
> Takustr. 7, 14195 Berlin
> www.zib.de/miltenberger
> miltenberger at zib.de
> +49 (30) 841 85 245
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: scipTests.zip
Type: application/zip
Size: 86752 bytes
Desc: scipTests.zip
URL: <http://listserv.zib.de/pipermail/scip/attachments/20181217/34a3efc4/attachment.zip>


More information about the Scip mailing list