<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <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>
      <a href="https://www.dict.cc/?s=obviously"></a></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"><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>
  </body>
</html>