On Mon, Jan 2, 2017 at 7:29 PM, Jed Brown <[email protected]> wrote: > Barry Smith <[email protected]> writes: > > > How about MatSetCoordindates(Mat, Vec). > > This would assume an interpolatory basis for which each Mat (row?)bs > corresponds to one Vec bs. Should we consider mixed spaces? >
I think none of this helps enough. You should have an easy object at hand to provide the information, and fallback to something easy like interpolatory when that is absent. Preferably, the object we use should only know about sets of dofs, just like we have for FieldSplit. Matt > > Then MatNullSpaceCreateRigidBody(Mat, MatNullSpace *); > > Perhaps something like this as a convenience, but I think it can be > useful to call the current function without first creating a Mat to > attach the coordinate Vec to. > > > Then presumable GAMG can pass the appropriated coordinates down to > the smaller matrices it creates internally and create the rigid body null > spaces it wants as it moves to the smaller matrices? > > > > Barry > > > > > > You could have a MatGetCoordindates(Mat, Vec) and not change the calling > sequence of MatNullSpaceCreateRigidBody() but I like the first alternative > I suggested. > > > > > >> On Jan 2, 2017, at 5:23 PM, Jed Brown <[email protected]> wrote: > >> > >> Mark Adams <[email protected]> writes: > >> > >>> On Mon, Jan 2, 2017 at 11:47 AM, Jed Brown <[email protected]> wrote: > >>> > >>>> Jeremy Theler <[email protected]> writes: > >>>> > >>>>> Hi all > >>>>> > >>>>> I want to check that the near nullspace I provide to GAMG gives > "almost > >>>>> null vectors" when multiplying each vector in the near nullspace > against > >>>>> the matrix problem. > >>>>> > >>>>> This way I can check that the unknown ordering I am using is > consistent, > >>>>> for example using by MatNullSpaceCreateRigidBody() or by computing > the > >>>>> nullspace by myself. > >>>> > >>>> Please use that and MatSetNearNullSpace(). It composes properly and > you > >>>> can check everything. > >>>> > >>>> PCSetCoordinates() happens to do double-duty for aggregation-based > >>>> methods, but outside of semi-geometric methods, it is just ugly code > >>>> duplication and makes assumptions that may be inappropriate (like > >>>> elasticity with an interpolatory basis). > >>> > >>> > >>> Yes, PCSetCoordinates is an old interface that is essentially > deprecated. > >>> Maybe we should officially deprecated this. > >> > >> I think we should officially deprecate it, but perhaps make something > >> more general available as a Mat function (since some algorithms may use > >> coordinates directly). (Needing to dig up a PC to provide problem (as > >> opposed to configuration) information is bad style.) > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener
