[LinAlg] Remove `replace_map` from our vector interfaces

[sebproell]

This function is dangerous and buggy within TrilinosEpetra itself. The information of the new map is not propagated to all views. Instead of replacing the Map of a vector, create a new vector with the new map and copy the data from the old vector.

Definition of Done

• LinALg::Vector::replace_map removed
• LinALg::MultiVector::replace_map removed

[mayrmt]

Cross-posting from #834

How does replace_map() behave in Tpetra? Does it propagate the new map to the views or not not? Before patching up stuff in 4C, I strongly advise to check with the Trilinos team, if potential issues can be fixed at their root.

@cgcgcg @csiefer2

[sebproell]

Here is a test that passes (run with 2 MPI ranks):

  TEST(Tpetra, MapReplacement)
  {
    auto map = Teuchos::make_rcp<Tpetra::Map<>>(10, 0, Tpetra::getDefaultComm());
    Tpetra::MultiVector<double> mv(map, 2);
    const auto vec_view = mv.subView(Teuchos::arrayViewFromVector(std::vector<std::size_t>{0}));

    // New map where elements are distributed differently
    std::array<int, 5> my_elements;
    if (Core::Communication::my_mpi_rank(MPI_COMM_WORLD) == 0)
      my_elements = {0, 2, 4, 6, 8};
    else
      my_elements = {1, 3, 5, 7, 9};

    auto new_map = Teuchos::make_rcp<Tpetra::Map<>>(
        10, my_elements.data(), my_elements.size(), 0, Tpetra::getDefaultComm());

    mv.replaceMap(new_map);
    // Old view does not have the new map
    EXPECT_FALSE(vec_view->getMap()->isSameAs(*new_map));

    // Get a new view
    auto vec_view_new = mv.subView(Teuchos::arrayViewFromVector(std::vector<std::size_t>{0}));
    // Check that the new view has the new map
    EXPECT_TRUE(vec_view_new->getMap()->isSameAs(*new_map));
  }

This means a view created before a map replacement is not updated, but at least a view created after a map replacement is. If Tpetra would add a sentence to the docs of replaceMap that states something like: "This call invalidates any views made via subView()", the behavior would be documented.

That being said, I would still not expose replace_map in our wrappers without a clear use case.

[maxfirmbach]

Let‘s try to not bloat up our wrappers. I think fixing stuff in Epetra makes no sense at this point. I would also try to avoid using it, do we even have a real use case?