<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>OK, many thanks,</p>
    <p>Manuel</p>
    <p>---<br>
    </p>
    <div class="moz-cite-prefix">On 4/11/19 12:07 PM, Matthew Knepley
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAMYG4Gnc66=netezX4sJWD-s4PceZu2B3UUNghVMOEPqhWTwXw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">On Thu, Apr 11, 2019 at 5:57 AM Manuel Colera
          Rico <<a href="mailto:m.colera@upm.es"
            moz-do-not-send="true">m.colera@upm.es</a>> wrote:<br>
        </div>
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            <div bgcolor="#FFFFFF">
              <p>MatCreateLocalRef() seems to be useful to extract
                submatrices from a global matrix. But how to construct A
                from the beginning from its submatrices? I.e., with
                MatNest, I can just do:</p>
              <p>    Mat A;</p>
              <p>    Mat matA[] = {A00, A01, NULL, A11};<br>
              </p>
              <p>    MatCreateNest(PETSC_COMM_SELF, 2, NULL, 2, NULL,
                matA, &A);</p>
              <p>without worrying about memory preallocations for A. Can
                I do the same with MatCreateLocalRef(), or do I first
                have to preallocate memory for A? <br>
              </p>
            </div>
          </blockquote>
          <div>It is a good point. You would have to preallocate the
            large matrix. However, the preallocation is just the sum for
            the</div>
          <div>preallocations of the small matrices, which you are
            already specifying. It would be no problem to give a similar</div>
          <div>LocalRef interface to preallocation to do that sum
            automatically for the user.</div>
          <div><br>
          </div>
          <div>Moreover, we now have a MatPreallocator interface. You
            can run your matrix assembly twice. Once with the</div>
          <div>MatPreallocator matrix, which can then preallocate you
            matrix exactly, and then again with the real matrix. This</div>
          <div>is more expensive of course, but in many applications,
            this expense is negligible compared to the solver.</div>
          <div><br>
          </div>
          <div>  Thanks,</div>
          <div><br>
          </div>
          <div>     Matt</div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            <div bgcolor="#FFFFFF">
              <p>Manuel</p>
              <p>---<br>
              </p>
              <p>On 4/11/19 11:30 AM, Matthew Knepley wrote:<br>
              </p>
              <blockquote type="cite">
                <div dir="ltr">
                  <div dir="ltr">On Thu, Apr 11, 2019 at 2:07 AM Smith,
                    Barry F. <<a href="mailto:bsmith@mcs.anl.gov"
                      target="_blank" moz-do-not-send="true">bsmith@mcs.anl.gov</a>>
                    wrote:<br>
                  </div>
                  <div class="gmail_quote">
                    <blockquote class="gmail_quote" style="margin:0px
                      0px 0px 0.8ex;border-left:1px solid
                      rgb(204,204,204);padding-left:1ex"><br>
                         Matt,<br>
                      <br>
                           You can't have some functionality in the
                      public API for a library and then criticize
                      someone for using it. I looked at the manual page
                      for MatCreateNest() and it doesn't say in big
                      letters "don't use this", nor does the compiler
                      tell the user "don't use this". Either
                      MatCreateNest() and/or MATNEST is so horrible it
                      needs to be stripped from the face of the earth or
                      it needs to be supported. It can't be in this
                      nebulous state of "yeah it exists but don't ever
                      use it".<br>
                    </blockquote>
                    <div><br>
                    </div>
                    <div>I agree this is a documentation problem. That
                      is why I try to provide complete explanations for
                      my recommendations.</div>
                    <div> </div>
                    <blockquote class="gmail_quote" style="margin:0px
                      0px 0px 0.8ex;border-left:1px solid
                      rgb(204,204,204);padding-left:1ex">    Barry<br>
                      <br>
                         In order to support easy testing of
                      MatCreateNest() based user code perhaps we could
                      add a little bit of code that allowed users to
                      call either <br>
                      MatCreateNest() or MatNestSetSubMats() but with an
                      option to have it generate a regular AIJ matrix
                      instead. For example -mat_nest_use_aij (and
                      MatNestUseAIJ()) This would allow  users to always
                      write and think about their code as nested
                      matrices but have it "fall back" to AIJ for
                      testing/debugging purposes.<br>
                    </blockquote>
                    <div><br>
                    </div>
                    <div>I think we should remove MatCreateNest()
                      completely. We should have 1 mechanism for getting
                      submatrices for creation, not 2, so we retain</div>
                    <div>MatCreateLocalRef(). Then if -mat_type nest was
                      specified, it gives you back an actually
                      submatrix, otherwise it gives a view. This would
                      do</div>
                    <div>everything that we currently do without this
                      horrible MatNest interface bubbling to the top.</div>
                    <div><br>
                    </div>
                    <div>   Matt</div>
                    <div> </div>
                    <blockquote class="gmail_quote" style="margin:0px
                      0px 0px 0.8ex;border-left:1px solid
                      rgb(204,204,204);padding-left:1ex"> > On Apr
                      10, 2019, at 11:49 AM, Manuel Colera Rico via
                      petsc-users <<a
                        href="mailto:petsc-users@mcs.anl.gov"
                        target="_blank" moz-do-not-send="true">petsc-users@mcs.anl.gov</a>>
                      wrote:<br>
                      > <br>
                      > Thank you for your answer, Matt. In the MWE
                      example attached before, both Nest vectors (the
                      r.h.s. of the system and the vector of unknowns)
                      are composed of the same number of blocks (2).
                      Indeed, PETSc is able to solve the system if
                      KSPSetUp() is not called, so the
                      system/MatNest/MatVec's must not incompatible at
                      all. Therefore, I wonder if I have missed to
                      called something before this routine or if this is
                      a KSPSetUp's bug.<br>
                      > <br>
                      > Of course one can always directly define a
                      single matrix and a single vector, but I find it
                      easier to work with Nest matrices and vectors.
                      Moreover, I think that the moment to use them is
                      from the beginning... once all the code is
                      developed, it is very hard to switch matrices
                      types.<br>
                      > <br>
                      > Regards,<br>
                      > <br>
                      > Manuel<br>
                      > <br>
                      > ---<br>
                      > <br>
                      > <br>
                      > <br>
                      > On 4/10/19 5:41 PM, Matthew Knepley wrote:<br>
                      >> On Wed, Apr 10, 2019 at 11:29 AM Manuel
                      Colera Rico via petsc-users <<a
                        href="mailto:petsc-users@mcs.anl.gov"
                        target="_blank" moz-do-not-send="true">petsc-users@mcs.anl.gov</a>>
                      wrote:<br>
                      >> Hello,<br>
                      >> <br>
                      >> I am trying to solve a system whose
                      matrix is of type MatNest. If I <br>
                      >> don't use KSPSetUp(), everything is fine.
                      However, if I use that <br>
                      >> routine, I get the following error:<br>
                      >> <br>
                      >> 0]PETSC ERROR: ---------------------
                      Error Message <br>
                      >>
                      --------------------------------------------------------------<br>
                      >> [0]PETSC ERROR: Invalid argument<br>
                      >> [0]PETSC ERROR: Nest vector arguments 1
                      and 2 have different numbers of <br>
                      >> blocks.<br>
                      >> <br>
                      >> This seems self-explanatory. Nest vectors
                      must have the same number of blocks to be
                      compatible.<br>
                      >> <br>
                      >> More broadly, there should be no reason
                      to use Nest vectors or matrices. It is an
                      optimization to<br>
                      >> be used at the very end, only after you
                      have profiled the code and seen that its
                      important. You can<br>
                      >> do everything you want to do without ever
                      touching Nest, and it looks like the Nest
                      interface is a<br>
                      >> problem for your code right now.<br>
                      >> <br>
                      >>   Thanks,<br>
                      >> <br>
                      >>     Matt<br>
                      >>  <br>
                      >> [0]PETSC ERROR: See <a
                        href="http://www.mcs.anl.gov/petsc/documentation/faq.html"
                        rel="noreferrer" target="_blank"
                        moz-do-not-send="true">http://www.mcs.anl.gov/petsc/documentation/faq.html</a>
                      <br>
                      >> for trouble shooting.<br>
                      >> [0]PETSC ERROR: Petsc Release Version
                      3.11.0, unknown<br>
                      >> [0]PETSC ERROR: <br>
                      >>
/home/manu/Documents/FEM-fluids/C-codes/CLG2-ConvectionDiffusion/Debug/CLG2-ConvectionDiffusion
                      <br>
                      >> on a mcr_20190405 named mancolric by
                      Unknown Wed Apr 10 17:20:16 2019<br>
                      >> [0]PETSC ERROR: Configure options
                      --with-cc=gcc --with-cxx=g++ <br>
                      >> --with-fc=gfortran COPTFLAGS="-O3
                      -march=native -mtune=native" <br>
                      >> CXXOPTFLAGS="-O3 -march=native
                      -mtune=native" FOPTFLAGS="-O3 <br>
                      >> -march=native -mtune=native"
                      --with-debugging=0 --download-fblaslapack <br>
                      >> --download--f2cblaslapack
                      --download-mpich --download--hypre <br>
                      >> --download-scalapack --download-mumps
                      --download-suitesparse <br>
                      >> --download-ptscotch --download-pastix
                      --with-matlab --with-openmp<br>
                      >> [0]PETSC ERROR: #1 VecCopy_Nest() line 68
                      in <br>
                      >>
                      /opt/PETSc_library/petsc-3.11.0/src/vec/vec/impls/nest/vecnest.c<br>
                      >> [0]PETSC ERROR: #2 VecCopy() line 1614 in
                      <br>
                      >>
                      /opt/PETSc_library/petsc-3.11.0/src/vec/vec/interface/vector.c<br>
                      >> [0]PETSC ERROR: #3 KSPInitialResidual()
                      line 63 in <br>
                      >>
                      /opt/PETSc_library/petsc-3.11.0/src/ksp/ksp/interface/itres.c<br>
                      >> [0]PETSC ERROR: #4 KSPSolve_GMRES() line
                      236 in <br>
                      >>
                      /opt/PETSc_library/petsc-3.11.0/src/ksp/ksp/impls/gmres/gmres.c<br>
                      >> [0]PETSC ERROR: #5 KSPSolve() line 782 in
                      <br>
                      >>
                      /opt/PETSc_library/petsc-3.11.0/src/ksp/ksp/interface/itfunc.c<br>
                      >> [0]PETSC ERROR: #6 mwe() line 55 in
                      ../Tests/tests.c<br>
                      >> <br>
                      >> Please find attached a MWE (it is a
                      slight modification of that of the <br>
                      >> post opened by Ce Qin, <br>
                      >> <a
href="https://lists.mcs.anl.gov/pipermail/petsc-users/2015-February/024230.html"
                        rel="noreferrer" target="_blank"
                        moz-do-not-send="true">https://lists.mcs.anl.gov/pipermail/petsc-users/2015-February/024230.html</a>,
                      <br>
                      >> whose answer I have not found).<br>
                      >> <br>
                      >> By the way, with the newest version of
                      PETSc, Eclipse marks as errors <br>
                      >> the commands PetscFree, CHKERRQ,
                      PETSC_COMM_SELF,... although it <br>
                      >> compiles and executes well. Perhaps it is
                      a problem related to Eclipse, <br>
                      >> but this did not happen with the older
                      versions of PETSc.<br>
                      >> <br>
                      >> Thanks and regards,<br>
                      >> <br>
                      >> Manuel<br>
                      >> <br>
                      >> ---<br>
                      >> <br>
                      >> <br>
                      >> <br>
                      >> -- <br>
                      >> What most experimenters take for granted
                      before they begin their experiments is infinitely
                      more interesting than any results to which their
                      experiments lead.<br>
                      >> -- Norbert Wiener<br>
                      >> <br>
                      >> <a
                        href="https://www.cse.buffalo.edu/~knepley/"
                        rel="noreferrer" target="_blank"
                        moz-do-not-send="true">https://www.cse.buffalo.edu/~knepley/</a><br>
                      <br>
                    </blockquote>
                  </div>
                  <br clear="all">
                  <div><br>
                  </div>
                  -- <br>
                  <div dir="ltr"
                    class="gmail-m_716376249453890510gmail_signature">
                    <div dir="ltr">
                      <div>
                        <div dir="ltr">
                          <div>
                            <div dir="ltr">
                              <div>What most experimenters take for
                                granted before they begin their
                                experiments is infinitely more
                                interesting than any results to which
                                their experiments lead.<br>
                                -- Norbert Wiener</div>
                              <div><br>
                              </div>
                              <div><a
                                  href="http://www.cse.buffalo.edu/~knepley/"
                                  target="_blank" moz-do-not-send="true">https://www.cse.buffalo.edu/~knepley/</a><br>
                              </div>
                            </div>
                          </div>
                        </div>
                      </div>
                    </div>
                  </div>
                </div>
              </blockquote>
            </div>
          </blockquote>
        </div>
        <br clear="all">
        <div><br>
        </div>
        -- <br>
        <div dir="ltr" class="gmail_signature">
          <div dir="ltr">
            <div>
              <div dir="ltr">
                <div>
                  <div dir="ltr">
                    <div>What most experimenters take for granted before
                      they begin their experiments is infinitely more
                      interesting than any results to which their
                      experiments lead.<br>
                      -- Norbert Wiener</div>
                    <div><br>
                    </div>
                    <div><a href="http://www.cse.buffalo.edu/~knepley/"
                        target="_blank" moz-do-not-send="true">https://www.cse.buffalo.edu/~knepley/</a><br>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
  </body>
</html>