<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <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>
    <p>Manuel</p>
    <p>---<br>
    </p>
    <p>On 4/11/19 11:30 AM, Matthew Knepley wrote:<br>
    </p>
    <blockquote type="cite"
cite="mid:CAMYG4G=X6ZRkQjihAjBmRMqa-JPYDJDQ66RWAJq65+mLtH8zXw@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 2:07 AM Smith, Barry F.
          <<a href="mailto:bsmith@mcs.anl.gov" 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_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>