(WIP) Tpetra: Remove template parameters
Created by: mhoemmen
@trilinos/tpetra
THIS IS A WORK IN PROGRESS. Please don't merge this yet.
Description
Start removing the LocalOrdinal, GlobalOrdinal, and Node template parameters from Tpetra. THIS IS A WORK IN PROGRESS. I've added new versions of the following classes that no longer have any of these template parameters:
- Details::Directory and subclasses
- Directory
- Map
- ImportExportData
- Transfer
- Export
- Import
I wanted these classes to build alongside the current Tpetra classes, so I could test and compare them, and have a gradual porting path. (Note use of ::Tpetra to pull in enums etc. from the Tpetra namespace, that I didn't want to duplicate. My goal is to avoid duplication whenever possible.) To prevent namespace drama, all new classes live in an entirely new namespace (TpetraNew), that is not nested in the Tpetra namespace.
I currently have tests for Map and Directory. The tests build and pass on my laptop. Testing Export and Import will take a bit more work, since very few of the current tests for these classes work in isolation. (Most of them depend on MultiVector, Vector, etc. and exercise DistObject.)
This was not very hard to do; it was mostly just tedious. The most important change is that the "decl" and "def" header files go away. Instead, there's a true header file (e.g., Tpetra_Map.hpp) and a .cpp file that actually has the implementation in it (no more explicit template instantiation (ETI)). We will still need ETI machinery for classes templated on Scalar or Packet, but we will be able to simplify the CMake logic for ETI quite a bit.
Next steps
The next class to convert is DistObject. That will be the first class to convert that will retain a template parameter (Packet).
I can defer changing Distributor, since it does not depend on the usual three template parameters; however, I have some future plans to hide Distributor's implementation that I can discuss elsewhere.
After DistObject will come RowGraph and CrsGraph. After those, will come Operator, then all of the other DistObject subclasses and the various functions that work with them. (The latter two will need to happen simultaneously -- e.g., for nonmember functions that work on CrsMatrix.)
Risks
- Build size and time increase: We could avoid this by making TpetraNew a new Tpetra subpackage. That way, it would be a separate library, and users could avoid linking to it.
- Merging with other work, such as @DrBooom 's incoming changes.
- Huge amount of work downstream to use this: We could mitigate and make this a gradual porting exercise with conversion functions, e.g., between old and new versions of the same data structure.