Update documentation,analysis guide->linearsolvers #443
Conversation
Include Muelu, Teko, etc., particularly mention the xml files
ischeider
added
type: enhancement
|
Thank you for updating this important section of the documentation! I think it closes #68 |
|
@amgebauer Definitely! I was not aware of this issue, sorry. |
There was a problem hiding this comment.
Thanks @ischeider for adding this valuable documentation.
I think it would be nice if @maxfirmbach also takes a look over the updated docs.
| - unsymmetric | ||
| * - elasticity | ||
| - symmetric | ||
| * - Contact |
There was a problem hiding this comment.
| * - Contact | |
| * - Contact with Lagrange multipliers |
There was a problem hiding this comment.
I always thought that any contact (at least with friction) leads to unsymmetric systems. Maybe an expert can comment on this.
| * - Convection dominated flow | ||
| - unsymmetric | ||
| * - elasticity | ||
| - symmetric |
There was a problem hiding this comment.
I think this is also not true if we have Dirichlet BCs
There was a problem hiding this comment.
It would be really good if this table could be extended to some extend, but I don't know enough about these symmetry issues.
There was a problem hiding this comment.
If I'm not mistaken the way 4C applies the DBCs results in an unsymmetric system (which is not obvious since there are other methods that maintain symmetry). And since Dirichlet BCs are quite common, it's worth adding it here in the list.
There was a problem hiding this comment.
A short summary of my discussion with @ischeider:
My comment is based on https://github.com/4C-multiphysics/4C/blob/main/src/core/linalg/src/sparse/4C_linalg_sparseoperator.hpp#L208-L217, i.e., 4C fills the dbc-rows with 0 and a 1 on the diagonal. The resulting matrix will be unsymmetric. It would be better to not assemble dbcs at all. We might be able to do so if we replace our internal discretization with a deal.ii implementation.
|
@ischeider, I had a look. May I push my updates to your draft directly to your branch? |
|
I have pushed some changes. For sure, the current state is not perfect. Most prominently, I'd love to see MueLu for Multiphysics (instead of our in-house implementation (AMGnxn)). Since this is more an issue of necessary changes to the source code, this PR is still a leap forward towards solver documentation. @ischeider, thanks for tackling this! |
Also: rename introduction_solvers to linear_solvers
| @@ -1,7 +1,6 @@ | |||
| References | |||
| =========== | |||
|
|
|||
| .. [Gee07] M. Gee, C.M. Siefert, J.J. Hu, R.S. Tuminaro, M.G. Sala: ML 5.0 Smoothed Aggregation User's Guide, SAND2006-2649, Sandia Nat. Lab, 2007. | |||
There was a problem hiding this comment.
There is a MueLu User's Guide:
@techreport{BergerVergiat2023a,
address = {Albuquerque, NM (USA) 87185},
author = {Berger-Vergiat, Luc and Glusa, Christian A. and Harper, Graham and Hu, Jonathan J. and Mayr, Matthias and Prokopenko, Andrey and Siefert, Christopher M. and Tuminaro, Raymond S. and Wiesner, Tobias A.},
institution = {Sandia National Laboratories},
number = {SAND2023-12265},
title = {{MueLu User's Guide}},
year = {2023}}
Description and Context
Even though I am not the expert on linear solvers, I saw that this section is particularly outdated (change from ML to MueLu is not covered, parameters that do not exist were still mentioned, etc.), and tried to update it.
All the experts, please check the content, so that it becomes a valuable resource of knowledge.
I know that we probably have to update it again soon, when we finally switch to Tpetra and Amesos2, but at least it gives some details to the current version.
Related Issues and Pull Requests
Needs: PR #400
Related to: Issue #365 , Discussion #408
Closes Issue #68
Interested parties
@maxfirmbach @dharinib98 @mayrmt