On Wed, Jan 29, 2014 at 12:00 PM, Jed Brown <[email protected]> wrote: > 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.
I'll look forward to the improved interface. For better or worse, I'd like to be able to view simulations in the near future, so it looks like I have to go with Matt's perverse but working version now. Geoffrey > 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 >
