[petsc-dev] Ghost update in VecAssembly?
Jed Brown
jed at jedbrown.org
Tue Mar 1 09:50:16 CST 2016
Matthew Knepley <knepley at gmail.com> writes:
> I am trying to understand what you are saying here. I have a vector on 2
> procs, divided as
>
> p0 |----interior---|--ghost--|
>
> p1 |----interior---|--ghost--|
Remember that the global Vec consists of just the interiors. The local
form is a sequential Vec that includes ghosts.
> Now I calculate some values in the interior on both procs using
> VecGetArray(),
>
> p0 |xxxxinteriorxxx|--ghost--|
>
> p1 |xxxxinteriorxxx|--ghost--|
If you do it this way, then the global Vec is complete without needing
to communicate anything.
> What is wrong with calling VecGhostUpdate() here to fill in the
> ghosts?
The ghost values aren't part of the global Vec, so it's just needless
communication. But more insidiously, it encourages an interface where
the input Vec is assumed to have updated ghost values (a "hidden"
property).
> Is your contention that I should have also calculated the ghosts?
No. But if you have a FE discretization then you're presumably using
ADD_VALUES. With VecGhost, the natural thing is to put your entries in
the local form and use VecGhostUpdate(x,ADD_VALUES,SCATTER_REVERSE).
Note that you would need a subsequent
VecGhostUpdate(x,INSERT_VALUES,SCATTER_FORWARD) if you wanted the local
form to be consistent with the now-assembled global form. But the
algebraic solvers don't need that, so it's only relevant if user code
will be called on that Vec prior to modification of any type by the
algebraic solver, and having user code assume the ghost values are
current is a dangerous assumption that will make your code fragile and
disgusting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20160301/ff86f935/attachment.sig>
More information about the petsc-dev
mailing list