Bruno Turcksin

@kronbichler Do you need help on this? @davydden @tjhei Can one of you implement the PETSc interface? I don't really want to spend time learning PETSc since I never used...

What is the next step for the integration of the new vector interface? #3073 shows that there is still a lot of work to do before we can fully use...

There are several places where we use `operator()` Is the preferred method to make the class a friend or should we use a `ReadWriteVector`?

Since #3957 has been merged, I think the new interface is ready to be used. The petsc wrappers are still missing but it should be easy for someone who knows...

I cannot post the slides (I would need to get the authorization from ORNL) but I will post a summary (yes, it does make a difference...)

yes, I think we should remove `EpetraWrappers::Vector`

I think it's a good idea. I have also received complaints about deal.II being slow and it's always someone who doesn't realize that they are using debug mode.

I am not sure about this change because `get_thread_data()` should be the same as `get_thread_data(0)` in the case you describe. The real bug might be in `get_thread_data()`.

When we are inside a parallel region, `get_thread_data()` is not supposed to detect the thread number. It should use thread 0. https://github.com/kokkos/kokkos/blob/256777d4630daec087b54328634850d857918eba/core/src/OpenMP/Kokkos_OpenMP_Instance.hpp#L94-L96 The condition might be wrong.

Then every time we use `get_thread_data()`, there is potentially a bug. We should either fix `get_thread_data()` or check that it does the correct thing everywhere.