Re: [Libmesh-devel] [PATCH] PETSc-dev API change to MatGetSubMatrix()

[Jed B. <je...@59...>]

On Thu, 26 Nov 2009 13:50:23 -0600 (CST), Roy Stogner <roy...@ic...> wrote:

> Is it safe to assume that if we do a VecCopy on an assembled vector,
> the result is assembled

Yes

> and if we do a VecCopy on an unassembled vector

Don't do this.

VecSetValues works as follows:

* values that are owned by this process get inserted immediately

* values that are not owned get put in the "stash", the stash is a very
  private thing and *not* copied by VecCopy

If you can guarantee that you have not set any remote values, then you
aren't strictly [1] required to call VecAssemblyBegin/VecAssemblyEnd
[2], but you will get wrong results if you have set remote values and
don't assemble before using the vector.

PETSc almost never uses VecSetValues internally, it is just offered as a
convenient way to set remote values if the application really needs it
(a lot of examples use it, but it's mostly gratuitous).  If you are
using VecSetValues in a performance-sensitive place, it would be better
to VecGetArray() and index it directly.  Get a "local vector" (including
unowned "ghost" values) if you need to set remote values (as in FEM
function evaluation) and scatter the result.

Jed

[1] This could change in a subsequent release, the API says you have to
    assemble.  This is unlikely to change for performance reasons, but
    it could change to help with debugging.  Actually, I'm adding that
    check to PETSc-dev now, you will now get an error if you try to copy
    an unassembled vector (they are assembled by default, you can only
    get an unassembled Vec by calling VecSetValues/VecSetValuesBlocked.

[2] That call would be practically free anyway.