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

Levinson, Richard J. (ARC-TI)[SGT, INC] richard.j.levinson at nasa.gov
Fri Dec 14 00:08:54 CET 2018


Matthias,

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).  

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
[/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




More information about the Scip mailing list