<div dir="ltr">Thank you Barry and Jed for the explanation!<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Sep 29, 2013 at 7:46 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">Matteo Parsani <<a href="mailto:parsani.matteo@gmail.com">parsani.matteo@gmail.com</a>> writes:<br>
> 2 - why those routines *should not be used* when writing a fresh code or a<br>
> large re-factoring?<br>
<br>
Barry wrote a great rationale, but consider an example: almost all<br>
third-party linear algebra libraries (and some special features in<br>
PETSc) require scalar (non-blocked) matrix formats, but PETSc has good<br>
implementations of other operations like matrix multiplication and<br>
incomplete factorization using BAIJ format.  Thus with some solution<br>
methods, you want a BAIJ matrix and with other methods, you need an AIJ<br>
matrix.  If you try to build the backend data format directly, you'll<br>
either need multiple versions to specifically support each format or<br>
there will need to be a copy, which doubles the peak memory usage<br>
required for the matrix.  If you just use MatXAIJSetPreallocation and<br>
MatSetValuesBlocked, then you can choose the matrix format at run-time,<br>
in which case all solvers become available without the extra memory<br>
usage.<br>
<br>
There are many more examples.  It is bad software design for a component<br>
to depend on more than it must.  Depend on generic interfaces instead of<br>
internal formats.  It will make your software more powerful and more<br>
maintainable.<br>
</blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Matteo<br></div>
</div>