February 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] [petsc-users] VECMPICUSP with ghosted vector
by Barry Smith 06 Feb '12

06 Feb '12

On Feb 6, 2012, at 1:39 PM, Matthew Knepley wrote: > On Mon, Feb 6, 2012 at 1:30 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Feb 6, 2012, at 1:27 PM, Matthew Knepley wrote: > > > On Mon, Feb 6, 2012 at 1:23 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > On Feb 6, 2012, at 1:14 PM, Matthew Knepley wrote: > > > > > On Mon, Feb 6, 2012 at 1:11 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > > On Feb 6, 2012, at 12:47 PM, Jed Brown wrote: > > > > > > > On Mon, Feb 6, 2012 at 21:42, Matthew Knepley <knepley(a)gmail.com> wrote: > > > > I don't like this because it would mean calling VecSetUp() all over the place. Couldn't the ghosting flag be on the same > > > > level as the sizes? > > > > > > > > Maybe VecSetUp() is wrong because that would imply collective. This memory allocation is simple and need not be collective. > > > > > > > > Ghosting information is an array, so placing it in VecSetSizes() would seem unnatural to me. I wouldn't really want VecSetGhosts(Vec,PetscInt,const PetscInt*) to be order-dependent with respect to VecSetType(), but maybe the VecSetUp() would be too messy. > > > > > > Only some vectors support ghosting, so the usual PETSc way (like with KSPGMRESRestart()) is to calling the specific setting routines ONLY AFTER the type has been set. Otherwise all kinds of oddball type specific stuff needs to be cached in the object and then pulled out later; possible but is that desirable? Who decides what can be set before the type and what can be set after? Having a single rule, anything appropriate for a subset of the types must be set after the type is set is a nice simple model. > > > > > > On the other hand you could argue that ALL vector types should support ghosting as a natural thing (with sequential vectors just have 0 length ghosts conceptually) then it would be desirable to allow setting the ghost information in any ordering. > > > > > > I will argue this. > > > > Ok, then just like VecSetSizes() we stash this information if given before the type is set and use it when the type is set. However if it is set after the type is set (and after the sizes are set) then we need to destroy the old datastructure and build a new one which means messier code. By instead actually allocating the data structure at VecSetUp() the code is cleaner because we never need to take down and rebuild a data structure and yet order doesn't matter. Users WILL need to call VecSetUp() before VecSetValues() and possibly a few other things like they do with Mat now. > > > > We just disallow setting it after the type, just like sizes. I don't see the argument against this. > > We allow setting the sizes after the type. > > Okay, so the current semantics are: VecSetSizes() wipes out the old Vec and creates one of the right size. No, if the vector has already been built then VecSetSizes() errors out; it does not build a vector of the new size. If the vector type has been set but the sizes not set then VecSetSizes() triggers actually building the data structures. Barry > I am fine > with that, and would just add a ghost size. I don't think this complicates what is already there much at all. > > Matt > > > > > > Matt > > > > > > Barry > > > > > > > > Sadly we now pretty much require MatSetUp() or a MatXXXSetPreallocation() to be called so why not always have VecSetUp() always called? > > > > > > Because I don't think we need it and it is snother layer of complication for the user and us. I think > > > we could make it work where it was called automatically when necessary, but that adds another > > > headache for maintenance and extension. > > > > > > Matt > > > > > > We have not converged yet, > > > > > > Barry > > > > > > > > > > > > > > > > > > -- > > > 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 > > > > > > > > > > -- > > 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 > > > > > -- > 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

1 0

Re: [petsc-dev] [petsc-users] VECMPICUSP with ghosted vector
by Dmitry Karpeev 06 Feb '12

06 Feb '12

On Mon, Feb 6, 2012 at 1:30 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Feb 6, 2012, at 1:27 PM, Matthew Knepley wrote: > > > On Mon, Feb 6, 2012 at 1:23 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > On Feb 6, 2012, at 1:14 PM, Matthew Knepley wrote: > > > > > On Mon, Feb 6, 2012 at 1:11 PM, Barry Smith <bsmith(a)mcs.anl.gov> > wrote: > > > > > > On Feb 6, 2012, at 12:47 PM, Jed Brown wrote: > > > > > > > On Mon, Feb 6, 2012 at 21:42, Matthew Knepley <knepley(a)gmail.com> > wrote: > > > > I don't like this because it would mean calling VecSetUp() all over > the place. Couldn't the ghosting flag be on the same > > > > level as the sizes? > > > > > > > > Maybe VecSetUp() is wrong because that would imply collective. This > memory allocation is simple and need not be collective. > > > > > > > > Ghosting information is an array, so placing it in VecSetSizes() > would seem unnatural to me. I wouldn't really want > VecSetGhosts(Vec,PetscInt,const PetscInt*) to be order-dependent with > respect to VecSetType(), but maybe the VecSetUp() would be too messy. > > > > > > Only some vectors support ghosting, so the usual PETSc way (like > with KSPGMRESRestart()) is to calling the specific setting routines ONLY > AFTER the type has been set. Otherwise all kinds of oddball type specific > stuff needs to be cached in the object and then pulled out later; possible > but is that desirable? Who decides what can be set before the type and what > can be set after? Having a single rule, anything appropriate for a subset > of the types must be set after the type is set is a nice simple model. > > > > > > On the other hand you could argue that ALL vector types should > support ghosting as a natural thing (with sequential vectors just have 0 > length ghosts conceptually) then it would be desirable to allow setting the > ghost information in any ordering. > > > > > > I will argue this. > > > > Ok, then just like VecSetSizes() we stash this information if given > before the type is set and use it when the type is set. However if it is > set after the type is set (and after the sizes are set) then we need to > destroy the old datastructure and build a new one which means messier code. > By instead actually allocating the data structure at VecSetUp() the code > is cleaner because we never need to take down and rebuild a data structure > and yet order doesn't matter. Users WILL need to call VecSetUp() before > VecSetValues() and possibly a few other things like they do with Mat now. > > > > We just disallow setting it after the type, just like sizes. I don't see > the argument against this. > > We allow setting the sizes after the type. > Since we are on a related subject: should then all type-specific processing of sizes be moved out of MatSetSizes() into MatSetUp? By this I mean this code: if (A->ops->setsizes) { /* Since this will not be set until the type has been set, this will NOT be called on the initial call of MatSetSizes() (which must be called BEFORE MatSetType() */ ierr = (*A->ops->setsizes)(A,m,n,M,N);CHKERRQ(ierr); } else { This eliminates the need to check for the presence of various type-specific setup methods -- they will all be called in MatSetUp after the type is guaranteed to have been set. This would also make MatSetSizes not collective. I imagine that Vec could be organized the same way. I actually would prefer VecSetUp to explicitly delineate the end of the "factory" phase. Dmitry. > > > > > > Matt > > > > > > Barry > > > > > > > > Sadly we now pretty much require MatSetUp() or a > MatXXXSetPreallocation() to be called so why not always have VecSetUp() > always called? > > > > > > Because I don't think we need it and it is snother layer of > complication for the user and us. I think > > > we could make it work where it was called automatically when > necessary, but that adds another > > > headache for maintenance and extension. > > > > > > Matt > > > > > > We have not converged yet, > > > > > > Barry > > > > > > > > > > > > > > > > > > -- > > > 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 > > > > > > > > > > -- > > 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 > >

1 0

Re: [petsc-dev] [petsc-users] VECMPICUSP with ghosted vector
by Matthew Knepley 06 Feb '12

06 Feb '12

On Mon, Feb 6, 2012 at 1:30 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Feb 6, 2012, at 1:27 PM, Matthew Knepley wrote: > > > On Mon, Feb 6, 2012 at 1:23 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > On Feb 6, 2012, at 1:14 PM, Matthew Knepley wrote: > > > > > On Mon, Feb 6, 2012 at 1:11 PM, Barry Smith <bsmith(a)mcs.anl.gov> > wrote: > > > > > > On Feb 6, 2012, at 12:47 PM, Jed Brown wrote: > > > > > > > On Mon, Feb 6, 2012 at 21:42, Matthew Knepley <knepley(a)gmail.com> > wrote: > > > > I don't like this because it would mean calling VecSetUp() all over > the place. Couldn't the ghosting flag be on the same > > > > level as the sizes? > > > > > > > > Maybe VecSetUp() is wrong because that would imply collective. This > memory allocation is simple and need not be collective. > > > > > > > > Ghosting information is an array, so placing it in VecSetSizes() > would seem unnatural to me. I wouldn't really want > VecSetGhosts(Vec,PetscInt,const PetscInt*) to be order-dependent with > respect to VecSetType(), but maybe the VecSetUp() would be too messy. > > > > > > Only some vectors support ghosting, so the usual PETSc way (like > with KSPGMRESRestart()) is to calling the specific setting routines ONLY > AFTER the type has been set. Otherwise all kinds of oddball type specific > stuff needs to be cached in the object and then pulled out later; possible > but is that desirable? Who decides what can be set before the type and what > can be set after? Having a single rule, anything appropriate for a subset > of the types must be set after the type is set is a nice simple model. > > > > > > On the other hand you could argue that ALL vector types should > support ghosting as a natural thing (with sequential vectors just have 0 > length ghosts conceptually) then it would be desirable to allow setting the > ghost information in any ordering. > > > > > > I will argue this. > > > > Ok, then just like VecSetSizes() we stash this information if given > before the type is set and use it when the type is set. However if it is > set after the type is set (and after the sizes are set) then we need to > destroy the old datastructure and build a new one which means messier code. > By instead actually allocating the data structure at VecSetUp() the code > is cleaner because we never need to take down and rebuild a data structure > and yet order doesn't matter. Users WILL need to call VecSetUp() before > VecSetValues() and possibly a few other things like they do with Mat now. > > > > We just disallow setting it after the type, just like sizes. I don't see > the argument against this. > > We allow setting the sizes after the type. Okay, so the current semantics are: VecSetSizes() wipes out the old Vec and creates one of the right size. I am fine with that, and would just add a ghost size. I don't think this complicates what is already there much at all. Matt > > > > > Matt > > > > > > Barry > > > > > > > > Sadly we now pretty much require MatSetUp() or a > MatXXXSetPreallocation() to be called so why not always have VecSetUp() > always called? > > > > > > Because I don't think we need it and it is snother layer of > complication for the user and us. I think > > > we could make it work where it was called automatically when > necessary, but that adds another > > > headache for maintenance and extension. > > > > > > Matt > > > > > > We have not converged yet, > > > > > > Barry > > > > > > > > > > > > > > > > > > -- > > > 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 > > > > > > > > > > -- > > 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 > > -- 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

1 0

Re: [petsc-dev] [petsc-users] VECMPICUSP with ghosted vector
by Barry Smith 06 Feb '12

06 Feb '12

On Feb 6, 2012, at 1:27 PM, Matthew Knepley wrote: > On Mon, Feb 6, 2012 at 1:23 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Feb 6, 2012, at 1:14 PM, Matthew Knepley wrote: > > > On Mon, Feb 6, 2012 at 1:11 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > On Feb 6, 2012, at 12:47 PM, Jed Brown wrote: > > > > > On Mon, Feb 6, 2012 at 21:42, Matthew Knepley <knepley(a)gmail.com> wrote: > > > I don't like this because it would mean calling VecSetUp() all over the place. Couldn't the ghosting flag be on the same > > > level as the sizes? > > > > > > Maybe VecSetUp() is wrong because that would imply collective. This memory allocation is simple and need not be collective. > > > > > > Ghosting information is an array, so placing it in VecSetSizes() would seem unnatural to me. I wouldn't really want VecSetGhosts(Vec,PetscInt,const PetscInt*) to be order-dependent with respect to VecSetType(), but maybe the VecSetUp() would be too messy. > > > > Only some vectors support ghosting, so the usual PETSc way (like with KSPGMRESRestart()) is to calling the specific setting routines ONLY AFTER the type has been set. Otherwise all kinds of oddball type specific stuff needs to be cached in the object and then pulled out later; possible but is that desirable? Who decides what can be set before the type and what can be set after? Having a single rule, anything appropriate for a subset of the types must be set after the type is set is a nice simple model. > > > > On the other hand you could argue that ALL vector types should support ghosting as a natural thing (with sequential vectors just have 0 length ghosts conceptually) then it would be desirable to allow setting the ghost information in any ordering. > > > > I will argue this. > > Ok, then just like VecSetSizes() we stash this information if given before the type is set and use it when the type is set. However if it is set after the type is set (and after the sizes are set) then we need to destroy the old datastructure and build a new one which means messier code. By instead actually allocating the data structure at VecSetUp() the code is cleaner because we never need to take down and rebuild a data structure and yet order doesn't matter. Users WILL need to call VecSetUp() before VecSetValues() and possibly a few other things like they do with Mat now. > > We just disallow setting it after the type, just like sizes. I don't see the argument against this. We allow setting the sizes after the type. > > Matt > > > Barry > > > > > Sadly we now pretty much require MatSetUp() or a MatXXXSetPreallocation() to be called so why not always have VecSetUp() always called? > > > > Because I don't think we need it and it is snother layer of complication for the user and us. I think > > we could make it work where it was called automatically when necessary, but that adds another > > headache for maintenance and extension. > > > > Matt > > > > We have not converged yet, > > > > Barry > > > > > > > > > > > > -- > > 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 > > > > > -- > 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

1 0

Re: [petsc-dev] [petsc-users] VECMPICUSP with ghosted vector
by Matthew Knepley 06 Feb '12

06 Feb '12

On Mon, Feb 6, 2012 at 1:23 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Feb 6, 2012, at 1:14 PM, Matthew Knepley wrote: > > > On Mon, Feb 6, 2012 at 1:11 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > On Feb 6, 2012, at 12:47 PM, Jed Brown wrote: > > > > > On Mon, Feb 6, 2012 at 21:42, Matthew Knepley <knepley(a)gmail.com> > wrote: > > > I don't like this because it would mean calling VecSetUp() all over > the place. Couldn't the ghosting flag be on the same > > > level as the sizes? > > > > > > Maybe VecSetUp() is wrong because that would imply collective. This > memory allocation is simple and need not be collective. > > > > > > Ghosting information is an array, so placing it in VecSetSizes() would > seem unnatural to me. I wouldn't really want > VecSetGhosts(Vec,PetscInt,const PetscInt*) to be order-dependent with > respect to VecSetType(), but maybe the VecSetUp() would be too messy. > > > > Only some vectors support ghosting, so the usual PETSc way (like with > KSPGMRESRestart()) is to calling the specific setting routines ONLY AFTER > the type has been set. Otherwise all kinds of oddball type specific stuff > needs to be cached in the object and then pulled out later; possible but is > that desirable? Who decides what can be set before the type and what can be > set after? Having a single rule, anything appropriate for a subset of the > types must be set after the type is set is a nice simple model. > > > > On the other hand you could argue that ALL vector types should support > ghosting as a natural thing (with sequential vectors just have 0 length > ghosts conceptually) then it would be desirable to allow setting the ghost > information in any ordering. > > > > I will argue this. > > Ok, then just like VecSetSizes() we stash this information if given > before the type is set and use it when the type is set. However if it is > set after the type is set (and after the sizes are set) then we need to > destroy the old datastructure and build a new one which means messier code. > By instead actually allocating the data structure at VecSetUp() the code > is cleaner because we never need to take down and rebuild a data structure > and yet order doesn't matter. Users WILL need to call VecSetUp() before > VecSetValues() and possibly a few other things like they do with Mat now. We just disallow setting it after the type, just like sizes. I don't see the argument against this. Matt > > Barry > > > > > Sadly we now pretty much require MatSetUp() or a > MatXXXSetPreallocation() to be called so why not always have VecSetUp() > always called? > > > > Because I don't think we need it and it is snother layer of complication > for the user and us. I think > > we could make it work where it was called automatically when necessary, > but that adds another > > headache for maintenance and extension. > > > > Matt > > > > We have not converged yet, > > > > Barry > > > > > > > > > > > > -- > > 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 > > -- 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

1 0

Re: [petsc-dev] [petsc-users] VECMPICUSP with ghosted vector
by Barry Smith 06 Feb '12

06 Feb '12

On Feb 6, 2012, at 1:14 PM, Matthew Knepley wrote: > On Mon, Feb 6, 2012 at 1:11 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Feb 6, 2012, at 12:47 PM, Jed Brown wrote: > > > On Mon, Feb 6, 2012 at 21:42, Matthew Knepley <knepley(a)gmail.com> wrote: > > I don't like this because it would mean calling VecSetUp() all over the place. Couldn't the ghosting flag be on the same > > level as the sizes? > > > > Maybe VecSetUp() is wrong because that would imply collective. This memory allocation is simple and need not be collective. > > > > Ghosting information is an array, so placing it in VecSetSizes() would seem unnatural to me. I wouldn't really want VecSetGhosts(Vec,PetscInt,const PetscInt*) to be order-dependent with respect to VecSetType(), but maybe the VecSetUp() would be too messy. > > Only some vectors support ghosting, so the usual PETSc way (like with KSPGMRESRestart()) is to calling the specific setting routines ONLY AFTER the type has been set. Otherwise all kinds of oddball type specific stuff needs to be cached in the object and then pulled out later; possible but is that desirable? Who decides what can be set before the type and what can be set after? Having a single rule, anything appropriate for a subset of the types must be set after the type is set is a nice simple model. > > On the other hand you could argue that ALL vector types should support ghosting as a natural thing (with sequential vectors just have 0 length ghosts conceptually) then it would be desirable to allow setting the ghost information in any ordering. > > I will argue this. Ok, then just like VecSetSizes() we stash this information if given before the type is set and use it when the type is set. However if it is set after the type is set (and after the sizes are set) then we need to destroy the old datastructure and build a new one which means messier code. By instead actually allocating the data structure at VecSetUp() the code is cleaner because we never need to take down and rebuild a data structure and yet order doesn't matter. Users WILL need to call VecSetUp() before VecSetValues() and possibly a few other things like they do with Mat now. Barry > > Sadly we now pretty much require MatSetUp() or a MatXXXSetPreallocation() to be called so why not always have VecSetUp() always called? > > Because I don't think we need it and it is snother layer of complication for the user and us. I think > we could make it work where it was called automatically when necessary, but that adds another > headache for maintenance and extension. > > Matt > > We have not converged yet, > > Barry > > > > > > -- > 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

1 0

Re: [petsc-dev] [petsc-users] VECMPICUSP with ghosted vector
by Matthew Knepley 06 Feb '12

06 Feb '12

On Mon, Feb 6, 2012 at 1:11 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Feb 6, 2012, at 12:47 PM, Jed Brown wrote: > > > On Mon, Feb 6, 2012 at 21:42, Matthew Knepley <knepley(a)gmail.com> wrote: > > I don't like this because it would mean calling VecSetUp() all over the > place. Couldn't the ghosting flag be on the same > > level as the sizes? > > > > Maybe VecSetUp() is wrong because that would imply collective. This > memory allocation is simple and need not be collective. > > > > Ghosting information is an array, so placing it in VecSetSizes() would > seem unnatural to me. I wouldn't really want > VecSetGhosts(Vec,PetscInt,const PetscInt*) to be order-dependent with > respect to VecSetType(), but maybe the VecSetUp() would be too messy. > > Only some vectors support ghosting, so the usual PETSc way (like with > KSPGMRESRestart()) is to calling the specific setting routines ONLY AFTER > the type has been set. Otherwise all kinds of oddball type specific stuff > needs to be cached in the object and then pulled out later; possible but is > that desirable? Who decides what can be set before the type and what can be > set after? Having a single rule, anything appropriate for a subset of the > types must be set after the type is set is a nice simple model. > > On the other hand you could argue that ALL vector types should support > ghosting as a natural thing (with sequential vectors just have 0 length > ghosts conceptually) then it would be desirable to allow setting the ghost > information in any ordering. > I will argue this. > Sadly we now pretty much require MatSetUp() or a > MatXXXSetPreallocation() to be called so why not always have VecSetUp() > always called? > Because I don't think we need it and it is snother layer of complication for the user and us. I think we could make it work where it was called automatically when necessary, but that adds another headache for maintenance and extension. Matt > We have not converged yet, > > Barry > > > -- 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

1 0

Re: [petsc-dev] [petsc-users] VECMPICUSP with ghosted vector
by Barry Smith 06 Feb '12

06 Feb '12

On Feb 6, 2012, at 12:47 PM, Jed Brown wrote: > On Mon, Feb 6, 2012 at 21:42, Matthew Knepley <knepley(a)gmail.com> wrote: > I don't like this because it would mean calling VecSetUp() all over the place. Couldn't the ghosting flag be on the same > level as the sizes? > > Maybe VecSetUp() is wrong because that would imply collective. This memory allocation is simple and need not be collective. > > Ghosting information is an array, so placing it in VecSetSizes() would seem unnatural to me. I wouldn't really want VecSetGhosts(Vec,PetscInt,const PetscInt*) to be order-dependent with respect to VecSetType(), but maybe the VecSetUp() would be too messy. Only some vectors support ghosting, so the usual PETSc way (like with KSPGMRESRestart()) is to calling the specific setting routines ONLY AFTER the type has been set. Otherwise all kinds of oddball type specific stuff needs to be cached in the object and then pulled out later; possible but is that desirable? Who decides what can be set before the type and what can be set after? Having a single rule, anything appropriate for a subset of the types must be set after the type is set is a nice simple model. On the other hand you could argue that ALL vector types should support ghosting as a natural thing (with sequential vectors just have 0 length ghosts conceptually) then it would be desirable to allow setting the ghost information in any ordering. Sadly we now pretty much require MatSetUp() or a MatXXXSetPreallocation() to be called so why not always have VecSetUp() always called? We have not converged yet, Barry

1 0

Re: [petsc-dev] [petsc-users] VECMPICUSP with ghosted vector
by Matthew Knepley 06 Feb '12

06 Feb '12

On Mon, Feb 6, 2012 at 12:47 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Mon, Feb 6, 2012 at 21:42, Matthew Knepley <knepley(a)gmail.com> wrote: > >> I don't like this because it would mean calling VecSetUp() all over the >> place. Couldn't the ghosting flag be on the same >> level as the sizes? >> > > Maybe VecSetUp() is wrong because that would imply collective. This memory > allocation is simple and need not be collective. > > Ghosting information is an array, so placing it in VecSetSizes() would > seem unnatural to me. I wouldn't really want > VecSetGhosts(Vec,PetscInt,const PetscInt*) to be order-dependent with > respect to VecSetType(), but maybe the VecSetUp() would be too messy. > I needed to be more specific. I think VecSetSizes(local, global, ghost) would work. Then VecSetGhostIndices() can be called anytime, and even remapped. Matt -- 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

1 0

Re: [petsc-dev] [petsc-users] VECMPICUSP with ghosted vector
by Jed Brown 06 Feb '12

06 Feb '12

On Mon, Feb 6, 2012 at 21:42, Matthew Knepley <knepley(a)gmail.com> wrote: > I don't like this because it would mean calling VecSetUp() all over the > place. Couldn't the ghosting flag be on the same > level as the sizes? > Maybe VecSetUp() is wrong because that would imply collective. This memory allocation is simple and need not be collective. Ghosting information is an array, so placing it in VecSetSizes() would seem unnatural to me. I wouldn't really want VecSetGhosts(Vec,PetscInt,const PetscInt*) to be order-dependent with respect to VecSetType(), but maybe the VecSetUp() would be too messy.

1 0