On Thu, Apr 11, 2019 at 2:07 AM Smith, Barry F.
<bsm...@mcs.anl.gov <mailto:bsm...@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@mcs.anl.gov
<mailto:petsc-users@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@mcs.anl.gov
<mailto:petsc-users@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/>
