<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 2, 2017 at 7:29 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> writes:<br>
<br>
>     How about MatSetCoordindates(Mat, Vec).<br>
<br>
This would assume an interpolatory basis for which each Mat (row?)bs<br>
corresponds to one Vec bs.  Should we consider mixed spaces?<br></blockquote><div><br></div><div>I think none of this helps enough. You should have an easy object at hand to provide the information,</div><div>and fallback to something easy like interpolatory when that is absent. Preferably, the object we use</div><div>should only know about sets of dofs, just like we have for FieldSplit.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>     Then MatNullSpaceCreateRigidBody(<wbr>Mat, MatNullSpace *);<br>
<br>
Perhaps something like this as a convenience, but I think it can be<br>
useful to call the current function without first creating a Mat to<br>
attach the coordinate Vec to.<br>
<br>
>     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?<br>
><br>
>    Barry<br>
><br>
><br>
> You could have a MatGetCoordindates(Mat, Vec) and not change the calling sequence of MatNullSpaceCreateRigidBody() but I like the first alternative I suggested.<br>
><br>
><br>
>> On Jan 2, 2017, at 5:23 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
>><br>
>> Mark Adams <<a href="mailto:mfadams@lbl.gov">mfadams@lbl.gov</a>> writes:<br>
>><br>
>>> On Mon, Jan 2, 2017 at 11:47 AM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
>>><br>
>>>> Jeremy Theler <<a href="mailto:jeremy@seamplex.com">jeremy@seamplex.com</a>> writes:<br>
>>>><br>
>>>>> Hi all<br>
>>>>><br>
>>>>> I want to check that the near nullspace I provide to GAMG gives "almost<br>
>>>>> null vectors" when multiplying each vector in the near nullspace against<br>
>>>>> the matrix problem.<br>
>>>>><br>
>>>>> This way I can check that the unknown ordering I am using is consistent,<br>
>>>>> for example using by MatNullSpaceCreateRigidBody() or by computing the<br>
>>>>> nullspace by myself.<br>
>>>><br>
>>>> Please use that and MatSetNearNullSpace().  It composes properly and you<br>
>>>> can check everything.<br>
>>>><br>
>>>> PCSetCoordinates() happens to do double-duty for aggregation-based<br>
>>>> methods, but outside of semi-geometric methods, it is just ugly code<br>
>>>> duplication and makes assumptions that may be inappropriate (like<br>
>>>> elasticity with an interpolatory basis).<br>
>>><br>
>>><br>
>>> Yes, PCSetCoordinates is an old interface that is essentially deprecated.<br>
>>> Maybe we should officially deprecated this.<br>
>><br>
>> I think we should officially deprecate it, but perhaps make something<br>
>> more general available as a Mat function (since some algorithms may use<br>
>> coordinates directly).  (Needing to dig up a PC to provide problem (as<br>
>> opposed to configuration) information is bad style.)<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>