I could, but i would need to attach a function i made and some data i wrote in a .txt file too, so you could run the code. Anyway this can be done here?
Btw, the CouenneNLSolver is already updated to work in Julia 1.0.1? I remember it only used to work in Julia 0.6.
I’m using https://github.com/rdeits/CouenneNL.jl instead, which is just a thin wrapper around AmplNLWriter, doesn’t require you to build from source, and has been updated for 1.0.
1e+050 best solution really means that no feasible point has been found (there is no incumbent). best possible 2 means that a lower bound on the objective value of 2 has been established by the solver (which does not necessarily require finding a feasible point).
Feasibility does not depend on the objective function, so if you’re getting infeasible back for one objective function there’s no sense in trying a different one.
Try removing some constraints and see which ones cause the problem to become infeasible. You also might want to try reducing the size of your problem as you’re debugging the formulation.
Allright, thanks for the info! I’ll try to reduce the size of my problem to see if i can get it to work!
EDIT: Trying to install that to use in Julia 1.0.1, but i keep getting this error:
julia> Pkg.add("CouenneNL")
WARNING: Base.Pkg is deprecated, run `using Pkg` instead
in module Main
Updating registry at `C:\Users\Muril\.julia\registries\General`
Updating git-repo `https://github.com/JuliaRegistries/General.git`
ERROR: The following package names could not be resolved:
* CouenneNL (not found in project, manifest or registry)
Please specify by known `name=uuid`.
Stacktrace:
[1] pkgerror(::String) at C:\cygwin\home\Administrator\buildbot\worker\package_win64\build\usr\shar
e\julia\stdlib\v0.7\Pkg\src\Types.jl:120
[2] #ensure_resolved#42(::Bool, ::Function, ::Pkg.Types.EnvCache, ::Array{Pkg.Types.PackageSpec,1})
at C:\cygwin\home\Administrator\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v0.7\Pkg
\src\Types.jl:890
[3] #ensure_resolved at .\none:0 [inlined]
[4] #add_or_develop#13(::Symbol, ::Bool, ::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{
(),Tuple{}}}, ::Function, ::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at C:\cygwin\home\A
dministrator\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v0.7\Pkg\src\API.jl:59
[5] #add_or_develop at .\none:0 [inlined]
[6] #add_or_develop#12 at C:\cygwin\home\Administrator\buildbot\worker\package_win64\build\usr\shar
e\julia\stdlib\v0.7\Pkg\src\API.jl:29 [inlined]
[7] #add_or_develop at .\none:0 [inlined]
[8] #add_or_develop#11(::Base.Iterators.Pairs{Symbol,Symbol,Tuple{Symbol},NamedTuple{(:mode,),Tuple
{Symbol}}}, ::Function, ::Array{String,1}) at C:\cygwin\home\Administrator\buildbot\worker\package_w
in64\build\usr\share\julia\stdlib\v0.7\Pkg\src\API.jl:28
[9] add(::String) at .\none:0
[10] top-level scope at none:0
Hello, i have reduced the size of my problem, and i finally got an answer (not a right answer, but i know why its wrong, and i’m trying to fix that). But it only works with these values:
I understand if i reduce the value of hsmax, i’m reducing the search space of my problem, and could make it infeasible (but from my experience, it shouldnt be infeasible anyway). I tried increasing it, and it gave me an infeasible result too.
hsmax can only accept odd values here, i tried from 5, 7, ..., 25, 27, 29. And it only works if i use 23.
Is there anyway i can stop Couenne and get in return the integer solution it found so far?
Since it started to get close to this solution, is starting to take so long to finish. For example, i got this:
Cbc0010I After 95800 nodes, 5974 on tree, 4.1972143 best solution, best possible 4.0000773 (5266.99
seconds)
and after a long time running…
Cbc0010I After 223400 nodes, 10717 on tree, 4.1972143 best solution, best possible 4.062431 (9952.79
seconds)
I was thinking something like, if the integer solution found differs, say x%, from the best possible, i want to stop it and get the results. Or maybe a time limit after it has found an integer solution.
Trying to use Couenne in Julia 1.0, and i’m getting this error:
[ Info: Precompiling CouenneNL [5724587f-3074-5673-b62c-b97e3475008a]
ERROR: LoadError: syntax: extra token "MathProgBase" after end of expression
Stacktrace:
[1] include at .\boot.jl:317 [inlined]
[2] include_relative(::Module, ::String) at .\loading.jl:1041
[3] include(::Module, ::String) at .\sysimg.jl:29
[4] top-level scope at none:2
[5] eval at .\boot.jl:319 [inlined]
[6] eval(::Expr) at .\client.jl:389
[7] top-level scope at .\none:3
in expression starting at C:\Users\Muril\.julia\dev\CouenneNL\src\CouenneNL.jl:11
ERROR: LoadError: Failed to precompile CouenneNL [5724587f-3074-5673-b62c-b97e3475008a] to C:\Users\
Muril\.julia\compiled\v1.0\CouenneNL\3v98H.ji.
Stacktrace:
[1] error(::String) at .\error.jl:33
[2] macro expansion at .\logging.jl:313 [inlined]
[3] compilecache(::Base.PkgId, ::String) at .\loading.jl:1187
[4] macro expansion at .\logging.jl:311 [inlined]
[5] _require(::Base.PkgId) at .\loading.jl:944
[6] require(::Base.PkgId) at .\loading.jl:855
[7] macro expansion at .\logging.jl:311 [inlined]
[8] require(::Module, ::Symbol) at .\loading.jl:837
[9] include_string(::Module, ::String, ::String) at .\loading.jl:1005
[10] (::getfield(Atom, Symbol("##123#127")){String,String,Module})() at C:\Users\Muril\.julia\packa
ges\Atom\Fha1N\src\eval.jl:120
[11] withpath(::getfield(Atom, Symbol("##123#127")){String,String,Module}, ::String) at C:\Users\Mu
ril\.julia\packages\CodeTools\hB4Hy\src\utils.jl:30
[12] withpath at C:\Users\Muril\.julia\packages\Atom\Fha1N\src\eval.jl:46 [inlined]
[13] #122 at C:\Users\Muril\.julia\packages\Atom\Fha1N\src\eval.jl:117 [inlined]
[14] hideprompt(::getfield(Atom, Symbol("##122#126")){String,String,Module}) at C:\Users\Muril\.jul
ia\packages\Atom\Fha1N\src\repl.jl:84
[15] macro expansion at C:\Users\Muril\.julia\packages\Atom\Fha1N\src\eval.jl:116 [inlined]
[16] macro expansion at C:\Users\Muril\.julia\packages\Media\ItEPc\src\dynamic.jl:24 [inlined]
[17] (::getfield(Atom, Symbol("##121#125")))(::Dict{String,Any}) at C:\Users\Muril\.julia\packages\
Atom\Fha1N\src\eval.jl:105
[18] handlemsg(::Dict{String,Any}, ::Dict{String,Any}) at C:\Users\Muril\.julia\packages\Atom\Fha1N
\src\comm.jl:168
[19] (::getfield(Atom, Symbol("##22#25")){Array{Any,1}})() at .\task.jl:259
in expression starting at C:\Users\Muril\Desktop\Murilo\UFPE\Dissertação\Julia\Arquivos Feitos 1.0.1
\otimização_sistema_4_barras.jl:1
(v1.0) pkg> up Couenne
Updating registry at `C:\Users\Muril\.julia\registries\General`
Updating git-repo `https://github.com/JuliaRegistries/General.git`
ERROR: The following package names could not be resolved:
* Couenne (not found in project or manifest)
Please specify by known `name=uuid`.
I just followed the instructions in that link you provided (wich worked for Julia 0.6.3):
Hmm, weird. Not sure. The q seems like it is an error in your code. Close Julia, open a new REPL, and then check that using CouenneNL works without error.
Well, i just went back to 0.6.3, couldn’t make it work in 1.0. I’ll try again later when i have more free time.
I got a question about Couenne again… is there any chance the optimal solution it found, isn’t really the best solution at all? I ask this, because, in my problem, i know there is a better solution than the one Couenne is giving me. Has anyone experienced this kind of issue?
Theoretically, no. In practice, there may be numerical issues that e.g. cause one of the lower-bound LPs to falsely claim infeasibility, causing the BnB algorithm to wrongly eliminate a part of the search space. Also, be sure to check that it’s not just due to the optimality gap tolerance you’re using.
Regarding the number of variables (continuos and/or integers) and constraints, is there any consensus if using a BnB algorithm to solve a MINLP is viable or not?
For example, i’m solving a problem that has around 7700 variables (wich of 12 are integers) and 7700 constraints. Depeding on some parameters i use, it takes between 2h and 6h to solve this problem. But, i’ll need to test my code in another similar problem wich has much more variables and constraints, and if Couenne can solve that, i’m afraid it will take days. So, i’m not sure if BnB is the best (or even acceptable) approach here…
Hmm, that’s not very user-friendly right now. The couenne.opt file needs to be in the same directory as the .nl file that’s passed to the couenne executable. But the .nl file is generated in a different directory, namely in AmplNLWriter.solverdata_dir (CouenneNL is just a thin wrapper around AmplNLWriter). So I think if you put your couenne.opt file there it should work. Improving this situation, e.g. by making it so that you can directly specify in which directory AmplNLWriter generates the .nl file, could be a good contribution to the AmplNLWriter package.
Yes. I just put the “couenne.opt” file in the same folder as the files i’m running, it worked. Couenne stoped using those bound tightening options and exited earlier because of the gap i put in there (it even shows a message saying that).