On Mon, Jan 2, 2017 at 8: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 don't see how you do that without getting into discretizations, which is not what we are addressing here and opens a big can of worms. Do we have any users that write their own null space vectors because they are using a non-interpolatory basis? (whatever the heck that is) The setCoordinates thing was put in because this is convenient for a lot of users. And the new matnullspace interface is great but it is just a minor tweak to that interface IMO. Asking users to move over the the MatNullSpace interface is only a few lines, which they can get from ksp/ex56, so not asking much if we are happy with this interface (and it has been stable for years now). > > 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. > Yea, maybe that makes more sense because it is a space and Vec is the space(s). > > > 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.) >
