-
Notifications
You must be signed in to change notification settings - Fork 174
solving: Default to LU + MUMPS where possible #1471
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Also isn't fieldsplit plus LU on the blocks only marginally better than unpreconditioned GMRES for e.g. mixed Poisson?
This feels like a fool's errand ...
________________________________
From: David A. Ham <notifications@github.com>
Sent: 09 July 2019 09:58:11
To: firedrakeproject/firedrake
Cc: Subscribed
Subject: Re: [firedrakeproject/firedrake] solving: Default to LU + MUMPS where possible (#1471)
@dham commented on this pull request.
________________________________
In firedrake/solving_utils.py<#1471 (comment)>:
+ :arg arguments: arguments for the bilinear form (need to know if we have a Real block).
+ :arg defaults: Any default sets of parameters to supply."""
+ parameters = dict(chain.from_iterable(d.items() for d in defaults))
+ if any(isinstance(V, fsi.RealFunctionSpace)
+ for V in chain.from_iterable(a.function_space() for a in arguments)):
+ # There's a Real block, override with defaults with nest + jacobi.
+ parameters.update({"pc_type": "jacobi", "mat_type": "nest"})
+ solver_parameters = solver_parameters or {}
+ mat_type = solver_parameters.get("mat_type")
+ pmat_type = solver_parameters.get("pmat_type")
+ # Allow anything, interpret "matfree" as matrix_free.
+ matfree = mat_type == "matfree"
+ pmatfree = pmat_type == "matfree"
+ # No preconditioner by default for matrix-free
+ if matfree or pmatfree:
+ parameters.update({"pc_type": "none"})
If you have a mixed system then even in 2D LU can get big fast and/or defeat the MUMPS memory management heuristics. Is this really a robust option?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#1471?email_source=notifications&email_token=ABOSV4TD727PBHS4VFGDABLP6RHKHA5CNFSM4H6KHKAKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOB52YQRQ#discussion_r301472617>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABOSV4SJRPYIPW6QUKSAZF3P6RHKHANCNFSM4H6KHKAA>.
|
The proposal is:
|
|
Yes, if you have n real variables (n small, typically n = 1) then full Schur fieldsplit + LU for (1, 1) block + n iterations of GMRES on the Schur complement solves the problem exactly (in exact arithmetic). |
David makes a good point. I would suggest also defaulting to |
|
I also have frequent headaches trying to use mumps. Maybe we dodge then if
we we can use the default LU (maybe with a special parameter to keep it
from breaking on saddle points) in serial processor mode -- that's usually
not terrible.
Is there any experience with pastix? Lawrence and I used it in a paper to
some effect, but I'm not sure how robust it is across a range of problems.
…On Tue, Jul 9, 2019 at 3:30 PM Patrick E. Farrell ***@***.***> wrote:
If you have a mixed system then even in 2D LU can get big fast and/or
defeat the MUMPS memory management heuristics. Is this really a robust
option?
David makes a good point. I would suggest also defaulting to "mat_mumps_icntl_14":
200 (or similar).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1471?email_source=notifications&email_token=AA4XULZ55VJ45RWJCBR7NFDP6TYOJA5CNFSM4H6KHKAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZRN3CA#issuecomment-509795720>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA4XUL7B5KAA4PPWCJQEXY3P6TYOJANCNFSM4H6KHKAA>
.
|
|
OK, so which of these best describes the conclusion of these discussions?
|
|
I think that for mixed problems we shouldn’t try to provide an LU default (except for R).
On 10 Jul 2019, at 16:58, Lawrence Mitchell <notifications@github.com<mailto:notifications@github.com>> wrote:
OK, so which of these best describes the conclusion of these discussions?
1. Yes, do this (with the better mumps options + fieldsplit/LU for problems with real blocks)
2. Yes, do this, but use superlu_dist instead of mumps (malloc! 64bit!)
3. No, continue with the current state of play.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#1471?email_source=notifications&email_token=ABOSV4SJ5APHDU45EHWVYULP6YBI5A5CNFSM4H6KHKAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZT5U5Y#issuecomment-510122615>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABOSV4SIWWWEKAHU6JS5J5TP6YBI5ANCNFSM4H6KHKAA>.
|
|
I vote for option #1. With @colinjcotter No one is advocating fieldsplits when not necessary (they are necessary with real blocks because of technical limitations). |
|
If I don’t have to remember that mumps option and it’s robust, it’s fine with me.
…Sent from my iPhone
On Jul 10, 2019, at 3:05 PM, Patrick E. Farrell ***@***.***> wrote:
I vote for option #1. With "mat_mumps_icntl_14": 200 MUMPS is almost bulletproof.
@colinjcotter No one is advocating fieldsplits when not necessary (they are necessary with real blocks because of technical limitations).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
b4d2830 to
449388b
Compare
449388b to
c1198d6
Compare
|
If we're happy with the proposal of options, I think this is now right. If not, I'll leave it until agreement is reached on what we want. |
|
It would be good to have a test that just solved a problem with R-blocks. |
0344278 to
ce1f816
Compare
ce1f816 to
0609b07
Compare
|
I think I finally fixed all the corner cases. Let's hope tests pass. |
0609b07 to
978f495
Compare
|
Ready for review. All tests are passing now. |
We now no longer translate options when inserting into the options dictionary.
This makes the default user experience friendlier.
978f495 to
0ca54f6
Compare
This changes the default to obey the principle of least surprise.
0ca54f6 to
1c1beec
Compare
This makes the default user experience friendlier.