<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 06/06/19 14:56, Pierre Seize via
      petsc-users wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:09fe9b55-064f-b86b-a25c-1c10cdabab0c@onera.fr">
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      <p>Dear PETSc,</p>
      <p>I have been reading the sources about the GMRES (mostly the
        FGMRES) solver, and there are a few things I do not understand.</p>
      <p>    - Aren't the arrays used to represent the Hessenberg matrix
        too wide ? The <tt>hh_origin</tt> and <tt>hes_origin</tt>
        arrays are allocated using <tt>(max_k + 2) * (max_k + 1)</tt>
        and <tt>(max_k + 1) * (max_k + 1)</tt> scalars respectively.
        But when I monitor those two matrices I see that the last
        columns (and therefore the last line of hh_origin) are not used.
        Is there a reason why the <tt>hh_origin</tt> array is not of
        size <tt>(max_k + 1) * (max_k)</tt> ?</p>
    </blockquote>
    Please forget the following point. It seems that I cannot read
    correctly : <tt>hes_origin</tt> is used instead of <tt>hh_origin</tt>
    ...<br>
    <blockquote type="cite"
      cite="mid:09fe9b55-064f-b86b-a25c-1c10cdabab0c@onera.fr">
      <p> </p>
      <p>    - In <tt>KSPComputeExtremeSingularValues_GMRES</tt> we
        compute the singular values of the <tt>hh_origin</tt> array,
        which is an upper diagonal (R) matrix from a QR decomposition of
        the Hessenberg matrix. Therefore it has the same singular values
        as the original Hessenberg matrix. In this function, we don't
        forget to "zero the below diagonal garbage". But in <tt>KSPComputeEigenvalues_GMRES</tt>
        we just use <tt>hh_origin</tt> right away, without removing the
        sub-diagonal. I don't understand what's computed here : the
        eigenvalues of the upper diagonal representation of the
        Hessenberg matrix + the subdiagonal part of the Hessenberg
        matrix ? Why don't we use the <tt>hes_origin</tt> matrix ?
        Finally, in <tt>KSPComputeRitz_GMRES</tt> we use <tt>hes_ritz</tt>,
        the last full Hessenberg matrix if available (<tt>gmres->fullcycle
          > 0</tt>), and <tt>hh_origin</tt> otherwise. But <tt>hes_ritz</tt>
        is a copy of the last full <tt>hh_origin</tt>, so my question
        is the same as before :<br>
      </p>
      <p>    <b>TLDR</b> : why do we use <tt>hh_origin</tt> to compute
        the eigenvalues, and not <tt>hes_origin</tt> ? Why is <tt>hes_ritz</tt>
        a copy of <tt>hh_origin</tt> and not of <tt>hes_origin</tt> ?<br>
      </p>
      <p><br>
      </p>
    </blockquote>
    I maintain my questions about the Hessenberg arrays sizes, and the <tt>hes_ritz</tt>
    / <tt>fullcycle</tt> arguments not being used in FGMRES.<br>
    <blockquote type="cite"
      cite="mid:09fe9b55-064f-b86b-a25c-1c10cdabab0c@onera.fr">
      <p> </p>
      <p>    - I have also noticed that the <tt>fullcycle</tt>
        attribute is not used for FGMRES (it is for GMRES). Is that
        intentional ? This attribute is only used in the <tt>KSPComputeRitz_GMRES</tt>
        function, does that mean that <tt>KSPComputeRitz </tt>should
        not be called with a FGMRES type ? If so, should there be a test
        to check if the KSP type is indeed GMRES and raise a
        warning/error if not ?</p>
      <p><br>
      </p>
      <p>I hope I'm not bothering too much, I've tried to answer theses
        questions by myself but I can't seem to find out.</p>
      <p><br>
      </p>
      <p>Thanks in advance,</p>
      <p>Pierre Seize<br>
      </p>
      <p><br>
      </p>
    </blockquote>
    <br>
  </body>
</html>