<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 29, 2015 at 7:55 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@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"><br>
Richard,<br>
<br>
Sounds reasonable to me.</blockquote><div><br></div><div>Richard, this is somewhat subtle since PETSc's inheritance model is sucky and somewhat broken. Look at</div><div>the factorization classes, AIJMUMPS etc., before coding anything.</div><div><br></div><div> Thanks,</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"><span class="HOEnZb"><font color="#888888"><br>
Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On Sep 29, 2015, at 5:16 PM, Richard Mills <<a href="mailto:richardtmills@gmail.com">richardtmills@gmail.com</a>> wrote:<br>
><br>
> Hi Folks,<br>
><br>
> It's come up in discussions a few times that, ideally, the burden of supporting very specific optimizations for complex architectures like Intel's upcoming Knights Landing MIC processor should be handled as much as possible by a library like MKL. To take some concrete steps towards this, I want to add support for using the new sparse BLAS inspector-executor ("SpMV 2" -- no idea why they called it that) routines that were added in the recent release (11.3) of MKL. These use an inspector-executor model to provide some optimized operations (sparse matrix-vector multiplication, sparse matrix-matrix multiplication, triangular solve, sparse matrix addition). Those interested can have a look at the documentation here:<br>
><br>
> <a href="https://software.intel.com/en-us/node/590105" rel="noreferrer" target="_blank">https://software.intel.com/en-us/node/590105</a><br>
><br>
> I am thinking that the cleanest way to support this is to add a new matrix subclass that mostly inherits from MATAIJ (or MATBAIJ), calling the inspection ("analysis") routines upon matrix assembly finalization and using the "SpMV 2" routines as appropriate. Then if someone wants to use the SpMV 2 stuff, they ensure that their matrix ends up as MATMKLSPMV2 (or whatever better name we come up with). Does this sound reasonable? If you have a better suggestion, please let me hear it.<br>
><br>
> --Richard<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="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>