<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Moving to petsc-dev</div><div><br></div><div>An initial implementation of MatHYPRE is in stefano_zampini/feature-mathypre</div><div><br></div><div>comments, suggestions etc are welcome.</div><div><br></div><div>Stefano</div><div><br></div><div><div>On Oct 25, 2016, at 9:45 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 25, 2016 at 1:43 PM, Jed Brown<span class="Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: 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: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: 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>--<span class="Apple-converted-space"> </span><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></div></blockquote></div><br></body></html>