Compiling with prebuilt IPOPT binaries under visual studio

1,130 views
Skip to first unread message

Dave Greer

unread,
Feb 14, 2014, 2:46:13 PM2/14/14
to casadi...@googlegroups.com
Hi, 

I have been trying to get CasADi to build under visual studio using the prebuilt IPOPT binaries from 


I used CMake to generate a visual studio solution, which did not build straight away and I had to make a few hacky changes:  

- I had to change ipopt_internal.cpp to use IpoptApplicationFactory() instead of new IpoptApplication.  This seems to be a requirement when using IPOPT as a dll as described here https://projects.coin-or.org/Ipopt/wiki/CompilationHints and I previously made this change successfully when using IPOPT with ADOL-C.  

- it looks like ipopt_internal.cpp queries the IpoptApplication instance for a list of options with RegOptions()->RegisteredOptionsList().  For me this was returning garbage data (the size of the list was reported as some random huge number), so I commented out this section and manually inserted some of the important IPOPT options such as "hessian_approximation" into CasADi's list of options.

With these changes, I was able to build the solution, but when I tried to run any of the examples I would run into crashes with invalid null pointers during getJacG().  As far as I can tell this is happening because the vector which should store the non-zero elements is empty.  I have uploaded the call stack for the rocket_ipopt example here     


The problem always seems to be with determining the constraint Jacobian - determining the gradient of the objective function seems to be working correctly.

I thought the problem might be to do with the changes I had made to the IPOPT interface, so I tried regenerating the CasADi solution without IPOPT support, but I ran into the same null pointer problem, for example in test_csparse_casadi.  I also tried using Nmake to compile but still got the same problem.

Can anyone suggest what might be going wrong?

Best wishes,

David

    

Dave Greer

unread,
Feb 14, 2014, 9:16:05 PM2/14/14
to casadi...@googlegroups.com
I just tried again on my machine at home (the previous post referred to my computer in the office) and it seems to be working fine.  This time I checked out the tested branch using git, previously I think I was using master downloaded from the web page.  I'll try duplicating what I did at home when I'm back in the office on Monday.

Joel Andersson

unread,
Feb 17, 2014, 3:51:02 AM2/17/14
to casadi...@googlegroups.com
Hello Dave!

Building CasADi with Visual Studio is often causing problem, so our suggestion is to try to use the MingGW compilers when in Windows. It looks like your problems on your computer in the office are related to incompatible versions of IPOPT.

In any cause, note that there are also Windows binaries of CasADi and that these already contain IPOPT, so there is no need to build or get IPOPT separately. You will find these binaries on files.casadi.org.

The master branch contains the latest release and is updated rarely. We completed the 1.8 release of CasADi this weekend (announcement email will follow today), so the master branch now contains this one. When you checked out the master branch it probably still referred to 1.7 from July last year and a lot of things have changed since then.

Good luck and let us know if you run into more troubles!
Joel

Dave Greer

unread,
Feb 17, 2014, 8:26:46 AM2/17/14
to casadi...@googlegroups.com
Hi Joel,

thanks for your response.  I previously looked at the CasADi binaries but I couldn't see any way to use them with C++ rather than the python interface (I would prefer to use C++ as I already have quite a lot of existing code from when I was working with ADOL-C).  Is there a way to use them with C++?

I tried again on my office machine using the tested branch and the non-IPOPT examples are now working fine but I'm still getting null pointer problems in the rocket_ipopt example.  Is there a way I can tell which version of IPOPT would be compatible?  I was using 3.11.0.

Best wishes,

Dave

Joel Andersson

unread,
Feb 17, 2014, 8:51:27 AM2/17/14
to casadi...@googlegroups.com
Hello!

I see. I think you are right that the current binaries are only for Python.

I don't think it is a question of different versions of IPOPT, but rather of different compilers and non-compatible binaries. But I can be wrong. The safest I would say is to try to compile everything with the same compiler, i.e. compile IPOPT yourself in your case.

Greetings,
Joel

Dave Greer

unread,
Feb 17, 2014, 9:58:29 AM2/17/14
to casadi...@googlegroups.com
Hi Joel,

I would have thought if there was an incompatibility between the compiler used for the binaries and the one I am using then it would have failed at the link stage.  Also, I have previously linked against those exact same binaries when I was using ADOL-C, without issue.  I have previously tried to build IPOPT in visual studio, but it is difficult as some parts of it require a fortran compiler.

Dave 

Joel Andersson

unread,
Feb 17, 2014, 11:35:21 AM2/17/14
to casadi...@googlegroups.com
Hello!

There is no IPOPT source code included in CasADi so the only incompatibility I can see is possible is between your IPOPT header files (located and used by CasADi) and your IPOPT library, and possibly a binary incompatibility between the compiler used for compiling IPOPT and the compiler used for compiling CasADi. Did you check in the CMake output from CasADi that the IPOPT libraries and header files are consistent? I also find it strange that you need to modify the source the way you describe.

It is also possible that we are talking about a genuine bug in CasADi's build system which only manifests itself under MSVC. As I said, we use MinGW when building on WIndows.

Joel

Dave Greer

unread,
Feb 18, 2014, 11:48:21 AM2/18/14
to casadi...@googlegroups.com
Hi Joel,

I got everything building nicely in Cygwin, so I've given up on visual studio for the time being.  

Thanks for your help,

Dave

Joel Andersson

unread,
Feb 18, 2014, 12:00:47 PM2/18/14
to casadi...@googlegroups.com
OK, great to hear! We are constantly working on improving the build procedures and distribution of binaries so hopefully this will go smoother in the future.

Joel
Reply all
Reply to author
Forward
0 new messages