[Ipopt] Managing large simulation codes
Ruhollah Tavakoli
rohtav at gmail.com
Fri Jan 30 00:54:12 EST 2009
Praveen,
there are two ways to do this, the first one is to use all-at-once concept
in which you consider your PDEs as equality constraint, e.g. see works by
Ghattas & Biros (JCP) or works by Elmad Haber (IP), the other way is what
you describe, i.e. solving PDEs externally
The former way is memory expensive and is not suitable for large problem, in
particular IPOPT uses sparse direct solvers and memory leaves as a great
problem.
for the second way, IPOPT has a flag that show if design vector was changed
(needs new solution), just see documentation. However, it's more safe to do
it in your code, you can always save a copy of design + solution and so
computation if design is changed.
My advice: IPOPT is very rubost, i extensively used it besides other boxes
like: MMA, SCPIP, ALGENCAN, ... I think that IPOPT is not suitable for large
scaler (n>10^5) problems in which we need approximate solution like *CFD*
computation due to expense of CPU & memory.
you can easily test that the line search used in IPOPT is very expensive for
CFD application, because it does lot of function evaluation, and usually
does not go a sensible proceed, maybe because objective function value
provided by CFD computation is not exact and include several types of
approximation.
cheers
RT
On Fri, Jan 23, 2009 at 7:59 AM, Praveen C <cpraveen at gmail.com> wrote:
> Hello
> I want to use ipopt to optimize using a large Computational Fluid Dynamics
> code. The situation can be described as follows
>
>
> x = design variable
>
> Flow solution:
> Q = CFD(x)
>
> Objective and constraint:
> F = F(x,Q)
> G = G(x,Q)
>
> To obtain gradients of objective and constraint, I have to run two adjoint
> solvers (assuming only one obj and one constraint)
>
> F_x = CFD_F(x,Q)
> G_x = CFD_G(x,Q)
>
> All the solvers CFD, CFD_F and CFD_G are expensive.
>
> My question is:
>
> How would I manage these things so that I do not do any duplicate
> computations ?
>
> Q is too large and cannot be stored in memory.
>
> Thanks
> praveen
> --
> http://pc.freeshell.org
>
> _______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/ipopt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.coin-or.org/pipermail/ipopt/attachments/20090130/db664beb/attachment.html
More information about the Ipopt
mailing list