Galeri::Xpetra::BuildProblem has redundant template parameters
Created by: mhoemmen
@trilinos/galeri @trilinos/xpetra
Galeri::Xpetra::BuildProblem takes six template parameters: Scalar, LocalOrdinal, GlobalOrdinal, Map, Matrix, and MultiVector. The latter three are redundant or very nearly so. With Tpetra, they are actually redundant. With Epetra, the first three template parameters are constrained and the last three are fixed.
See discussion here: https://github.com/trilinos/Trilinos/pull/3053#issuecomment-403168295
Expectations
Template parameters should be as few and as independent as possible.
"C++ Coding Standards: 101 Rules, Guidelines, and Best Practices" (Sutter & Alexandrescu) 65: "Customize intentionally and explicitly" (templating on Map, MultiVector, and CrsMatrix unintentionally create customization points).
C++ Core Guidelines T.42: "Use template aliases to simplify notation and hide implementation details"
C++ Core Guidelines T.122: "Use templates (usually template aliases) to compute types at compile time"
Motivation and Context
We suspect that unnecessary template parameters lead to longer build times. They also make interfaces harder to use.
Possible Solution
Galeri::Xpetra::BuildProblem
's template parameters only express four (five perhaps, if one counts the Node type) fundamental properties:
- Epetra or Tpetra
- Scalar
- LocalOrdinal
- GlobalOrdinal
It can derive the Map, MultiVector, and CrsMatrix types from this information. Its implementation can use template aliases for Map, MultiVector, and CrsMatrix.