[petsc-users] Error with KSPSetUp and MatNest
Manuel Colera Rico
m.colera at upm.es
Thu Apr 11 04:57:33 CDT 2019
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:
Mat A;
Mat matA[] = {A00, A01, NULL, A11};
MatCreateNest(PETSC_COMM_SELF, 2, NULL, 2, NULL, matA, &A);
without worrying about memory preallocations for A. Can I do the same
with MatCreateLocalRef(), or do I first have to preallocate memory for A?
Manuel
---
On 4/11/19 11:30 AM, Matthew Knepley wrote:
> On Thu, Apr 11, 2019 at 2:07 AM Smith, Barry F. <bsmith at mcs.anl.gov
> <mailto: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 <mailto: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
> <mailto: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/da2c0993/attachment.html>
More information about the petsc-users
mailing list