Matteo Parsani <[email protected]> writes: > 2 - why those routines *should not be used* when writing a fresh code or a > large re-factoring?
Barry wrote a great rationale, but consider an example: almost all third-party linear algebra libraries (and some special features in PETSc) require scalar (non-blocked) matrix formats, but PETSc has good implementations of other operations like matrix multiplication and incomplete factorization using BAIJ format. Thus with some solution methods, you want a BAIJ matrix and with other methods, you need an AIJ matrix. If you try to build the backend data format directly, you'll either need multiple versions to specifically support each format or there will need to be a copy, which doubles the peak memory usage required for the matrix. If you just use MatXAIJSetPreallocation and MatSetValuesBlocked, then you can choose the matrix format at run-time, in which case all solvers become available without the extra memory usage. There are many more examples. It is bad software design for a component to depend on more than it must. Depend on generic interfaces instead of internal formats. It will make your software more powerful and more maintainable.
pgpN6NvE2JweN.pgp
Description: PGP signature
