Stephan,
I have located the troublesome line in TaoSetUp_ALMM() it has the line
auglag->Px = tao->solution;
and in alma.h it has
Vec Px, LgradX, Ce, Ci, G; /* aliased vectors (do not destroy!) */
Now auglag->P in some situations alias auglag->P and in some cases auglag->Px
serves to hold a portion of auglag->P. So then in
TaoALMMSubsolverObjective_Private()
the lines
PetscCall(VecCopy(P, auglag->P));
PetscCall((*auglag->sub_obj)(auglag->parent));
causes, just as you said, tao->solution to be overwritten by the P at which the
objective function is being computed. In other words, the solution of the outer
Tao is aliased with the solution of the inner Tao, by design.
You are definitely correct, the use of TaoALMMSubsolverObjective_Private and
TaoALMMSubsolverObjectiveAndGradient_Private in a line search would be
problematic.
I am not an expert at these methods or their implementations. Could you point
to an actual use case within Tao that triggers the problem. Is there a set of
command line options or code calls to Tao that fail due to this "design
feature". Within the standard use of ALMM I do not see how the objective
function would be used within a line search. The TaoSolve_ALMM() code is
self-correcting in that if a trust region check fails it automatically rolls
back the solution.
Barry
> On Oct 28, 2022, at 4:27 AM, Stephan Köhler
> <[email protected]> wrote:
>
> Dear PETSc/Tao team,
>
> it seems to be that there is a bug in the TaoALMM class:
>
> In the methods TaoALMMSubsolverObjective_Private and
> TaoALMMSubsolverObjectiveAndGradient_Private the vector where the function
> value for the augmented Lagrangian is evaluate
> is copied into the current solution, see, e.g.,
> https://petsc.org/release/src/tao/constrained/impls/almm/almm.c.html line 672
> or 682. This causes subsolver routine to not converge if the line search for
> the subsolver rejects the step length 1. for some
> update. In detail:
>
> Suppose the current iterate is xk and the current update is dxk. The line
> search evaluates the augmented Lagrangian now at (xk + dxk). This causes
> that the value (xk + dxk) is copied in the current solution. If the point
> (xk + dxk) is rejected, the line search should
> try the point (xk + alpha * dxk), where alpha < 1. But due to the copying,
> what happens is that the point ((xk + dxk) + alpha * dxk) is evaluated, see,
> e.g., https://petsc.org/release/src/tao/linesearch/impls/armijo/armijo.c.html
> line 191.
>
> Best regards
> Stephan Köhler
>
> --
> Stephan Köhler
> TU Bergakademie Freiberg
> Institut für numerische Mathematik und Optimierung
>
> Akademiestraße 6
> 09599 Freiberg
> Gebäudeteil Mittelbau, Zimmer 2.07
>
> Telefon: +49 (0)3731 39-3173 (Büro)
>
> <OpenPGP_0xC9BF2C20DFE9F713.asc>
