Hello everybody, Lately there have been a lot of github issues on Tpetra support and how it can be achieved in an efficient way both in terms of coding hours and the resulting implementation. I feel that it could be beneficial to have some kind of roundtable discussion(s) on how the interface should work internally. Externally it should just match the existing parallel linear algebra classes as closely as possible of course.
I am currently trying to use the FROSch preconditioner from ShyLU and the Xpetra/Epetra combination was somewhat unreliable when it comes to memory management, possibly because Epetra is not using the reference counted pointer RCP from Teuchos. Due to that I have a code that currently needs very few functions (constr., reinit, add, compress) and then switched to "pure" trilinos with the result of trilinos_matrix(). Therefore, I would extend as I go from a working implementation of a SparseMatrix Wrapper. To ensure that the resulting code would need as little modifications as possible to be consistent with other simultaneous efforts it would be good to have some general guidelines or something like that. Ideally we could get some Trilinos developers to join the discussion. From the european trilinos user group meeting I know that they already have a lot of experience in switching existing code from Epetra to Tpetra both in the simpler "mirrored" implementation as well as the more performant but also more involved implementation making full(er) use of Kokkos. Looking forward to fruitful discussions, Philipp -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/5a9ab835-1544-41ed-845e-1bee7e497c2an%40googlegroups.com.
