Comments (30)
from ipopt.jl.
I guess we needed a sparse linear algebra library. It should work now if you wipe deps/usr
and deps/src
and rebuild.
from ipopt.jl.
Cool, now it just segfaults - progress!
from ipopt.jl.
@IainNZ how did you end up fixing this? I'm havingthe same problem. What deps
folder did you wipe?
from ipopt.jl.
I guess it was the deps/usr
folder you get after Pkg.build
from ipopt.jl.
@joehuchette: you'll definitely need gfortran installed to compile Ipopt with its dependencies
from ipopt.jl.
Yeah I do, looks like it's an issue with the Homebrew version of Ipopt, not with Julia
from ipopt.jl.
The default setup from brew install ipopt
(at least from homebrew-science, you guys might have a separate version in juliadeps in which case ignore this) builds Mumps using MPI, which you usually don't want to do with the normal release version of Ipopt. Try brew install ipopt --without-mpi
, if you're getting it from homebrew-science.
Okay now I see staticfloat/homebrew-juliadeps#9 - you'll want to bump Ipopt to 3.11.7 like Miles just did for Linux, there were bug fixes for Mavericks due to the clang C++ standard library change that aren't in 3.11.5.
from ipopt.jl.
That's good to know, but something else seems to be causing a segfault. Looks like an OpenBLAS issue
from ipopt.jl.
Can you run Ipopt's test examples outside of Julia? If it's only segfaulting when running from Julia, then this is probably related to issues that I've debugged to death with the Matlab interface to Ipopt. Matlab (and presumably Julia too when you're using OpenBlas) uses ILP64 BLAS on 64-bit machines. Ipopt and most system BLAS libraries are LP64. If Julia's BLAS and the Ipopt library are both loaded into the same address space, there can be some cross-talk and bad things can happen when integers are the wrong size. Can you post some of what the segfault's outputting, as much of a backtrace as you can get?
If this is what's happening, then it might be easier to statically link the reference BLAS (or some other static-lib LP64 BLAS, ATLAS might work too?) into the Ipopt shared library and live with the slight performance loss compared to OpenBlas. That's what I did with the Ipopt Matlab interface, and for sparse problems the choice of BLAS isn't that big a deal. The multifrontal block reductions in Mumps/MA57 are rarely big enough for OpenBlas to outperform Netlib by enough of a margin to be worth the hassle of messing with Julia/OpenBlas compilation options likeUSE_BLAS64
.
from ipopt.jl.
make test
works fine outside Julia, so you may be on to something. I get
>> lldb -- julia runtests.jl
Current executable set to 'julia' (x86_64).
(lldb) r
Process 50391 launched: '/usr/local/julia/julia' (x86_64)
******************************************************************************
This program contains Ipopt, a library for large-scale nonlinear optimization.
Ipopt is released as open source code under the Eclipse Public License (EPL).
For more information visit http://projects.coin-or.org/Ipopt
******************************************************************************
NOTE: You are using Ipopt by default with the MUMPS linear solver.
Other linear solvers might be more efficient (see Ipopt documentation).
This is Ipopt version 3.11.4, running with linear solver mumps.
Number of nonzeros in equality constraint Jacobian...: 4
Number of nonzeros in inequality constraint Jacobian.: 4
Number of nonzeros in Lagrangian Hessian.............: 10
Process 50391 stopped
* thread #1: tid = 0x3791bd, 0x0000000105a60617 libopenblas.dylib`.L41 + 7, queue = 'com.apple.main-thread', stop reason = signal SIGSEGV
frame #0: 0x0000000105a60617 libopenblas.dylib`.L41 + 7
libopenblas.dylib`.L41 + 7:
-> 0x105a60617: movhps (%rsi), %xmm0
0x105a6061a: addq %rdx, %rsi
0x105a6061d: movsd (%rsi), %xmm1
0x105a60621: addq %rdx, %rsi
(lldb) bt
* thread #1: tid = 0x3791bd, 0x0000000105a60617 libopenblas.dylib`.L41 + 7, queue = 'com.apple.main-thread', stop reason = signal SIGSEGV
* frame #0: 0x0000000105a60617 libopenblas.dylib`.L41 + 7
frame #1: 0x000000010abf8de2 libipopt.dylib`Ipopt::IpBlasDcopy(int, double const*, int, double*, int) + 82
frame #2: 0x000000010aa2e32b libipopt.dylib`Ipopt::TNLPAdapter::GetStartingPoint(this=0x0000000101681b60, x=<unavailable>, need_x=true, y_c=<unavailable>, need_y_c=false, y_d=<unavailable>, need_y_d=false, z_L=<unavailable>, need_z_L=false, z_U=<unavailable>, need_z_U=false) + 1035 at IpTNLPAdapter.cpp:1488
frame #3: 0x000000010aab25f9 libipopt.dylib`Ipopt::GradientScaling::DetermineScalingParametersImpl(Ipopt::SmartPtr<Ipopt::VectorSpace const>, Ipopt::SmartPtr<Ipopt::VectorSpace const>, Ipopt::SmartPtr<Ipopt::VectorSpace const>, Ipopt::SmartPtr<Ipopt::MatrixSpace const>, Ipopt::SmartPtr<Ipopt::MatrixSpace const>, Ipopt::SmartPtr<Ipopt::SymMatrixSpace const>, Ipopt::Matrix const&, Ipopt::Vector const&, Ipopt::Matrix const&, Ipopt::Vector const&, double&, Ipopt::SmartPtr<Ipopt::Vector>&, Ipopt::SmartPtr<Ipopt::Vector>&, Ipopt::SmartPtr<Ipopt::Vector>&) + 473
frame #4: 0x000000010ab18849 libipopt.dylib`Ipopt::StandardScalingBase::DetermineScaling(Ipopt::SmartPtr<Ipopt::VectorSpace const>, Ipopt::SmartPtr<Ipopt::VectorSpace const>, Ipopt::SmartPtr<Ipopt::VectorSpace const>, Ipopt::SmartPtr<Ipopt::MatrixSpace const>, Ipopt::SmartPtr<Ipopt::MatrixSpace const>, Ipopt::SmartPtr<Ipopt::SymMatrixSpace const>, Ipopt::SmartPtr<Ipopt::MatrixSpace const>&, Ipopt::SmartPtr<Ipopt::MatrixSpace const>&, Ipopt::SmartPtr<Ipopt::SymMatrixSpace const>&, Ipopt::Matrix const&, Ipopt::Vector const&, Ipopt::Matrix const&, Ipopt::Vector const&) + 521
frame #5: 0x000000010ab27ef8 libipopt.dylib`Ipopt::OrigIpoptNLP::InitializeStructures(Ipopt::SmartPtr<Ipopt::Vector>&, bool, Ipopt::SmartPtr<Ipopt::Vector>&, bool, Ipopt::SmartPtr<Ipopt::Vector>&, bool, Ipopt::SmartPtr<Ipopt::Vector>&, bool, Ipopt::SmartPtr<Ipopt::Vector>&, bool, Ipopt::SmartPtr<Ipopt::Vector>&, Ipopt::SmartPtr<Ipopt::Vector>&) + 4264
frame #6: 0x000000010aaf4400 libipopt.dylib`Ipopt::IpoptData::InitializeDataStructures(Ipopt::IpoptNLP&, bool, bool, bool, bool, bool) + 352
frame #7: 0x000000010aa94e99 libipopt.dylib`Ipopt::DefaultIterateInitializer::SetInitialIterates() + 185
frame #8: 0x000000010aabcf9c libipopt.dylib`Ipopt::IpoptAlgorithm::InitializeIterates() + 60
frame #9: 0x000000010aabb3a5 libipopt.dylib`Ipopt::IpoptAlgorithm::Optimize(bool) + 613
frame #10: 0x000000010aa01d40 libipopt.dylib`Ipopt::IpoptApplication::call_optimize(this=0x000000010af047c0) + 4464 at IpIpoptApplication.cpp:857
frame #11: 0x000000010aa0046d libipopt.dylib`Ipopt::IpoptApplication::OptimizeNLP(this=0x000000010af047c0, nlp=0x000000010af04810, alg_builder=0x00007fff5fbfdc98) + 1453 at IpIpoptApplication.cpp:751
frame #12: 0x000000010a9ffe6b libipopt.dylib`Ipopt::IpoptApplication::OptimizeNLP(this=0x000000010af047c0, nlp=0x000000010af04810) + 91 at IpIpoptApplication.cpp:714
frame #13: 0x000000010a9ff6c4 libipopt.dylib`Ipopt::IpoptApplication::OptimizeTNLP(this=0x000000010af047c0, tnlp=0x00007fff5fbfdf78) + 228 at IpIpoptApplication.cpp:693
frame #14: 0x000000010aa09ef7 libipopt.dylib`IpoptSolve(ipopt_problem=0x000000010af05370, x=0x000000010c8c62d0, g=0x000000010b208fb0, obj_val=0x0000000102572ff0, mult_g=0x0000000000000000, mult_x_L=0x0000000000000000, mult_x_U=0x0000000000000000, user_data=0x00000001024bb500) + 1703 at IpStdCInterface.cpp:270
frame #15: 0x000000010107d723
frame #16: 0x000000010107d5f3
frame #17: 0x000000010005b075 libjulia.dylib`jl_apply_generic + 229
frame #18: 0x00000001000993c1 libjulia.dylib`do_call + 209
frame #19: 0x0000000100097e96 libjulia.dylib`eval + 694
frame #20: 0x00000001000980ed libjulia.dylib`eval + 1293
frame #21: 0x00000001000990fb libjulia.dylib`eval_body + 635
frame #22: 0x00000001000992a2 libjulia.dylib`jl_interpret_toplevel_thunk_with + 274
frame #23: 0x00000001000a5e43 libjulia.dylib`jl_toplevel_eval_flex + 1347
frame #24: 0x00000001000a63a4 libjulia.dylib`jl_parse_eval_all + 276
frame #25: 0x00000001000a658f libjulia.dylib`jl_load + 127
frame #26: 0x000000010336ec6b sys.dylib`julia_include1851 - 18446744069360653204
frame #27: 0x00000001034b62fb sys.dylib`julia_include_from_node115026 - 18446744069359312132
frame #28: 0x000000010005b075 libjulia.dylib`jl_apply_generic + 229
frame #29: 0x00000001000993c1 libjulia.dylib`do_call + 209
frame #30: 0x0000000100097e96 libjulia.dylib`eval + 694
frame #31: 0x00000001000a5dd2 libjulia.dylib`jl_toplevel_eval_flex + 1234
frame #32: 0x00000001000a63a4 libjulia.dylib`jl_parse_eval_all + 276
frame #33: 0x00000001000a658f libjulia.dylib`jl_load + 127
frame #34: 0x000000010336ec6b sys.dylib`julia_include1851 - 18446744069360653204
frame #35: 0x0000000101069632
frame #36: 0x000000010005b075 libjulia.dylib`jl_apply_generic + 229
from ipopt.jl.
@tkelman: that's a good point. Perhaps we can make a configure flag for Ipopt to use ILP64 for blas/lapack.
from ipopt.jl.
@joehuchette Yep, exactly what I thought it was. See https://projects.coin-or.org/Ipopt/browser/releases/3.11.4/Ipopt/src/LinAlg/IpBlas.cpp#L111 for definition of IpBlasDcopy
. Ipopt on a Mac will use framework vecLib for Blas and Lapack if you don't tell it otherwise, I'm guessing you didn't specifically ask Ipopt to use OpenBlas here?
@mlubin Yes we should look into this, but I don't think it will be an easy change. It would take quite a bit of digging to find everywhere that ipfint
is being used interchangeably with int
or Index
without typecasting. There's a FIXME about it here: https://projects.coin-or.org/Ipopt/browser/releases/3.11.4/Ipopt/configure.ac#L433, but currently it's just hardcoded to int
- https://projects.coin-or.org/Ipopt/browser/releases/3.11.4/Ipopt/src/Common/IpTypes.hpp#L26. All the sparse solvers and user interfaces are also currently using int
, it could get messy very quickly.
I don't think anyone has tried hacking at this one, at least not AFAIK. The easiest solution is statically linking BLAS and LAPACK into the Ipopt shared library, but for obvious reasons that's not good enough to be a permanent fix.
from ipopt.jl.
With @joehuchette here. Ipopt depends on vecLib, not openblas, so I'm not sure why openblas is being called. How do you go about statically linking the reference blas?
from ipopt.jl.
I'm not sure why openblas is being called
Name shadowing on dcopy_
etc.
How do you go about statically linking the reference blas?
Easiest way is configuring Ipopt --with-blas=BUILD --with-lapack=BUILD --disable-shared
but then you won't get a shared Ipopt library which Julia needs.
To get a shared Ipopt library statically linked to reference blas, try something like
for i in Blas Lapack; do
cd ThirdParty/$i
./get.$i
./configure --disable-shared --with-pic --prefix=$prefix
make install
cd ../..
done
./configure --with-blas="-L$prefix/lib -lcoinblas" \
--with-lapack="-L$prefix/lib -lcoinlapack" \
--prefix=$prefix --enable-dependency-linking
make install
from ipopt.jl.
Should add a test that uses hessian_approximation = limited-memory
for good measure, as that will call Lapack.
from ipopt.jl.
Hmm I tried this, and it still chokes on an openblas call.
from ipopt.jl.
What do ldd libipopt.so
or otool -L libipopt.dylib
say?
from ipopt.jl.
>> otool -L libipopt.dylib
libipopt.dylib:
/Users/huchette/.julia/v0.3/Ipopt/deps/usr/lib/libipopt.1.dylib (compatibility version 11.0.0, current version 11.4.0)
/Users/huchette/.julia/v0.3/Ipopt/deps/usr/lib/libcoinmumps.1.dylib (compatibility version 6.0.0, current version 6.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0)
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/Users/huchette/.julia/v0.3/Ipopt/deps/usr/lib/libcoinlapack.1.dylib (compatibility version 6.0.0, current version 6.6.0)
/Users/huchette/.julia/v0.3/Ipopt/deps/usr/lib/libcoinblas.1.dylib (compatibility version 5.0.0, current version 5.6.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0
from ipopt.jl.
Can you clear out /Users/huchette/.julia/v0.3/Ipopt/deps/usr/lib
, re-run the make for ThirdParty/Blas and ThirdParty/Lapack outputting to a log file, and gist the logs, along with ThirdParty/Blas/config.log and ThirdParty/Lapack/config.log?
from ipopt.jl.
Here you go:
https://gist.github.com/joehuchette/2e5d7ea0bcc0a450ea70
Thanks for helping to debug, BTW.
from ipopt.jl.
It's reusing libtool from the (previous) Ipopt configure when building Blas and Lapack, so not obeying --disable-shared
properly. First, delete libtool from the top-level Ipopt directory. Get rid of as much as you can from past builds, preferably start from a clean source tree (plus ./get.Mumps
). I try to avoid in-source builds for this very reason.
Just to be sure, let's use a separate build folder, and also be a little more explicit about wanting static libs:
for i in Blas Lapack; do
cd ThirdParty/$i
./get.$i
mkdir -p build
cd build
../configure --disable-shared --enable-static --with-pic --prefix=$prefix
make install
cd ../../..
done
mkdir -p build
cd build
../configure --with-blas=$prefix/lib/libcoinblas.a \
--with-lapack=$prefix/lib/libcoinlapack.a \
--prefix=$prefix --enable-dependency-linking
make install
Then let me know what otool -L libipopt.dylib
says again.
And ls /Users/huchette/.julia/v0.3/Ipopt/deps/usr/lib
from ipopt.jl.
I run
prefix=/Users/huchette/.julia/v0.3/Ipopt/deps/usr
cd ThirdParty/Mumps
./get.Mumps
mkdir -p build
cd build
../configure --prefix=$prefix --disable-shared --enable-static --without-lapack --without-mpi
make install
cd ../..
for i in Blas Lapack; do
cd $i
./get.$i
mkdir -p build
cd build
../configure --disable-shared --enable-static --with-pic --without-mpi --prefix=$prefix
make install
cd ../..
done
cd ..
mkdir -p build
cd build
../configure --with-blas=$prefix/lib/libcoinblas.a \
--with-lapack=$prefix/lib/libcoinlapack.a \
--prefix=$prefix --enable-dependency-linking --without-mpi
make install
and get
>> otool -L libipopt.dylib
libipopt.dylib:
/Users/huchette/.julia/v0.3/Ipopt/deps/usr/lib/libipopt.1.dylib (compatibility version 11.0.0, current version 11.4.0)
/Users/huchette/.julia/v0.3/Ipopt/deps/usr/lib/libcoinmumps.1.dylib (compatibility version 6.0.0, current version 6.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0)
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
>> ls -l /Users/huchette/.julia/v0.3/Ipopt/deps/usr/lib
total 14152
-rw-r--r-- 1 huchette staff 196512 Mar 15 00:18 libcoinblas.a
-rwxr-xr-x 1 huchette staff 784 Mar 15 00:18 libcoinblas.la
-rw-r--r-- 1 huchette staff 737872 Mar 15 00:19 libcoinlapack.a
-rwxr-xr-x 1 huchette staff 790 Mar 15 00:19 libcoinlapack.la
-rwxr-xr-x 1 huchette staff 1714352 Mar 15 00:21 libcoinmumps.1.4.9.dylib
lrwxr-xr-x 1 huchette staff 24 Mar 15 00:21 libcoinmumps.1.dylib -> libcoinmumps.1.4.9.dylib
-rw-r--r-- 1 huchette staff 1964160 Mar 15 00:17 libcoinmumps.a
lrwxr-xr-x 1 huchette staff 24 Mar 15 00:21 libcoinmumps.dylib -> libcoinmumps.1.4.9.dylib
-rwxr-xr-x 1 huchette staff 857 Mar 15 00:21 libcoinmumps.la
-rwxr-xr-x 1 huchette staff 2589152 Mar 15 00:23 libipopt.1.9.4.dylib
lrwxr-xr-x 1 huchette staff 20 Mar 15 00:23 libipopt.1.dylib -> libipopt.1.9.4.dylib
lrwxr-xr-x 1 huchette staff 20 Mar 15 00:23 libipopt.dylib -> libipopt.1.9.4.dylib
-rwxr-xr-x 1 huchette staff 1300 Mar 15 00:23 libipopt.la
drwxr-xr-x 6 huchette staff 204 Mar 15 00:23 pkgconfig
from ipopt.jl.
I think we're in business then, does that a) succeed at Ipopt's make test
, and b) work in Julia?
You shouldn't need to worry about --without-mpi
anywhere, that's something that should only matter if you're getting Ipopt from homebrew-science. Or maybe if you have some MPICC
etc. environment variables set. Was it causing problems without that?
You also shouldn't need to configure or build Mumps separately, just download its source code with ./get.Mumps
before you configure Ipopt. A dylib for Mumps should be fine (and was what you got, since you didn't tell Ipopt anything about the separate static version you built without needing to).
from ipopt.jl.
The unit tests are choking on a missing symbol in Mumps:
./run_unitTests
Running unitTests...
Testing AMPL Solver Executable...
no AMPL solver executable found, skipping test...
Testing C++ Example...
./run_unitTests: line 59: 58087 Trace/BPT trap: 5 ./hs071_cpp > tmpfile 2>&1
---- 8< ---- Start of test program output ---- 8< ----
dyld: lazy symbol binding failed: Symbol not found: _dsyr_
Referenced from: /Users/huchette/.julia/v0.3/Ipopt/deps/src/Ipopt-3.11.4/build/ThirdParty/Mumps/.libs/libcoinmumps.1.dylib
Expected in: flat namespace
dyld: Symbol not found: _dsyr_
Referenced from: /Users/huchette/.julia/v0.3/Ipopt/deps/src/Ipopt-3.11.4/build/ThirdParty/Mumps/.libs/libcoinmumps.1.dylib
Expected in: flat namespace
---- 8< ---- End of test program output ---- 8< ----
******** Test FAILED! ********
Output of the test program is above.
Testing C Example...
./run_unitTests: line 77: 58105 Trace/BPT trap: 5 ./hs071_c > tmpfile 2>&1
---- 8< ---- Start of test program output ---- 8< ----
dyld: lazy symbol binding failed: Symbol not found: _dsyr_
Referenced from: /Users/huchette/.julia/v0.3/Ipopt/deps/src/Ipopt-3.11.4/build/ThirdParty/Mumps/.libs/libcoinmumps.1.dylib
Expected in: flat namespace
dyld: Symbol not found: _dsyr_
Referenced from: /Users/huchette/.julia/v0.3/Ipopt/deps/src/Ipopt-3.11.4/build/ThirdParty/Mumps/.libs/libcoinmumps.1.dylib
Expected in: flat namespace
---- 8< ---- End of test program output ---- 8< ----
******** Test FAILED! ********
Output of the test program is above.
Testing Fortran Example...
./run_unitTests: line 95: 58122 Trace/BPT trap: 5 ./hs071_f > tmpfile 2>&1
---- 8< ---- Start of test program output ---- 8< ----
dyld: lazy symbol binding failed: Symbol not found: _dsyr_
Referenced from: /Users/huchette/.julia/v0.3/Ipopt/deps/src/Ipopt-3.11.4/build/ThirdParty/Mumps/.libs/libcoinmumps.1.dylib
Expected in: flat namespace
dyld: Symbol not found: _dsyr_
Referenced from: /Users/huchette/.julia/v0.3/Ipopt/deps/src/Ipopt-3.11.4/build/ThirdParty/Mumps/.libs/libcoinmumps.1.dylib
Expected in: flat namespace
Program received signal SIGTRAP: Trace/breakpoint trap.
Backtrace for this error:
#0 0x10a069f72
#1 0x10a06a73e
#2 0x7fff895bf5a9
---- 8< ---- End of test program output ---- 8< ----
******** Test FAILED! ********
Output of the test program is above.
make[2]: *** [test] Error 255
make[1]: *** [unitTest] Error 2
make: *** [test] Error 2
from ipopt.jl.
Damn, the unit tests ran in Linux but apparently not on Mac. I'll fire up my Mac VM and let you know what I figure out. Might involve building Mumps statically too, like you did but telling Ipopt about it a la --with-mumps=$prefix/lib/libcoinmumps.a
from ipopt.jl.
Can reproduce, more or less, with Ipopt 3.11.4.
Please update to Ipopt 3.11.7.
Used this build script, essentially identical to this #1 (comment)
from ipopt.jl.
Wow, looks like this works! Thanks so much!
from ipopt.jl.
Nice! Just need to update the homebrew script now.
from ipopt.jl.
I have a fixed version of the BinDeps SimpleBuild, but didn't do the homebrew script.
from ipopt.jl.
Related Issues (20)
- add `MathOptInterface.Name()` attribute HOT 1
- `max_wall_time` is still not working HOT 5
- Allow user to specify the Ipopt binary HOT 2
- copy_to does not copy attributes for variable bound constraints HOT 6
- Only evaluate QP callbacks if needed HOT 1
- Problem with HSL solvers since updating to MacOS 13.0 HOT 3
- double free or corruption (out) error HOT 20
- Linking full hsl library to Ipopt.jl on ubuntu HOT 19
- julia 0.6.0 install Ipopt cannot connect to mumps dependency HOT 2
- Add support for GetIpoptCurrentViolations
- Incorrect number of Hessian structure (nonzero entries) HOT 10
- Does Ipopt.jl support giving hessian matrix in JuMP directly, without using the C_wrapper? HOT 2
- pointer being freed was not allocated HOT 33
- Invalid number in NLP function or derivative detected. HOT 8
- Issue with non-negative variable tolerance. HOT 2
- does not allow Ipopt_jll current version HOT 2
- Add some pre-built "debugging" callbacks HOT 1
- Crash on Windows when optimizing with SPRAL_jll HOT 11
- Using Ipopt in parallel threads HOT 4
- "double free or corruption" when providing duplicate hessian entries via MathOptInterface HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ipopt.jl.