<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 25, 2016 at 1:43 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">Stefano Zampini <<a href="mailto:stefano.zampini@gmail.com">stefano.zampini@gmail.com</a>> writes:<br>
> MATHYPRE could be a shell wrapping Hypre calls for the moment.<br>
> However, HypreParCSR and MATAIJ are mostly equivalent formats. As far as I know, the main (only?) difference resides in the fact that the diagonal term of the diagonal part is ordered first in the CSR.<br>
> For this reason, I think it should inherit from AIJ.<br>
<br>
This is more delicate.  Derived classes need to *exactly* retain the AIJ<br>
structure because all unimplemented methods use the parent<br>
implementations.  If the rows are not sorted, MatSetValues, MatGetRow,<br>
and the like cease to work.  You can still make MatHypreParCSR respond<br>
to MatMPIAIJSetPreallocation, but I don't think it can be derived from<br>
AIJ unless you audit *all* reachable AIJ code to remove the assumption<br>
of sorted rows *and* document the API change for all users that could<br>
observe the lack of sorting.  (I don't think that's worthwhile.)<br>
<br>
Note that the existing AIJ derived implementations merely augment the<br>
AIJ structure rather than modifying it.<br></blockquote><div><br></div><div><soapbox></div><div>  Inheritance is almost never useful except in contrived textbook examples. It was a tremendous pain to make</div><div>work in PETSc, and I think if we did it again, I would just go back and make subobjects that packaged up lower</div><div>level behavior instead of inheriting.</div><div></soapbox></div><div><br></div><div>   Matt</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> As soon  as I have time, I can start a new matrix class, but I don’t have much time to implement at the SetValues level yet.<br>
<br>
That's not urgent, but if you write it as a Mat implementation instead<br>
of some utility functions, it would be easy to add later and would not<br>
disrupt existing users.  There is no requirement that all Mat<br>
implementations include all the methods that "make sense"; it can be<br>
fleshed out later according to demand.<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>