Tpetra: Simplify initialization paths
Created by: mhoemmen
THIS COMMENT SUPERSEDED BY MY LONG COMMENT BELOW (01:23 09 Mar 2016).
@trilinos/tpetra Moved from Bugzilla Bug 6361: https://software.sandia.gov/bugzilla/show_bug.cgi?id=6361
That bug discussion centered around whether Tpetra should initialize Kokkos and MPI (if enabled) for users automatically. The motivating problem is that users encountered unexpected, undesired Kokkos behavior, because Tpetra initialized Kokkos with defaults, when it should instead have used Kokkos' input command-line arguments. The main benefit of automatic initialization is that Tpetra users who don't otherwise use Kokkos or MPI, don't have to know about either. The risks of automatic initialization are:
- Need to pass in command-line arguments through (argc, argv), for both Kokkos and MPI
- If we silently initialize Kokkos with defaults, users might get undesired behavior
We didn't all come to full agreement, but I think we can agree that the following two options make sense:
- initialize(argc,argv): Tpetra initializes MPI (if not already) and Kokkos (if not already), passing in command-line arguments to both MPI_Init and Kokkos::initialize. Note that MPI_Init reserves the right to modify both argc and argv (e.g., to delete MPI's command-line arguments).
- initialize(): Tpetra requires that both MPI and Kokkos are initialized. If not, the function throws.
It is unnecessary to provide an initialize() function that takes an MPI_Comm
, because Tpetra does not have a "default MPI communicator." Tpetra::Map
takes and wraps the user's communicator. Similarly, initialize() need not take a Kokkos execution space instance; the proper place for that would be the constructor of Tpetra::Map
.
Note that the zero-argument version of initialize() above changes current behavior with respect to Kokkos initialization. Current behavior is that initialize() initializes Kokkos with default arguments.