scipopt / scip.jl Goto Github PK

It's not currently listed in the table, or the overview figure.

See discussion in issue Cbc.jl/#100 and PR Cbc.jl/#101,

Still need scipoptsuite dependency 😞

Also, can we enforce a dependency on a specific version of CSIP?

Hi,

I tried to build SCIP on Windows, which is unfortunately not possible.
Would it be possible to provide an updated version that supports it?

Anton

At the moment, set*callback only adds to the callbacks that are registered (with CSIP). But the expected behaviour in MathProgBase is that at most on callback of each type exists, so we should remove existing callbacks first.

See also #19.

See #85 for previous issue and #88 for discussion.

This requires upstream changes in SCIP itself.

Not sure whether the problem was introduced in SCIP itself, or in our work-around way of building the shared library.

cc: @chkwon @fserra

Fix attempted in #45

If so, should mention explicitly.

Can build.jl download and compile the SCIP source codes by itself without needing SCIPOPTDIR? Is there anything that prevent it? License issue, perhaps? I just doubt that normal Julia users will need SCIP codes and binaries outside Julia. If they need it, they will install it outside Julia, I guess. Just like Ipopt.

I compiled with make SHARED=true ZLIB=false GMP=false READLINE=false LPSOPT=opt-gccold OPT=opt-gccold IPOPT=true scipoptlib

drawing attention to IPOPT=true, yet one I try to solve my model within JuMP I get

"Quadratic constraint handler does not have LAPACK for eigenvalue computation. Will assume that matrices (with size > 2x2) are indefinite."

I thought the way to resolve this was to compile with IPOPT=true, but that is what I have done and still get this error.

@JuliaRegistrator register()

Summary: When I use SCIP.jl to pass a MINLP JuMP model to SCIP, the solve complains the initial point is infeasible. When I use AmplNLWriter to send the same model to SCIP, it correctly classifies the initial point as feasible.

Example:

using JuMP, SCIP, AmplNLWriter

# Switch between interfaces to SCIP
#m = Model(solver=SCIPSolver())
m = Model(solver=AmplNLSolver("/opt/scipoptsuite-4.0.0/scip-4.0.0/interfaces/ampl/bin/scipampl"))

@variable(m, 0 <= x[1:3] <= 10, start=5.0)
@variable(m, y, Bin, start=1.0)

@NLconstraint(m, x[1] + x[2] <= x[3]*y)
@constraint(m, x[1] - x[2] == 0)

@objective(m, Min, x[1])

# This makes the initial point feasible
setvalue(x[3], 10.0)

solve(m)

Using SCIP.jl:

  [nonlinear] <nonlin_obj>: (1 * <_var0_>)-1<_var4_>[C]  <= 0;
violation: right hand side is violated by 5 (scaled: 5)
all 1 solutions given by solution candidate storage are infeasible

feasible solution found by trivial heuristic after 0.0 seconds, objective value 0.000000e+00
presolving:
(round 1, fast)       0 del vars, 0 del conss, 0 add conss, 0 chg bounds, 0 chg sides, 0 chg coeffs, 3 upgd conss, 0 impls, 0 clqs
(round 2, fast)       2 del vars, 2 del conss, 0 add conss, 2 chg bounds, 0 chg sides, 0 chg coeffs, 3 upgd conss, 0 impls, 0 clqs
presolving (3 rounds: 3 fast, 0 medium, 0 exhaustive):
 3 deleted vars, 2 deleted constraints, 0 added constraints, 2 tightened bounds, 0 added holes, 0 changed sides, 0 changed coefficients
 0 implications, 0 cliques
transformed 1/1 original solutions to the transformed problem space
Quadratic constraint handler does not have LAPACK for eigenvalue computation. Will assume that matrices (with size > 2x2) are indefinite.
Presolving Time: 0.01

SCIP Status        : problem is solved [optimal solution found]
Solving Time (sec) : 0.01
Solving Nodes      : 0
Primal Bound       : +0.00000000000000e+00 (1 solutions)
Dual Bound         : +0.00000000000000e+00
Gap                : 0.00 %
:Optimal

Using AmplNLWriter:

SCIP version 4.0.0 [precision: 8 byte] [memory: block] [mode: optimized] [LP solver: CPLEX 12.6.3.0] [GitHash: a80a247]
Copyright (C) 2002-2017 Konrad-Zuse-Zentrum fuer Informationstechnik Berlin (ZIB)

External codes: 
  CPLEX 12.6.3.0       Linear Programming Solver developed by IBM (www.cplex.com)
  CppAD 20160000.1     Algorithmic Differentiation of C++ algorithms developed by B. Bell (www.coin-or.org/CppAD)
  Ipopt 3.12.4         Interior Point Optimizer developed by A. Waechter et.al. (www.coin-or.org/Ipopt)
  ASL                  AMPL Solver Library developed by D. Gay (www.netlib.com/ampl)


number of parameters = 2137
non-default parameter settings:


read problem </home/adowling2/.julia/v0.5/AmplNLWriter/.solverdata/tmpVJvBW1.nl>
============

original problem has 4 variables (1 bin, 0 int, 0 impl, 3 cont) and 2 constraints

1/1 feasible solution given by solution candidate storage, new primal bound 5.000000e+00

feasible solution found by trivial heuristic after 0.0 seconds, objective value 0.000000e+00
presolving:
presolving (1 rounds: 1 fast, 0 medium, 0 exhaustive):
 0 deleted vars, 0 deleted constraints, 0 added constraints, 0 tightened bounds, 0 added holes, 0 changed sides, 0 changed coefficients
 0 implications, 0 cliques
transformed 3/3 original solutions to the transformed problem space
Presolving Time: 0.00

SCIP Status        : problem is solved [optimal solution found]
Solving Time (sec) : 0.01
Solving Nodes      : 0
Primal Bound       : +0.00000000000000e+00 (3 solutions)
Dual Bound         : +0.00000000000000e+00
Gap                : 0.00 %

optimal solution found

:Optimal

Perhaps this is a red herring, but notice the warning message about LAPACK eigenvalue computation with SCIP.jl. Including Ipopt is supposed to provide an interface to LAPACK. Using the AMPL executable for SCIP, we see that Ipopt is included as an external code and the warning message is absent.

Edit x2: Using @NLobjective instead of @objective results in the same behavior.

I'm running into the error

MathProgBase.addvar!(m::SCIPLinearQuadraticModel, l, u, objcoef) = error("Not implemented for SCIP.jl")

via a call to JuMP's @variable(model) to a model that has already been constructed. Is there any way I can get around this?

Here is the stack trace up to the JuMP call:

 [1] addvar!(::SCIP.SCIPLinearQuadraticModel, ::Float64, ::Float64, ::Float64) at /home/ubuntu/.julia/v0.6/SCIP/src/mpb_interface.jl:216
 [2] JuMP.Variable(::JuMP.Model, ::Float64, ::Float64, ::Symbol, ::String, ::Float64) at /home/ubuntu/.julia/v0.6/JuMP/src/JuMP.jl:399
 [3] #constructvariable!#113(::Array{Any,1}, ::Function, ::JuMP.Model, ::JuMP.#_error#120{Tuple{Symbol}}, ::Float64, ::Float64, ::Symbol, ::String, ::Float64) at /home/ubuntu/.julia/v0.6/JuMP/src/macros.jl:971
 [4] macro expansion at /home/ubuntu/.julia/v0.6/JuMP/src/macros.jl:319 [inlined]

I'm on JuMP 0.8.4.

We need to call SCIPexprCreate which has variadic arguments. This is supported by Julia's ccall, but only for variadic arguments of the same type.

This was already discussed in #100 and on Discourse.

The suggested solution is to create a thin C wrapper, which exposes function without variadic arguments. Unfortunately, we still need those for SCIP_EXPR_SUM and SCIP_EXPR_PRODUCT.

The installation guide says to

Choose an installation path and set the environment variable SCIPOPTDIR to point there.

What installation path should I specify? Is this the same directory that I extracted the .tar.gz file to, or will any directory do (even if it doesn't exist on disk?)

This applies to the rewrite (after #76 is merged).

Currently, the simple @SC macro is used everywhere, where on would use SCIP_CALL in C.
It only does an @assert to check that the return code is SCIP_OKAY.

It would be better to throw a custom exception, also explaining what happened.

Not sure if we can actually show the full stacktrace (including the SCIP calls). I believe this requires compiling SCIP in debug mode?

cc @fserra

There seem to be major memory leaks somewhere between SCIP.jl, CSIP and SCIP.
See this gist for a script that realiably fills up all memory on my 4GB notebook and instantly freezes the system :-\

@fserra: do you want to debug this on saturday, and get lunch at Risa afterwards?

How does this interact with variable bounds? I.e., what if you have x == 1, Binary. Does this drop the tighter bounds? I'd also want an error/infeasibility report for 2 <= x <= 3, Binary.

Originally posted by @mlubin in https://github.com/_render_node/MDE3OlB1bGxSZXF1ZXN0UmV2aWV3MTg4NTYwNjMz/pull_request_reviews/more_threads

I couldn't reply to the comment on #76 for some reason, so opening an issue. The current code in #76 seems to silently ignore user-provided bounds on binary variables.

SCIP allows for user defined expressions. One could in principle give the evaluations via callbacks (as I guess other solvers do), in case we cannot understand the expression provided to MPB.
This is probably future future work

I'm trying to use SCIP.jl to solve a simple nonlinear optimization, but so far any nonlinear constraints cause the same memory allocation failure. For example:

using JuMP, SCIP

m = Model(solver=SCIPSolver())
@variable m -5 <= x <= 5
@NLconstraint m x <= 2
solve(m)

fails with:

[/home/rdeits/apps/scipoptsuite-5.0.1/scip/src/blockmemshell/memory.c:1052] ERROR: Insufficient memory for allocation of 18446744073701163096 bytes.
[/home/rdeits/apps/scipoptsuite-5.0.1/scip/src/nlpi/expr.c:12244] ERROR: Insufficient memory for new chunk.
[/home/rdeits/apps/scipoptsuite-5.0.1/scip/src/nlpi/expr.c:12244] ERROR: No memory in function call
[/home/rdeits/apps/scipoptsuite-5.0.1/scip/src/nlpi/expr.c:12766] ERROR: Error <-1> in function call
[/home/rdeits/apps/scipoptsuite-5.0.1/scip/src/nlpi/expr.c:15381] ERROR: Error <-1> in function call
[/home/rdeits/apps/scipoptsuite-5.0.1/scip/src/scip/cons_nonlinear.c:8424] ERROR: Error <-1> in function call
[/home/rdeits/apps/scipoptsuite-5.0.1/scip/src/scip/cons.c:1584] ERROR: Error <-1> in function call
[/home/rdeits/apps/scipoptsuite-5.0.1/scip/src/scip/cons.c:6670] ERROR: Error <-1> in function call
[/home/rdeits/apps/scipoptsuite-5.0.1/scip/src/scip/prob.c:1318] ERROR: Error <-1> in function call
[/home/rdeits/apps/scipoptsuite-5.0.1/scip/src/scip/prob.c:571] ERROR: Error <-1> in function call
[/home/rdeits/apps/scipoptsuite-5.0.1/scip/src/scip/scip.c:13987] ERROR: Error <-1> in function call
[/home/rdeits/apps/scipoptsuite-5.0.1/scip/src/scip/scip.c:15978] ERROR: Error <-1> in function call
[/home/rdeits/apps/scipoptsuite-5.0.1/scip/src/scip/scip.c:16198] ERROR: Error <-1> in function call
CSIP: failing with retcode 2 at /home/rdeits/.julia/v0.6/SCIP/deps/src/CSIP-0.5.0/src/csip.c:997

I built the scipoptsuite from source following the instructions in the SCIP.jl readme, and I'm using the version of CSIP which is automatically downloaded by Pkg.build("SCIP").

I've also run the full test suite for scipoptsuite with ctest, and the only tests which fail are the ones which require the MA27 solver. I've likewise run the tests for CSIP with make test and again, all of those tests pass except the ones requiring MA27.

Can you help?

Is it expected in principle for solutions to violate cuts you've already added through the callbacks earlier? If so, is there an option to force SCIP to only give solutions in callbacks that satisfy ALL of the cuts already added?

Only row-wise addition is supported in CSIP.

SCIP and SCIP.jl support disjunctive formulations:
https://github.com/SCIP-Interfaces/SCIP.jl/blob/master/src/wrapper/cons_disjunction.jl

However, it's not clear from the signature how the API works, including expected types at each point.

To be fair, I'm not sure it's a SCIP.jl or SCIP core issue, I'll close it if considered unnecessary

Right now, when a constraint is added that forces a variable into MOI.ZeroOne, we also change the bounds (in SCIP) to [0, 1], or else the solver will fail.

This is a problem in cases where previously defined bounds (e.g. [0, 2]) are overwritten and later the ZeroOne constraint is deleted, without resetting the bounds properly.

This should be easy to do, based on CSIP, but there are some challenges:

1. Incomplete solutions (with NaN values) are not currently support by SCIP and therefore CSIP. This feature (solution completion by neighborhood search) might be included in the next SCIP release, but even then it might only work for solution candidates added before the branch-and-bound process.
2. CSIP only supports adding one solution per callback call. It should be possible to refactor that code, though.
3. The tests from JuMP for heuristic callbacks fail on my initial implementation because the callback is never called. This is because the heuristic timing is set to AFTERNODE (which makes sense, because we then have the LP relaxation values) but the problem used in the tests is already solved during the root. Therefore, the solving is stopped before the heuristic is asked.

The MOI wrapper is directly defining:
function MOI.add_constraint(o::Optimizer, func::SVF, set::S) where {S <: VAR_TYPES}
using the low-level SCIP generated API, we should have an intermediate function in managed_scip.jl

When you compile SCIP with Ipopt, the build fails because CSIP doesn't express its dependency on Ipopt correctly:

$ ldd -r libcsip.so 

linux-vdso.so.1 =>  (0x00007ffd287f3000)

libscipopt.so => /home/ubuntu/.julia/v0.5/SCIP/deps/src/CSIP-0.3.5/lib/libscipopt.so (0x00007f30414f2000)

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f304112d000)

libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3040e29000)

libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3040b23000)

libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f304090d000)

/lib64/ld-linux-x86-64.so.2 (0x00007f30420e7000)

undefined symbol: _ZTIN5Ipopt7JournalE  (/home/ubuntu/.julia/v0.5/SCIP/deps/src/CSIP-0.3.5/lib/libscipopt.so)

undefined symbol: _ZN5Ipopt7Journal4NameEv  (/home/ubuntu/.julia/v0.5/SCIP/deps/src/CSIP-0.3.5/lib/libscipopt.so)

undefined symbol: _ZN5Ipopt7Journal13SetPrintLevelENS_16EJournalCategoryENS_13EJournalLevelE(/home/ubuntu/.julia/v0.5/SCIP/deps/src/CSIP-0.3.5/lib/libscipopt.so)

undefined symbol: _ZN5Ipopt7Journal17SetAllPrintLevelsENS_13EJournalLevelE  (/home/ubuntu/.julia/v0.5/SCIP/deps/src/CSIP-0.3.5/lib/libscipopt.so)

undefined symbol: _ZNK5Ipopt7Journal10IsAcceptedENS_16EJournalCategoryENS_13EJournalLevelE  (/home/ubuntu/.julia/v0.5/SCIP/deps/src/CSIP-0.3.5/lib/libscipopt.so)

undefined symbol: _ZTIN5Ipopt11TNLPAdapterE (/home/ubuntu/.julia/v0.5/SCIP/deps/src/CSIP-0.3.5/lib/libscipopt.so)

undefined symbol: _ZTIN5Ipopt12OrigIpoptNLPE    (/home/ubuntu/.julia/v0.5/SCIP/deps/src/CSIP-0.3.5/lib/libscipopt.so)

undefined symbol: _ZN5Ipopt11TNLPAdapter7ResortXERKNS_6VectorEPd    (/home/ubuntu/.julia/v0.5/SCIP/deps/src/CSIP-0.3.5/lib/libscipopt.so)

undefined symbol: _ZN5Ipopt7JournalD2Ev (/home/ubuntu/.julia/v0.5/SCIP/deps/src/CSIP-0.3.5/lib/libscipopt.so)

undefined symbol: _ZN5Ipopt14IpLapackDgetrfEiPdPiiRi    (/home/ubuntu/.julia/v0.5/SCIP/deps/src/CSIP-0.3.5/lib/libscipopt.so)

undefined symbol: _ZN5Ipopt11TNLPAdapter7ResortGERKNS_6VectorES3_Pd (/home/ubuntu/.julia/v0.5/SCIP/deps/src/CSIP-0.3.5/lib/libscipopt.so)

undefined symbol: _ZN5Ipopt14IpLapackDgetrsEiiPKdiPiPdi (/home/ubuntu/.julia/v0.5/SCIP/deps/src/CSIP-0.3.5/lib/libscipopt.so)

undefined symbol: _ZN5Ipopt16IpoptApplicationC1Ebb  (/home/ubuntu/.julia/v0.5/SCIP/deps/src/CSIP-0.3.5/lib/libscipopt.so)

undefined symbol: _ZN5Ipopt13IpLapackDsyevEbiPdiS0_Ri   (/home/ubuntu/.julia/v0.5/SCIP/deps/src/CSIP-0.3.5/lib/libscipopt.so)

undefined symbol: _ZN5Ipopt7JournalC2ERKSsNS_13EJournalLevelE   (/home/ubuntu/.julia/v0.5/SCIP/deps/src/CSIP-0.3.5/lib/libscipopt.so)

undefined symbol: _ZN5Ipopt11TNLPAdapter10ResortBndsERKNS_6VectorEPdS3_S4_  (/home/ubuntu/.julia/v0.5/SCIP/deps/src/CSIP-0.3.5/lib/libscipopt.so)

CC @chriscoey

It should not be so difficult for SCIP itself, but requires a rethinking of how we decide on variable and constraint indices, as well as additional mapping structures that might become necessary.

SCIP actually supports users submitting multipe (partial) solution candidates, but I guess it would be enough to allow for a single one, through MOI.

Hi,

I am solving QCQP. I find that if I model quadratic constraints and objective using @constraint and @objective, and then SCIP returns wrong answer. Instead, is I models using @NLconstraint and @NLobjective, SCIP gives the correct answer? Why is it?

Hi,

I find a quite wield thing. If I change CSIP_VERSION from 0.4.0 to 0.3.6, SCIP is much faster.
To do that I also need to change line 1484 in csip.c
from SCIP_in_CSIP(SCIPtrySolFree(scip, &sol, FALSE, TRUE, TRUE, TRUE, &stored));
to SCIP_in_CSIP(SCIPtrySolFree(scip, &sol, FALSE, FALSE, TRUE, TRUE, TRUE, &stored));

However, after the change, csip.c in version 0.3.6 is almost the same as csip.c in 0.4.0. But the performance is very different. I guess the dependence of two versions are different.

Here is test code

using JuMP, SCIP
function test(iter)
for i = 1:iter
m= Model()
nvar = 1000
@variable(m, 0<=x[1:nvar]<=1)
@constraint(m, con[i in 1:(nvar-2)], x[i]+x[i+1]<=1)
@objective(m, :Min, sum{(x[i]+x[i+2])^2, i in 1:(nvar-2)})
m.solver=SCIPSolver("display/verblevel", 0)
solve(m)
end
end
test(10)

on my computer, version 0.3.6 takes 15seconds, while version 0.4.0 takes 80 seconds. This is not the old problem I tested, the difference in solution time can be even ten times for many problems I solved.

Hi,

I have installed the academic licence of SCIP but I had no success to use it in Julia/Atom in Windows OS.

I tried with AmplNLWriter, but even so nothing... It seems the binary scipampl is not supported in Windows...

The SCIPOptSuite 5.0.1 is supported on Julia 0.6.2.1 ?

Thanks in advance.

See Clp.jl/#17.

Currently (after merging #76), setting MOI.FEASIBILITY_SENSE is a no-op.
We coud clear the objective coefficients of all variables, but then they could not be recovered when the objective sense is set to maximize or minimize.

To support this properly, we would have to store both the sense and the objective coefficients separately in the MOI wrapper (SCIP.Optimizer).

Consider the following:

using JuMP
using SCIP
using LinearAlgebra
m = Model(with_optimizer(SCIP.Optimizer))
@variable m x[1 : 3]
@variable m y[1 : 3]
@variable m z[1 : 3]
w = x × y - x × z
@constraint m w .== 1
optimize!(m)

SCIP reports that the problem is solved, but value.(w) results in

3-element Array{Float64,1}:
 1.9999999962747097
 1.9999999925494194
 1.9999999962747097

i.e., twice what it should be.

So I'm starting to run some experiments using SCIP, and I'm going to begin complaining about the missing methods that I need to get things working. First one is getsolvetime.

Since SCIP support for plugins (callbacks) is more general that what is available in other MIP solvers, it makes sense to offer a thin layer around the SCIP style of them, for example:

• constraint handlers (lazy constraints)
• heuristics (based on LP solutions, but also from scratch type heuristics, or improving heuristics)
• relaxations (instead of, or in addition to LP)
• branching rules
• node selection rules

If/when a callback interface is established for MOI, this layer could be used then.

It would be great to have support for SCIP-SDP available in SCIP.jl (and through the MathProgBase interface as well). Do you have an estimate how difficult this might be?

And how they match up with the SCIP documentation

It's okay not having an automatic build, but we should at least have some instructions in the README to get people started.

INFO: Building SCIP
==============================================================[ ERROR: SCIP ]==============================================================
LoadError: None of the selected providers can install dependency libcsip.
Use BinDeps.debug(package_name) to see available providers

while loading C:\Users\shara.julia\v0.6\SCIP\deps\build.jl, in expression starting on line 52

===========================================================================================================================================
=============================================================[ BUILD ERRORS ]==============================================================
WARNING: SCIP had build errors.

• packages with build errors remain installed in C:\Users\shara.julia\v0.6
• build the package(s) and all dependencies with Pkg.build("SCIP")
• build a single package by running its deps/build.jl script

===========================================================================================================================================

Since there have been no changes from MPB to MOI (?) this might be comparatively easy, since we could look at CSIP for inspiration.

But if that interface is subject to change in MOI, we might also wait and do it later.

Currently, we have

https://github.com/SCIP-Interfaces/SCIP.jl/blob/7a5095fdbc10c4ccfd20d2a73f6df85015ce2ffc/src/MOI_wrapper/results.jl#L46

which is called in e.g.

https://github.com/SCIP-Interfaces/SCIP.jl/blob/7a5095fdbc10c4ccfd20d2a73f6df85015ce2ffc/src/MOI_wrapper/results.jl#L51-L54

However, SCIPgetBestSol allows SCIP to be in many more stages. Should the assert_solved check be changed to something less conservative? I'd change this straight away, but I'm not sure what requirements should be satisfied on the MathOptInterface side.

I ran into this when I tried to solve with a time limit; even though SCIP found a feasible point, the stage was still SOLVING, so I couldn't get the results.

In MathProgBase and JuMP there's a distinction between solvers for LinearQuadratic vs Nonlinear (expression-based) problems. According to the documentation, the callbacks are supported only for MIP solvers (i.e., LinearQuadratic).

For SCIP, this distinction is artificial. We initially implemented the wrapper with a focus on the LinearQuadratic interface, later adding support for the Nonlinear.

Unfortunately, when building a model using @NLconstraint, adding callback functions does not have an effect with SCIP.jl currently (see example).

@mlubin: Is this a restriction inherent in JuMP or MathProgBase? Can we work around this with little effort?

@fserra: I'm confused by the implementation of Nonlinear in SCIP.jl, in particular this code:

type SCIPMathProgModel <: AbstractLinearQuadraticModel
[...]
end

type SCIPNonlinearModel <: AbstractNonlinearModel
    m::SCIPMathProgModel
end

LinearQuadraticModel(s::SCIPSolver) = SCIPMathProgModel(s.options)
NonlinearModel(s::SCIPSolver) = SCIPMathProgModel(s.options)

The type SCIPNonlinearModel is never again used in the code. Might there be a related issue here?

This applies only after #76 is merged.

We now use Clang.jl to generate Julia wrappers from the SCIP header files automatically.
There is a script for that purpose that should be rerun for every (major) release of SCIP that we want to support.

Unfortunately, the process was not completely automatic. The steps should be documented clearly, or integrated properly in the generator script.

In particular, the following steps followed the execution of the script:

• rename Ptr{SCIP} to Ptr{SCIP_}, to avoid name conflict with module.
• delete empty wrappers for type_*.h; the type definitions all went to commons.jl
• add some missing (type/enum) definitions to manual_commons.jl (why did Clang.jl not add them?)

Also, we used the branch of Clang.jl from PR #210, which was now merged to master, but not yet tagged?

Hi,
Could anybody describe me how I can add "SCIP" solver to the Julia in very simple words. I have just started working with Julia and README file description seems too complicated to me.
Thanks.

Using SCIPSolver("limits/gap",1e-5) leads to

ERROR: LoadError: MethodError: `convert` has no method matching convert(::Type{Ptr{Void}}, ::Float64)
This may have arisen from a call to the constructor Ptr{Void}(...),
since type constructors fall back to convert methods.
Closest candidates are:
  call{T}(::Type{T}, ::Any)
  convert{T}(::Type{Ptr{T}}, !Matched::UInt64)
  convert{T}(::Type{Ptr{T}}, !Matched::Int64)
  ...
 in setparams! at /home/mlubin/.julia/v0.4/SCIP/src/params.jl:13

Is this the correct usage? Why do you need to convert a Float64 to a void*?

Now that we have a working version and a better understanding of both Julia and the conceptual gap between SCIP and MathProgBase, we could build a more direct wrapper, skipping CSIP entirely.

We could also (in the same step) provide a Julia wrapper for the "raw" SCIP function(alitie)s, on which the MPB interface implementation is based. This would enable users to easily use the more advanced features directly, that is, without need for :ccall. It is unclear to what extent the public functions of SCIP should be made available, since the large number of these suggests a semi-automatic way of generating the wrappers.

CC: @fserra

One gets a nasty segfault without any helpful information (from SCIP nor Julia) when getting variables without having optimized.

MWE: https://github.com/SCIP-Interfaces/SCIP.jl/blob/090911ee1c5a2306272025129f1da5fc13f0c10d/test/MOI_additional.jl#L403

If line MOI.optimize! is removed