[petsc-users] Error with KSPSetUp and MatNest

Thu Apr 11 04:30:44 CDT 2019

On Thu, Apr 11, 2019 at 2:07 AM Smith, Barry F. <bsmith at mcs.anl.gov> wrote:

>
>    Matt,
>
>      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".
>

I agree this is a documentation problem. That is why I try to provide
complete explanations for my recommendations.

>    Barry
>
>    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
> 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.
>

I think we should remove MatCreateNest() completely. We should have 1
mechanism for getting submatrices for creation, not 2, so we retain
MatCreateLocalRef(). Then if -mat_type nest was specified, it gives you
back an actually submatrix, otherwise it gives a view. This would do
everything that we currently do without this horrible MatNest interface
bubbling to the top.

   Matt

> > On Apr 10, 2019, at 11:49 AM, Manuel Colera Rico via petsc-users <
> petsc-users at mcs.anl.gov> wrote:
> >
> > 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.
> >
> > 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.
> >
> > Regards,
> >
> > Manuel
> >
> > ---
> >
> >
> >
> > On 4/10/19 5:41 PM, Matthew Knepley wrote:
> >> On Wed, Apr 10, 2019 at 11:29 AM Manuel Colera Rico via petsc-users <
> petsc-users at mcs.anl.gov> wrote:
> >> Hello,
> >>
> >> I am trying to solve a system whose matrix is of type MatNest. If I
> >> don't use KSPSetUp(), everything is fine. However, if I use that
> >> routine, I get the following error:
> >>
> >> 0]PETSC ERROR: --------------------- Error Message
> >> --------------------------------------------------------------
> >> [0]PETSC ERROR: Invalid argument
> >> [0]PETSC ERROR: Nest vector arguments 1 and 2 have different numbers of
> >> blocks.
> >>
> >> This seems self-explanatory. Nest vectors must have the same number of
> blocks to be compatible.
> >>
> >> More broadly, there should be no reason to use Nest vectors or
> matrices. It is an optimization to
> >> be used at the very end, only after you have profiled the code and seen
> that its important. You can
> >> do everything you want to do without ever touching Nest, and it looks
> like the Nest interface is a
> >> problem for your code right now.
> >>
> >>   Thanks,
> >>
> >>     Matt
> >>
> >> [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html
> >> for trouble shooting.
> >> [0]PETSC ERROR: Petsc Release Version 3.11.0, unknown
> >> [0]PETSC ERROR:
> >>
> /home/manu/Documents/FEM-fluids/C-codes/CLG2-ConvectionDiffusion/Debug/CLG2-ConvectionDiffusion
>
> >> on a mcr_20190405 named mancolric by Unknown Wed Apr 10 17:20:16 2019
> >> [0]PETSC ERROR: Configure options --with-cc=gcc --with-cxx=g++
> >> --with-fc=gfortran COPTFLAGS="-O3 -march=native -mtune=native"
> >> CXXOPTFLAGS="-O3 -march=native -mtune=native" FOPTFLAGS="-O3
> >> -march=native -mtune=native" --with-debugging=0 --download-fblaslapack
> >> --download--f2cblaslapack --download-mpich --download--hypre
> >> --download-scalapack --download-mumps --download-suitesparse
> >> --download-ptscotch --download-pastix --with-matlab --with-openmp
> >> [0]PETSC ERROR: #1 VecCopy_Nest() line 68 in
> >> /opt/PETSc_library/petsc-3.11.0/src/vec/vec/impls/nest/vecnest.c
> >> [0]PETSC ERROR: #2 VecCopy() line 1614 in
> >> /opt/PETSc_library/petsc-3.11.0/src/vec/vec/interface/vector.c
> >> [0]PETSC ERROR: #3 KSPInitialResidual() line 63 in
> >> /opt/PETSc_library/petsc-3.11.0/src/ksp/ksp/interface/itres.c
> >> [0]PETSC ERROR: #4 KSPSolve_GMRES() line 236 in
> >> /opt/PETSc_library/petsc-3.11.0/src/ksp/ksp/impls/gmres/gmres.c
> >> [0]PETSC ERROR: #5 KSPSolve() line 782 in
> >> /opt/PETSc_library/petsc-3.11.0/src/ksp/ksp/interface/itfunc.c
> >> [0]PETSC ERROR: #6 mwe() line 55 in ../Tests/tests.c
> >>
> >> Please find attached a MWE (it is a slight modification of that of the
> >> post opened by Ce Qin,
> >>
> https://lists.mcs.anl.gov/pipermail/petsc-users/2015-February/024230.html,
>
> >> whose answer I have not found).
> >>
> >> By the way, with the newest version of PETSc, Eclipse marks as errors
> >> the commands PetscFree, CHKERRQ, PETSC_COMM_SELF,... although it
> >> compiles and executes well. Perhaps it is a problem related to Eclipse,
> >> but this did not happen with the older versions of PETSc.
> >>
> >> Thanks and regards,
> >>
> >> Manuel
> >>
> >> ---
> >>
> >>
> >>
> >> --
> >> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which their
> experiments lead.
> >> -- Norbert Wiener
> >>
> >> https://www.cse.buffalo.edu/~knepley/
>
>

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20190411/5b9a713f/attachment-0001.html>