[petsc-dev] getting data out of a PetscFE simulation

[Jed Brown]

Local vectors are supposed to be just that: local. VecViewing a local vector and expecting it to be parallel is perverse.  So we need a real interface.

Placing 1.0 on the diagonal (and don't assemble into those rows and columns) is the common way to deal with Dirichlet boundary nodes. See ex48 for one example. I have written about this in a few places; I can find the more complete description when I have a keyboard.

On January 29, 2014 12:53:26 PM MST, Geoffrey Irving <irving at naml.us> wrote:
>On Wed, Jan 29, 2014 at 11:36 AM, Jed Brown <jed at jedbrown.org> wrote:
>> Matt's sample code doesn't set it either. We need to fix (and the
>*only* acceptable fix if that VecView always does the right thing,
>because we have to be able to call it in analysis settings that know
>nothing about your discretization).
>
>Matt's sample code doesn't set it either, but for Matt's sample code I
>know where to insert the one line call to DMPlexProjectFunctionLocal.
>For your version I never have explicit access to the local vector, so
>I can't insert the fix.
>
>> The problem is that some vectors reside in a homogeneous space (e.g.
>increments and eigenvectors) while others reside in the inhomogeneous
>space (solutions). We can add a flag or BC attribute on the vector to
>this effect, but this (and slip conditions) was the issue that led me
>to conclude that removing boundary nodes was mostly a false economy.
>
>To leave the boundary conditions in, we would need efficient support
>for a very large, very sparse MatNullSpace.  This is doable via
>shells, but is it easy to do in a way that doesn't interfere with the
>user's other null spaces?
>
>Geoffrey