[petsc-dev] VecNestSetSubVec for VecNest.

[Jed Brown]

We discussed Vec local/global semantics on the libmesh list a year ago or
more. I didn't think there was a failing in the current system, but libmesh
imposes some stricter consistency on local vectors, which sometimes causes
unnecessary communication. I don't recall all the details, but we can dig up
the thread.
On Oct 17, 2011 9:17 PM, "Vijay S. Mahadevan" <vijay.m at gmail.com> wrote:

> > I would not try to simultaneously change the distribution of the Vec.
> That's
> > what VecScatter is for. VecConvert() would keep the same distribution and
> > give you back a semantically identical vector of a different type.
>
> Well, I implied changing the parallel layout because of the code I've
> seen in say libMesh and other packages using PETSc. Their idea of
> localize() is often to convert a MPI vector to a locally serial vector
> with/without ghost nodes. I see your point on using VecScatter and so
> VECSEQ can still be disallowed but some form of Ghosted parallel
> vector conversion would still be useful.
>
> On Mon, Oct 17, 2011 at 9:00 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > On Mon, Oct 17, 2011 at 20:55, Vijay S. Mahadevan <vijay.m at gmail.com>
> wrote:
> >>
> >> Actually, that is quite consistent in philosophy to the merge
> >> operation I'm trying to perform. SEQ->MPI might still be an invalid
> >> operation for Vec though. Perhaps with a PETSC_DECIDE for local, it
> >> still could be relevant ? You can definitely specialize this for
> >> MPI->SEQ and Nest Vectors with a new VecReuse enum with relevant
> >> names.
> >
> > I would not try to simultaneously change the distribution of the Vec.
> That's
> > what VecScatter is for. VecConvert() would keep the same distribution and
> > give you back a semantically identical vector of a different type.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111017/d37f8655/attachment.html>