Barry,

so far, I have not experimented with trust-region methods, but I can imagine that this "design feature" causes no problem for trust-region methods, if the old point is saved and after the trust-region check fails the old point is copied to the actual point.  But the implementation of the Armijo line search method does not work that way.  Here, the actual point will always be overwritten.  Only if the line search fails, then the old point is restored, but then the TaoSolve method ends with a line search failure.

If you have an example for your own, you can switch the Armijo line search by the option -tao_ls_type armijo.  The thing is that it will cause no problems if the line search accepts the steps with step length one. It is also possible that, by luck, it will cause no problems, if the "excessive" step brings a reduction of the objective

Otherwise, I attach my example, which is not minimal, but here you can see that it causes problems.  You need to set the paths to the PETSc library in the makefile.  You find the options for this problem in the run_test_tao_neohooke.sh script.
The import part begins at line 292 in test_tao_neohooke.cpp

Stephan

On 02.11.22 19:04, Barry Smith wrote:
   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<stephan.koeh...@math.tu-freiberg.de>  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>

--
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)

Attachment: Minimal_example_without_vtk_2.tar.gz
Description: application/gzip

Attachment: OpenPGP_0xC9BF2C20DFE9F713.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to