" I interpret the numbers you show slightly differently. For both elements, you need about 10-30 inner A iterations for each outer iteration. That's actually quite a good number. It means that the top left block can be inverted easily in either case, and that's of course also what I would expect. In particular, you need more inner A iterations when using the Q2 element than for the Q1 element -- which I'd expect to be the case.
The difference is in the outer iterations. That, too, is what I would expect: The Q1-P0 element is unstable, so there is one (or a few) eigenvalues that go to zero even if the rest stays the same under mesh refinement. In other words, the condition number grows substantially more than what you'd see just from mesh refinement, and that reflects in the number of outer iterations. I can't say why that isn't reflected in the paper (different test case?) but what you see does not surprise me. In short, I think the message should be: Don't use unstable elements. " I am aware that choosing an unstable element is generally not recommended. However, despite not being LBB stable, the Q1-P0 element is still commonly used in solid mechanics and included in commercial codes. In practice, it performs quite well for my benchmark problems and the computational savings for not choosing quadratic displacement elements are significant. Besides the condition number, I am wondering whether the increased outer iterations I presented could stem from a poor approximation of the Schur complement, S = B*A^-1*B^T? Following one of the approachs PETSc uses for saddle point systems (see here <https://petsc.org/main/manualpages/PC/PCFieldSplitSetSchurPre/>), I tried approximating the Schur complement as S = B*diag(A)^-1*B^T and obtained the following results: - Cycle 2: 41(Outer), 434 Inner (A), 3379 Inner (S) - Cycle 3: 82 (Outer), 1669 Inner (A), 13308 Inner (S) The outer FMGRES iterations are quite reasonable, but the number of inner iterations for solving with the Schur complement clearly increased significantly. Sloppy speaking, did I simply shift the conditioning issue from the outer solve to the inner Schur solve? Using AMG for the Schur solve helped to reduce the inner iteration counts for S to 530 (Cycle 2) and 2746 (Cycle 3). However, the total cpu time remained similar to that of using sparse ilu. Given all this, do you have any recommendations for a more effective Schur complement approximation and/or preconditioner? Ideally, this can be generalized to incompressible elasticity as well. Thank you, Simon On Monday, September 8, 2025 at 12:14:57 AM UTC+2 Wolfgang Bangerth wrote: Simon: > I recently modified step-22 and step-56 (the Stokes problem) by switching the > usual Q2-Q1 element to a cheaper Q1-P0 element, i.e., linear Lagrange > polynomials for displacement and element-wise constant pressure. > > What I noticed is that using Q1-P0 significantly increases the cost of the > linear solve. Here are some example iteration counts from step-56: > > *Q2-Q1:* > > * Cycle 2: 21 (Outer), 320 Inner (A), 22 Inner (S) > * Cycle 3: 21 (Outer), 592 Inner (A), 22 Inner (S) > > *Q1-P0:* > > * Cycle 2: 258 (Outer), 2313 Inner (A), 258 Inner (S) > * Cycle 3: 811 (Outer), 12600 Inner (A), 811 Inner (S) > > I looked at a paper co-authored by Wolfgang (link here<https:// > www.math.colostate.edu/~bangerth/publications/2021-q1q1.pdf? > utm_source=chatgpt.com>), and Fig. 8 suggests the FGMRES iteration count > shouldn’t blow up this much. But clearly, the true bottleneck is the inner > iterations for A. > > My understanding is that using the upper block-triangular preconditioner with > ILU for both the mass matrix and the A-matrix should still be reasonable when > lowering the polynomial degree. > > Does anyone (maybe the authors of the tutorials?) have an idea why the > iteration counts increase so dramatically with the Q1-P0 element? I interpret the numbers you show slightly differently. For both elements, you need about 10-30 inner A iterations for each outer iteration. That's actually quite a good number. It means that the top left block can be inverted easily in either case, and that's of course also what I would expect. In particular, you need more inner A iterations when using the Q2 element than for the Q1 element -- which I'd expect to be the case. The difference is in the outer iterations. That, too, is what I would expect: The Q1-P0 element is unstable, so there is one (or a few) eigenvalues that go to zero even if the rest stays the same under mesh refinement. In other words, the condition number grows substantially more than what you'd see just from mesh refinement, and that reflects in the number of outer iterations. I can't say why that isn't reflected in the paper (different test case?) but what you see does not surprise me. In short, I think the message should be: Don't use unstable elements. > My goal is actually not to solve Stokes, but to develop a *preconditioner * > for *incompressible nonlinear elasticity*, solving: > > * div(P(F(u))) = 0 with P the stress and F the deformation gradient, > * det(F) - 1 = 0. > > The discretized system looks structurally similar to Stokes, especially since > the A-matrix (stiffness matrix) is symmetric and the B-matrix depends > similarly on div(u). So the same upper block-triangular preconditioner should > be applicable, maybe with tweaks to the inner preconditioners. Is a Q1-P0 discretization of this system stable? I would expect the same issue as with Stokes here. Best W. -- ------------------------------------------------------------------------ Wolfgang Bangerth email: [email protected] 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/dealii/99afcf70-21bd-497d-a6e6-910cbc851952n%40googlegroups.com.
