On Tue, Oct 25, 2016 at 1:43 PM, Jed Brown <[email protected]> wrote:
> Stefano Zampini <[email protected]> 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
