http://www.mail-archive.com/libmesh-devel at lists.sourceforge.net/msg02100.html ??
On Mon, Oct 17, 2011 at 9:25 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote: > 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. >
