<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><br></div> Stephan,<div><br></div><div> The Tao author has kindly fixed the bug in the code you found in <a href="https://gitlab.com/petsc/petsc/-/merge_requests/5890">https://gitlab.com/petsc/petsc/-/merge_requests/5890</a> Please let us know if this works and resolves your problem.</div><div><br></div><div> Thanks</div><div><br></div><div> Barry</div><div><br><div><br><blockquote type="cite"><div>On Nov 22, 2022, at 4:03 AM, Stephan Köhler <stephan.koehler@math.tu-freiberg.de> wrote:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div>
<font face="monospace">Yeah, I also read this. But for me as a
reader </font>"highly recommended" does not mean that Armijo does
not work correct with ALMM :).<br>
<br>
And I think that Armijo is easier than trust-region in the sense
that if Armijo does not work, than I did something wrong in the
Hessian or the gradient. In trust-region methods, there are more
parameters and maybe I set one of them wrong or something like that.<br>
At least, this is my view. But I'm also not an expert on
trust-region methods.<br>
<br>
<div class="moz-cite-prefix">On 12.11.22 06:00, Barry Smith wrote:<br>
</div>
<blockquote type="cite" cite="mid:2E5E8937-D739-4CFB-9A21-28DFBF5791B5@petsc.dev">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div><br>
</div>
I noticed this in the TAOALMM manual page.
<div><br>
</div>
<div>
<div>It is also highly recommended that the subsolver chosen by
the user utilize a trust-region</div>
<div>strategy for globalization (default: TAOBQNKTR) especially
if the outer problem features bound constraints.</div>
<div><br>
</div>
<div>I am far from an expert on these topics.</div>
<div><br>
<blockquote type="cite">
<div>On Nov 4, 2022, at 7:43 AM, Stephan Köhler
<a class="moz-txt-link-rfc2396E" href="mailto:stephan.koehler@math.tu-freiberg.de"><stephan.koehler@math.tu-freiberg.de></a> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<div> <font face="monospace">Barry,<br>
<br>
this is a nonartificial code. This is a problem in
the ALMM subsolver. I want to solve a problem with a
TaoALMM solver what then happens is:<br>
<br>
TaoSolve(tao) /* TaoALMM solver */<br>
|<br>
|<br>
|--------> This calls the TaoALMM subsolver
routine<br>
<br>
TaoSolve(subsolver)<br>
|<br>
|<br>
|-----------> The
subsolver does not correctly work, at least with an
Armijo line search, since the solution is overwritten
within the line search. <br>
In my case, the
subsolver does not make any progress although it is
possible.<br>
<br>
To get to my real problem you can simply change line
268 to if(0) (from if(1) -----> if(0)) and line
317 from // ierr = TaoSolve(tao); CHKERRQ(ierr);
-------> ierr = TaoSolve(tao); CHKERRQ(ierr);<br>
What you can see is that the solver does not make any
progress, but it should make progress.<br>
<br>
To be honest, I do not really know why the option
-tao_almm_subsolver_tao_ls_monitor has know effect if
the ALMM solver is called and not the subsolver. I
also do not know why -tao_almm_subsolver_tao_view
prints as termination reason for the subsolver <br>
<br>
Solution converged: ||g(X)|| <= gatol<br>
<br>
This is </font><font face="monospace">obviously not
the case. I set the tolerance <br>
-tao_almm_subsolver_tao_gatol 1e-8 \<br>
-tao_almm_subsolver_tao_grtol 1e-8 \<br>
<br>
I encountered this and then I looked into the ALMM
class and therefore I tried to call the subsolver
(previous example).<br>
<br>
I attach the updated programm and also the options.<br>
<br>
Stephan<br>
<br>
<br>
<br>
<br>
<br>
</font>
<div class="moz-cite-prefix">On 03.11.22 22:15, Barry
Smith wrote:<br>
</div>
<blockquote type="cite" cite="mid:5E53FE56-5C68-4F06-8A48-54ACBDC800C7@petsc.dev">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div><br>
</div>
Thanks for your response and the code. I understand
the potential problem and how your code demonstrates a
bug if the TaoALMMSubsolverObjective() is used in the
manner you use in the example where you directly
call TaoComputeObjective() multiple times line a line
search code might.
<div><br>
</div>
<div> What I don't have or understand is how to
reproduce the problem in a real code that uses Tao.
That is where the Tao <span style="font-family:
monospace;">Armijo</span> line search code has a
problem when it is used (somehow) in a Tao solver
with ALMM. You suggest "<span style="font-family:
monospace;">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." I don't see how
to do this if I use -tao_type </span><font face="monospace">almm I cannot use </font><span style="font-family: monospace;">-tao_ls_type
armijo; that is the option </span><span style="font-family: monospace;">-tao_ls_type
doesn't seem to me to be usable in the context of
almm (since almm internally does directly its own
trust region approach for globalization). If we
remove the if (1) code from your example, is there
some Tao options I can use to get the bug to
appear inside the Tao solve?</span></div>
<div><span style="font-family: monospace;"><br>
</span></div>
<div><font face="monospace">I'll try to explain again,
I agree that the fact that the Tao solution is
aliased (within the ALMM solver) is a problem with
repeated calls to </font>TaoComputeObjective() but
I cannot see how these repeated calls could ever
happen in the use of TaoSolve() with the ALMM
solver. That is when is this "design problem" a true
problem as opposed to just a potential problem that
can be demonstrated in artificial code?</div>
<div><br>
</div>
<div>The reason I need to understand the
non-artificial situation it breaks things is to come
up with an appropriate correction for the current
code.</div>
<div><br>
</div>
<div> Barry</div>
<div><br>
</div>
<div><br>
</div>
<div><span style="font-family: monospace;"><br>
</span></div>
<div><span style="font-family: monospace;"><br>
</span></div>
<div><br>
</div>
<div><br>
</div>
<div>
<div><br>
<blockquote type="cite">
<div>On Nov 3, 2022, at 12:46 PM, Stephan Köhler
<a class="moz-txt-link-rfc2396E" href="mailto:stephan.koehler@math.tu-freiberg.de" moz-do-not-send="true"><stephan.koehler@math.tu-freiberg.de></a>
wrote:</div>
<br class="Apple-interchange-newline">
<div>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div> <font face="monospace">Barry,<br>
<br>
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. <br>
<br>
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. <br>
It is also possible that, by luck, it will
cause no problems, if the </font><font face="monospace"><var title="adjective">"excessive"</var>
step brings a reduction of the objective<br>
<br>
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.<br>
The import part begins at line 292 in
test_tao_neohooke.cpp<br>
<br>
Stephan<br>
</font><br>
<div class="moz-cite-prefix">On 02.11.22
19:04, Barry Smith wrote:<br>
</div>
<blockquote type="cite" cite="mid:AB01B851-54B1-4878-B08D-0D15CB3EA825@petsc.dev">
<pre class="moz-quote-pre" wrap=""> 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
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Oct 28, 2022, at 4:27 AM, Stephan Köhler <a class="moz-txt-link-rfc2396E" href="mailto:stephan.koehler@math.tu-freiberg.de" moz-do-not-send="true"><stephan.koehler@math.tu-freiberg.de></a> 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., <a class="moz-txt-link-freetext" href="https://petsc.org/release/src/tao/constrained/impls/almm/almm.c.html" moz-do-not-send="true">https://petsc.org/release/src/tao/constrained/impls/almm/almm.c.html</a> 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., <a class="moz-txt-link-freetext" href="https://petsc.org/release/src/tao/linesearch/impls/armijo/armijo.c.html" moz-do-not-send="true">https://petsc.org/release/src/tao/linesearch/impls/armijo/armijo.c.html</a> 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>
</pre>
</blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
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)</pre>
</div>
<span id="cid:53BF6026-151A-4E18-A28A-EB4E32053206"><Minimal_example_without_vtk_2.tar.gz></span><span id="cid:BA6DFAE3-9D35-4B59-ADCF-7215AE537875"><OpenPGP_0xC9BF2C20DFE9F713.asc></span></div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
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)</pre>
</div>
<span id="cid:5BB928F7-60C9-4222-A986-5D019BA22F4F"><run_test_tao_neohooke.sh></span><span id="cid:FE400ED3-1EFE-4AF7-B2D6-DD3B39229E5E"><test_tao_neohooke.cpp></span><span id="cid:1986F733-B355-4B58-A154-3DB836B8882F"><OpenPGP_0xC9BF2C20DFE9F713.asc></span></div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
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)</pre>
</div>
<span id="cid:5ED27353-8E40-4C1E-B6CC-1B66296F8C8D"><OpenPGP_0xC9BF2C20DFE9F713.asc></span></div></blockquote></div><br></div></body></html>