Re: [petsc-users] segv in VecSum when using nested vec
Could you get a stack trace with gdb? Also, I ran on petsc-dev.
Breakpoint 1, vecsumsegv::vecsumsegv (this=0x7fffffffd310, m=3, n=4) at vecsumsegv.cc:28 28 ierr = VecSum(x,&val); (gdb) next
This was fixed in petsc-dev.
Thanks, I'll switch to petsc-dev for this.
Why are you using VecNest? It causes more harm than good in all but some very special circumstances.
I'm using it to experiment with PETSc's block preconditioners. In short, I have a block matrix for the 2D Stokes eqs with the variables arranged as (u1,...,uN,v1,...,vN,p1,...pN). The matrix has the form A = [Q G, D 0]. I'm using VecCreateNest to assemble the vector x = [u p], just like I use MatCreateNest to assemble the matrix A from the blocks Q, G and D. The index sets are the ones you helped me with in a previous thread (https://lists.mcs.anl.gov/mailman/htdig/petsc-users/2012-February/012262.htm...) dr. ir. Christiaan Klaij CFD Researcher Research & Development E mailto:[email protected] T +31 317 49 33 44 MARIN 2, Haagsteeg, P.O. Box 28, 6700 AA Wageningen, The Netherlands T +31 317 49 39 11, F +31 317 49 32 45, I www.marin.nl
On Wed, Mar 7, 2012 at 1:54 AM, Klaij, Christiaan <[email protected]> wrote:
Could you get a stack trace with gdb? Also, I ran on petsc-dev.
Breakpoint 1, vecsumsegv::vecsumsegv (this=0x7fffffffd310, m=3, n=4) at vecsumsegv.cc:28 28 ierr = VecSum(x,&val); (gdb) next
This was fixed in petsc-dev.
Thanks, I'll switch to petsc-dev for this.
Why are you using VecNest? It causes more harm than good in all but some very special circumstances.
I'm using it to experiment with PETSc's block preconditioners. In short, I have a block matrix for the 2D Stokes eqs with the variables arranged as (u1,...,uN,v1,...,vN,p1,...pN). The matrix has the form A = [Q G, D 0]. I'm using VecCreateNest to assemble the vector x = [u p], just like I use MatCreateNest to assemble the matrix A from the blocks Q, G and D. The index sets are the ones you helped me with in a previous thread ( https://lists.mcs.anl.gov/mailman/htdig/petsc-users/2012-February/012262.htm... )
This is just an optimization for block PCs, and for vectors I think it makes almost no difference. Matt
dr. ir. Christiaan Klaij CFD Researcher Research & Development E mailto:[email protected] T +31 317 49 33 44
MARIN 2, Haagsteeg, P.O. Box 28, 6700 AA Wageningen, The Netherlands T +31 317 49 39 11, F +31 317 49 32 45, I www.marin.nl
-- 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
On Wed, Mar 7, 2012 at 06:53, Matthew Knepley <[email protected]> wrote:
Why are you using VecNest? It causes more harm than good in all but some
very special circumstances.
I'm using it to experiment with PETSc's block preconditioners. In short, I have a block matrix for the 2D Stokes eqs with the variables arranged as (u1,...,uN,v1,...,vN,p1,...pN). The matrix has the form A = [Q G, D 0]. I'm using VecCreateNest to assemble the vector x = [u p], just like I use MatCreateNest to assemble the matrix A from the blocks Q, G and D. The index sets are the ones you helped me with in a previous thread ( https://lists.mcs.anl.gov/mailman/htdig/petsc-users/2012-February/012262.htm... )
This is just an optimization for block PCs, and for vectors I think it makes almost no difference.
Agreed, I recommend using normal Vecs. You can access part of it with VecGetSubVector() if you want to set values for each part separately (it will be no-copy if possible). VecNest only matters if you insist on storing the subvectors as non-contiguous parts of the composite Vec, but also insist on not making copies. Even then, since VecScatter does not have native support for VecNest, there will be some copies in the preconditioner (but they could eventually be supported without copies, note that it's mostly moot because you need a very specialized scenario to make copies account for more than 5% of run-time). So you should basically never use VecNest unless you are really sure that it's the right thing.
participants (3)
-
Jed Brown -
Klaij, Christiaan -
Matthew Knepley