[petsc-dev] [petsc-users] VECMPICUSP with ghosted vector

[Matthew Knepley]

On Mon, Feb 6, 2012 at 1:42 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
> On Feb 6, 2012, at 1:39 PM, Matthew Knepley wrote:
>
> > On Mon, Feb 6, 2012 at 1:30 PM, Barry Smith <bsmith at 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 at 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 at 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 at 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.


Okay, so this is already confusing. Having SetSizes() store the sizes is
correct, since they are common to every type,
as I think ghosting should be. The weird part is SetSizes() calling SetUp
(actually its equivalent ops->create). I don't
think removing this will break much code since most people rely on SetType
or SetFromOptions.

   Matt


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


-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120206/e0e80b7d/attachment.html>