Pascal,
Originally, I only knew Trilinos because I used the distributed matrices and
vectors in my application. I also knew that there is a configuration of
trilinos to make complex numbers available in all packages that support it.
However, from what I can tell, that only effects Tpetra datatypes, not Epetra.
From what I have seen in the dealwrappers, they only use Epetra. An
interesting detail about this is the Komplex-Package, which is described as an
Epetra based solver for complex systems, which wraps Epetra matrices and
stores the real and imaginary parts as blocks. (see here:
https://docs.trilinos.org/dev/packages/komplex/doc/html/index.html
<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.trilinos.org%2Fdev%2Fpackages%2Fkomplex%2Fdoc%2Fhtml%2Findex.html&data=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Ca8809251f22f473d86cc08d83141f358%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637313506615095299&sdata=m%2BNl78twnMHlf3ByWf3OlsYX7WDK%2ByHz6ogeMVuKUBA%3D&reserved=0> )
At GitHub I can see that project 4 deals with adding Tpetra support which
would make complex numbers in Tpetra usable in deal if the interface is built
to support them)
Yes, Tpetra is the way to go in the long run. deal.II actually has Tpetra
wrappers already, in namespace LinearAlgebra::TpetraWrappers. It is definitely
our long-term goal to move from the Epetra interfaces to the Tpetra
interfaces. The issue -- for several years already -- is that not all of the
packages we use in Trilinos (for example for solvers, preconditioners, etc)
support Tpetra. In other words, at least every time we looked, we could not
replace our Epetra interfaces without losing functionality.
That said, it is definitely true that there are Trilinos packages for solvers
and preconditioners that do support Tpetra, and for which we don't (yet) have
any interfaces. So, if you are willing to help out with this situation, one
approach worth pursuing would be to explore what Trilinos functionality you
need, and then ask here or on github which pieces are already available and
which still need to be written. None of the interfaces are very large, and
writing more interfaces is not a very difficult task because there are already
good examples to start from. We would certainly appreciate any help!
About GMRES: I will be using PETSc GMRES to solve my system, but if possible I
will try to also solve it with dealii::SolverGMRES and let you know what happens.
Yes, feedback is welcome!
Best
W.
--
------------------------------------------------------------------------
Wolfgang Bangerth email: bange...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/
--
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 dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/dealii/967f3eea-3051-6f58-3447-52d1bdba784a%40colostate.edu.
