[petsc-dev] [petsc-users] Using PETSc solvers and preconditioners with mfem

[Stefano Zampini]

Moving to petsc-dev

An initial implementation of MatHYPRE is in stefano_zampini/feature-mathypre

comments, suggestions etc are welcome.

Stefano

On Oct 25, 2016, at 9:45 PM, Matthew Knepley <knepley at gmail.com> wrote:

> On Tue, Oct 25, 2016 at 1:43 PM, Jed Brown <jed at jedbrown.org> wrote:
> Stefano Zampini <stefano.zampini at gmail.com> writes:
> > MATHYPRE could be a shell wrapping Hypre calls for the moment.
> > 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.
> > For this reason, I think it should inherit from AIJ.
> 
> This is more delicate.  Derived classes need to *exactly* retain the AIJ
> structure because all unimplemented methods use the parent
> implementations.  If the rows are not sorted, MatSetValues, MatGetRow,
> and the like cease to work.  You can still make MatHypreParCSR respond
> to MatMPIAIJSetPreallocation, but I don't think it can be derived from
> AIJ unless you audit *all* reachable AIJ code to remove the assumption
> of sorted rows *and* document the API change for all users that could
> observe the lack of sorting.  (I don't think that's worthwhile.)
> 
> Note that the existing AIJ derived implementations merely augment the
> AIJ structure rather than modifying it.
> 
> <soapbox>
>   Inheritance is almost never useful except in contrived textbook examples. It was a tremendous pain to make
> work in PETSc, and I think if we did it again, I would just go back and make subobjects that packaged up lower
> level behavior instead of inheriting.
> </soapbox>
> 
>    Matt
> 
> > 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.
> 
> That's not urgent, but if you write it as a Mat implementation instead
> of some utility functions, it would be easy to add later and would not
> disrupt existing users.  There is no requirement that all Mat
> implementations include all the methods that "make sense"; it can be
> fleshed out later according to demand.
> 
> 
> 
> -- 
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
> -- Norbert Wiener

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20161107/c005ca1f/attachment.html>