Closed moritzdannhauer closed 7 years ago
This will involve changing many, many files. As an initial step, we could make a new module with only one algorithm option. What size complex matrices do you need to solve right now? If they're not too big, we can try Eigen's solvers first.
I see, we need to change all of the solvers... Do you want to merge/replace the real and the complex module version at some point?
What size complex matrices do you need to solve right now? Right now, they are small because we are using very simple examples and the stiffness matrix are generally very sparse too. Our short-term goal is to use realistic head meshes with millions of nodes. Thats why, EIgen may not be an option (because of limited matrix sizes allowed) and implementing a complex verion of solvelinearsystem seems unavoidable.
Eigen can support any size matrix, it's more the speed of the solvers that would be tested. We still need to try multithreading the Eigen solvers (with a simple compiler flag).
Is it efficient with memory? So, does it take advantage of the sparsity - if it does not it may be not worth it. If we do not know we can try it with the new version of 'SolveLinearSystemComplex'.
Of course, Eigen has a sparse matrix type which surely would be used by its solvers. For details read https://eigen.tuxfamily.org/dox-devel/group__TopicSparseSystems.html
Ok, thats the next goal to do something useful with the complex number we can create now in SCIRun5. How difficult will it be to connect the new solvers to SCIRun5? Is it similar in way to the cleaver1 interface in terms of coding?
I just looked at the Eigen code. Is it simply something like:
ConjugateGradient<SparseMatrix
There's already a class I can reuse for the Eigen solving. I just need to make a new module and UI.
We need complex number support for both inputs (2 additional complex number support) and the algorithmic part of this module.