[petsc-users] getting the near nullspace from PCSetCoordinates

[Barry Smith]

> On Jan 2, 2017, at 7:29 PM, Jed Brown <jed at jedbrown.org> wrote:
> 
> Barry Smith <bsmith at mcs.anl.gov> 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?

  Of course.  
> 
>>    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 <jed at jedbrown.org> wrote:
>>> 
>>> Mark Adams <mfadams at lbl.gov> writes:
>>> 
>>>> On Mon, Jan 2, 2017 at 11:47 AM, Jed Brown <jed at jedbrown.org> wrote:
>>>> 
>>>>> Jeremy Theler <jeremy at seamplex.com> 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.)