[petsc-users] Reasons for breakdown in preconditioned LSQR
Pierre Jolivet
pierre at joliv.et
Tue May 7 00:24:23 CDT 2024
> On 7 May 2024, at 7:04 AM, Marco Seiz <marco at kit.ac.jp> wrote:
>
> This Message Is From an External Sender
> This message came from outside your organization.
> Hello,
>
> something a bit different from my last question, since that didn't
> progress so well:
> I have a related model which generally produces a rectangular matrix A,
> so I am using LSQR to solve the system.
> The matrix A has two nonzeros (1, -1) per row, with A^T A being similar
> to a finite difference Poisson matrix if the rows were permuted randomly.
> The problem is singular in that the solution is only specified up to a
> constant from the matrix, with my target solution being a weighted zero
> average one, which I can handle by adding a nullspace to my matrix.
> However, I'd also like to pin (potentially many) DOFs in the future so I
> also tried pinning a single value, and afterwards subtracting the
> average from the KSP solution.
> This leads to the KSP *sometimes* diverging when I use a preconditioner;
> the target size of the matrix will be something like ([1,20] N) x N,
> with N ~ [2, 1e6] so for the higher end I will require a preconditioner
> for reasonable execution time.
>
> For a smaller example system, I set up my application to dump the input
> to the KSP when it breaks down and I've attached a simple python script
> + data using petsc4py to demonstrate the divergence for those specific
> systems.
> With `python3 lsdiv.py -pc_type lu -ksp_converged_reason` that
> particular system shows breakdown, but if I remove the pinned DOF and
> add the nullspace (pass -usens) it converges. I did try different PCs
> but they tend to break down at different steps, e.g. `python3 lsdiv.py
> -usenormal -qrdiv -pc_type qr -ksp_converged_reason` shows the breakdown
> for PCQR when I use MatCreateNormal for creating the PC mat, but
> interestingly it doesn't break down when I explicitly form A^T A (don't
> pass -usenormal).
What version are you using? All those commands are returning
Linear solve converged due to CONVERGED_RTOL_NORMAL iterations 1
So I cannot reproduce any breakdown, but there have been recent changes to KSPLSQR.
> For the moment I can work by adding the nullspace but eventually the
> need for pinning DOFs will resurface, so I'd like to ask where the
> breakdown is coming from. What causes the breakdowns? Is that a generic
> problem occurring when adding (dof_i = val) rows to least-squares
> systems which prevents these preconditioners from being robust? If so,
> what preconditioners could be robust?
> I did a minimal sweep of the available PCs by going over the possible
> inputs of -pc_type for my application while pinning one DOF. Excepting
> unavailable PCs (not compiled for, other setup missing, ...) and those
> that did break down, I am left with ( hmg jacobi mat none pbjacobi sor
> svd ).
It’s unlikely any of these preconditioners will scale (or even converge) for problems with up to 1E6 unknowns.
I could help you setup https://urldefense.us/v3/__https://epubs.siam.org/doi/abs/10.1137/21M1434891__;!!G_uCfscf7eWS!cEzzrez47D-rTba54wHj2wMvjkRrPiIlyhhfvWp2H4HT4EO9-soMFVTQUt0bjRj08xqYWHXUBJusDpvvB-LqSQ$ if you are willing to share a larger example (the current Mat are extremely tiny).
Thanks,
Pierre
>
>
> Best regards,
> Marco
>
> <lsdiv.zip>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20240507/5cd430b9/attachment-0001.html>
More information about the petsc-users
mailing list