[Ipopt] Strategies for solving a large scale optimisation problem?

[Damien Hocking]

Omid,

We've also done large problems, 25M variables and 10M constraints, and 
with the limited memory Hessian, no second derivatives, and MKL Pardiso. 
The first thing is to get your first derivatives right. Smooth, 
continuous and make sure they're not zero, this kills the linear solver.

Second, IPOPT is a good optimiser but it's a weak nonlinear equation 
solver. If you solve a straight NxN sparse nonlinear problem, a standard 
Newton solver will be much faster than IPOPT. If you can give IPOPT a 
decent starting point, like a converged but not optimised system, you'll 
be much more likely to succeed. When I say converged but not optimised, 
I mean the basic physics, such as the equality constraints are all 
converged but the inequalities aren't. This is what we do, a basic solve 
of the physics (material, momentum and energy balance in our case) with 
a Newton solver and then load the model with the optimisation structure 
into IPOPT. One other advantage of this is that you can see if you've 
posed the physics correctly before you try and optimise.

Damien

On 2020-12-16 6:11 a.m., Seth Watts wrote:
> Hi Omid -
>
> I often use Ipopt to solve problems at the same order of your large 
> problem, although in my case the physics is solid mechanics solved 
> with FEA. Even for linear physics, the runtime is dominated by the 
> physics rather than the Ipopt functions. I haven’t checked lately, but 
> my recollection is that 95+% of the runtime is spent evaluating f, g, 
> df, and dg, rather than solving for an update (for which I use the HSL 
> solvers).
>
> I would therefore start by trying to accelerate your response function 
> evaluations. How do you evaluate their derivatives? An adjoint 
> sensitivity analysis is almost certainly the best choice. Can you 
> reduce the number of times you need to solve your physics by saving 
> the solution fields for each update (rather than the naive approach of 
> solving them each time you need to evaluate a response function)? Can 
> you parallelize your physics to reduce walltime? How many constraint 
> functions do you have? It might be possible to reformulate them to 
> reduce the number, which would reduce time spent solving for an update 
> as well as time spent evaluating constraint derivatives.
>
> - Seth
>
> On Wed, Dec 16, 2020 at 5:43 AM Omid Bidar <obidar1 at sheffield.ac.uk 
> <mailto:obidar1 at sheffield.ac.uk>> wrote:
>
>     Dear all,
>
>     I'm a new user of IPOPT, trying to solve an optimisation problem
>     in a CFD context. The number of design variables in the problem is
>     the same as the number of mesh cells, which are at least 10k but
>     could be up to 500k for the problems we are working on. So the
>     problem at hand is very nonlinear and highly dimensional.
>
>     A colleague has run the optimisation for a toy problem we're
>     working on using SNOPT successfully, but it requires a user
>     license. We're looking into using IPOPT as a free alternative.
>     We've managed to use IPOPT with a small number of design variables
>     with MUMPS as the linear solver, but the same setup for large
>     design variables currently takes too long to compute (we've had to
>     terminate the computation after running it overnight to solve the
>     problem).
>
>     Having looked on the internet I know that people have implemented
>     IPOPT for very large problems, but I haven't managed to really
>     find any good resource on how to go about setting up the problem.
>     Can someone please advise?
>
>     For brevity's sake I've not included a lot of details about the
>     problem but can share more details should this be required.
>
>     Cheers,
>     Omid
>
>
>     _______________________________________________
>
>     Ipopt mailing list
>
>     Ipopt at list.coin-or.org <mailto:Ipopt at list.coin-or.org>
>
>     https://list.coin-or.org/mailman/listinfo/ipopt
>     <https://list.coin-or.org/mailman/listinfo/ipopt>
>
>
>
>
> _______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org
> https://list.coin-or.org/mailman/listinfo/ipopt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/ipopt/attachments/20201216/43878589/attachment.html>