<p>Yes, see also</p><p><a href="http://www.mail-archive.com/libmesh-devel@lists.sourceforge.net/msg02047.html">http://www.mail-archive.com/libmesh-devel@lists.sourceforge.net/msg02047.html</a></p><p><a href="http://www.mail-archive.com/libmesh-devel@lists.sourceforge.net/msg01141.html">http://www.mail-archive.com/libmesh-devel@lists.sourceforge.net/msg01141.html</a></p>
<p>On Oct 17, 2011 9:29 PM, "Vijay S. Mahadevan" <<a href="mailto:vijay.m@gmail.com" target="_blank">vijay.m@gmail.com</a>> wrote:</p><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<a href="http://www.mail-archive.com/libmesh-devel@lists.sourceforge.net/msg02100.html" target="_blank">http://www.mail-archive.com/libmesh-devel@lists.sourceforge.net/msg02100.html</a> ??<br>
<br>
On Mon, Oct 17, 2011 at 9:25 PM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>> wrote:<br>
> We discussed Vec local/global semantics on the libmesh list a year ago or<br>
> more. I didn't think there was a failing in the current system, but libmesh<br>
> imposes some stricter consistency on local vectors, which sometimes causes<br>
> unnecessary communication. I don't recall all the details, but we can dig up<br>
> the thread.<br>
><br>
> On Oct 17, 2011 9:17 PM, "Vijay S. Mahadevan" <<a href="mailto:vijay.m@gmail.com" target="_blank">vijay.m@gmail.com</a>> wrote:<br>
>><br>
>> > I would not try to simultaneously change the distribution of the Vec.<br>
>> > That's<br>
>> > what VecScatter is for. VecConvert() would keep the same distribution<br>
>> > and<br>
>> > give you back a semantically identical vector of a different type.<br>
>><br>
>> Well, I implied changing the parallel layout because of the code I've<br>
>> seen in say libMesh and other packages using PETSc. Their idea of<br>
>> localize() is often to convert a MPI vector to a locally serial vector<br>
>> with/without ghost nodes. I see your point on using VecScatter and so<br>
>> VECSEQ can still be disallowed but some form of Ghosted parallel<br>
>> vector conversion would still be useful.<br>
>><br>
>> On Mon, Oct 17, 2011 at 9:00 PM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>> wrote:<br>
>> > On Mon, Oct 17, 2011 at 20:55, Vijay S. Mahadevan <<a href="mailto:vijay.m@gmail.com" target="_blank">vijay.m@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Actually, that is quite consistent in philosophy to the merge<br>
>> >> operation I'm trying to perform. SEQ->MPI might still be an invalid<br>
>> >> operation for Vec though. Perhaps with a PETSC_DECIDE for local, it<br>
>> >> still could be relevant ? You can definitely specialize this for<br>
>> >> MPI->SEQ and Nest Vectors with a new VecReuse enum with relevant<br>
>> >> names.<br>
>> ><br>
>> > I would not try to simultaneously change the distribution of the Vec.<br>
>> > That's<br>
>> > what VecScatter is for. VecConvert() would keep the same distribution<br>
>> > and<br>
>> > give you back a semantically identical vector of a different type.<br>
><br>
</blockquote></div>