<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Feb 25, 2017 at 7:35 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</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>
>      Do you think this is a reasonable approach or am I missing<br>
>      something fundamental? I am assuming generally for the "higher<br>
>      order" DM the Mat it returns is a MATSHELL or a new matrix class<br>
>      built on "tensor contractions" and that kind of nonsense. I don't<br>
>      want to do all the coding and then have it turn out that it is<br>
>      totally useless for CEED etc.<br>
<br>
Well, this is exactly what we do in pTatin.<br>
<br>
I would ask, why just two discretizations?  I've always thought a better<br>
interface would be for Mats (and any other operators/functions) to have<br>
optional approximations or supplementary data attached.  We can do this<br>
with PetscObjectCompose, but that's hard to work with in a structured<br>
way.  Anyway, I think I would rather just have the Amat with ability to<br>
attach one or more Pmats.<br>
</blockquote></div><br>I think that would be more convincing with a concrete use case example. Right now</div><div class="gmail_extra">it sounds more like a additional complication for not much extra functionality, but</div><div class="gmail_extra">maybe that is because I cannot think of when I would use it.</div><div class="gmail_extra"><br></div><div class="gmail_extra">  Matt<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>