Changing IPOPT options after NLP solver construction

[jochem_de...@hotmail.com]

Dear all,

is there an intrinsic reason why some IPOPT options, such as, e.g.

`ipopt.mu_init`

`ipopt.mu_target`

`ipopt.acceptable_iter`

`ipopt.tol`

cannot be changed through the CasADi interface after the `nlpsol` object has been created?

The context is that I am using IPOPT (successfully) in a homotopy method, but I need to create three different solver objects (that have the same problem functions but that differ in these options) to solve the initial/middle/final problems, which can be extremely time-consuming for large-scale problems (solver construction times of up to 30 min.)

Thanks in advance and best regards,

Jochem

[jochem_de...@hotmail.com]

Note that in my case, code-generating the dependencies and compiling the code is not feasible due to the size and complexity of the problem.

Op woensdag 20 januari 2021 om 13:08:14 UTC+1 schreef jochem_de...@hotmail.com:

[Joris Gillis]

Dear Jochem,

After discussion with Joel, I spawned https://github.com/casadi/casadi/issues/2726 for this.

Best regards,

  Joris

[ese...@gmail.com]

Dear Joris,

I am running into quite a similar problem.

I am using CasADi to implement a distributed optimization method, where the local problems are repreatedly solved with IPOPT to varying accuracy with some parameters changed between each iteration.

The idea is to save execution time by solving the problem approximately in the beginning and solving it exactly, once the algorithm nears convergence.

However, this does not save execution time in practice, since a new nlpsol instance has to be created for each new iteration. The exact values of the required tolerance depends on the residual of the previous (global) solution, so I cannot know the tolerance in advance. The specific options I want to change are 'ipopt.tol' and 'ipopt.constr_viol_tol'.

I am currently doing a workaround, where I round the resulting tolerances to two significant digits and then keep all created nlpsol instances in a dictionary, so I can reuse instances for similar tolerances. However, this means I have to keep hundreds of instances in memory and even with this, creating the instances still takes up the majority of the execution time.

I'm not sure on the progress of the mentioned issue, but I think this would be a great addition to CasADi, if this option could be added in a future release.

As always, thanks for providing such a great tool!

Best regards,

Steffen

[Joris Gillis]

Dear Steffen,

Could code-generation be an option for you?

solver.generate_dependencies , compile to a library, and use the library name to setup your new Ipopt solver instance..

Best regards,

  Joris

[ese...@gmail.com]

Hello Joris,

Thanks for the heads-up, I didn't know you could use the code-gen feature in this way.

It took me some time to set everything up but now it works properly and it's really fast! Thanks a lot!

Just in case someone else stumles upon this, this is the work flow I ended up with, using Visual Studio and Python on Windows.

There's probablier easier ways to do this, but I did it the first time and it works for me.

--------------------------------------------------------------------------------------------------

import subprocess

...

filename = ...

solver.generate_dependencies( f"{filename}.c" )

subprocess.call(["compile.bat", f"{filename}.c"])

...

solver = ca.nlpsol("mpc", "ipopt", f"{filename}.dll", opts )

--------------------------------------------------------------------------------------------------

Here, "compile.bat" is a batch script that sets up the environment to use the Visual Studio compilers and then compiles the file to a .dll

For me, it looks like this

--------------------------------------------------------------------------------------------------

set source_file=%1

call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat" x64

"cl" "/LD" %source_file%

--------------------------------------------------------------------------------------------------

Hope this helps.

Best regards,

Steffen

[jochem_de...@hotmail.com]

Dear Joris,

It's been a while, any update on this would be highly appreciated! :)

Kind regards,

Jochem

Op zaterdag 6 februari 2021 om 19:51:08 UTC+1 schreef joris.g...@gmail.com: