Complex arithmetic for PDE solvers 2 #755
Conversation
…istVectorArrayOperatorBase
native complex number support should be used in the future
Codecov Report
|
2 similar comments
Codecov Report
|
Codecov Report
|
Codecov Report
|
How would this work if I got a Fenics install that supports complex field types natively?
Not sure if I understand the question. If FEniCS would support complex numbers, this feature would be ignored by the bindings as only real numbers will be passed to the backend. If one wants to use native complex number support one would have to adapt the bindings. |
|
Since DolfinX does support complex natively, I think we should at least consider this when implementing these changes to not make future support for that unnecessarily hard. |
I would agree. Is the idea to add a |
|
I don't know how native complex data will be supported by the FEniCS bindings, as I know nothing about complex number support in DolfinX. I assume that most code can be shared, but there will probably be two versions of the bindings.
I am not sure if I understand the difference. For NGSolve it is possible to instantiate complex discrete function spaces. I suspect, that then also all matrices assembled for this function space will have complex data. I don't know (haven't tried yet) if it is possible to multiply a real matrix with a complex vector. If yes, it would be possible, to dispose the complexified NGSolve bindings from this PR and only use the native support. I would do the same thing for DolfinX. If the backend cannot handle a mix of real an complex data, it will be probably necessary to keep the complexified bindings for the case when the actual model is real but we need to solve problems with complex shifts and offer a second set of bindings for the case when the actual model is using complex numbers. If you have anything concrete in mind we can do know to simplify things in the future, I am open to suggestions .. |
|
@pml, can this be merged? |
|
Yes. |
This PR adds generic support for complex-valued VectorArrays for PDE solvers with
ListVectorArray-based bindings. The construction is generic and does not require any complex number support within the PDE solver. The approach is similar to #747, but provides base classes forVectorsandOperatorsthat can be used for arbitrary solver bindings.Unlike #747, complex linear combinations are completely handled by
LincombOperator. Should the need arise, anassemble_lincombrule could be added, which separately assembles real and imaginary parts.Moreover, this PR adds complex data to the
VectorArrayfixtures and fixes various complex number issues, both in the tests and the implementations.I have tried to fix
lgmres, but more testing / checking the code is required. Theheat_sinknotebook seems to work, although the error system magnitude plot looks different. (At first sight, both plots look strange, and maybe the lgmres tolerances are not chosen correctly.)lgmresseems to run significantly faster compared to #747.