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 <[email protected]> wrote: >On Wed, Jan 29, 2014 at 11:36 AM, Jed Brown <[email protected]> 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
