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. > 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.
signature.asc
Description: PGP signature
