I have made a merge request https://gitlab.com/petsc/petsc/-/merge_requests/5002 <https://gitlab.com/petsc/petsc/-/merge_requests/5002> with an attempt to improve the documentation. It turns out that sometimes it works well also with right preconditioning (but generically it should not) so I did not put in error checking to prevent such usage. It turns out a bunch of test examples with null spaces are run with right preconditioning.
Barry > On Mar 21, 2022, at 1:51 PM, Marco Cisternino <[email protected]> > wrote: > > > From: Matthew Knepley <[email protected] <mailto:[email protected]>> > Sent: lunedì 21 marzo 2022 18:31 > To: Marco Cisternino <[email protected] > <mailto:[email protected]>> > Cc: Mark Adams <[email protected] <mailto:[email protected]>>; > [email protected] <mailto:[email protected]> > Subject: Re: [petsc-users] Null space and preconditioners > > On Mon, Mar 21, 2022 at 1:25 PM Marco Cisternino <[email protected] > <mailto:[email protected]>> wrote: > Thank you, Matt. > I already set the null space and test it in the toy code > If you set this and it is not working, something is wrong. This will remove > null space components from each update in the Krylov space. > This is done in an example where I check convergence to the exact solution: > https://gitlab.com/petsc/petsc/-/blob/main/src/snes/tutorials/ex69.c > <https://gitlab.com/petsc/petsc/-/blob/main/src/snes/tutorials/ex69.c> > > Do I have to set a special null space when I use GAMG? > The toy code works for PCNONE and PCILU, giving a zero mean solution the > first PC and an almost zero mean solution the second one. > GAMG floats away, quoting Mark. > Looking at what I do: > MatNullSpaceCreate(PETSC_COMM_WORLD, PETSC_TRUE, 0, nullptr, &nullspace); > MatSetNullSpace(matrix, nullspace); > it is more or less what you do at lines 3231-3233 of your reference. Am I > wrong? > What about lines 3220-3223? What is the difference between nullSpace and > nullSpacePres? > > > I tried your suggestion: the norm and the mean of the solution using > -mg_coarse_pc_type svd with PCGAMG is much closer to the one of PCNONE (the > norm is the same up to the 6th digit, the mean is about 10e-4 with “svd” > PCGAMG and 10e-17 with PCNONE). I’m going to try with the real code and see > what happens on larger meshes > This is not perfect since null space components can be introduced by the rest > of the preconditioner, but when I use range-space smoothers and > local interpolation it tends to be much better for me. Maybe it is just my > problems. > > Is there a way to set -mg_coarse_pc_type svd with the API into the code? > > Thanks, > > Marco > > Thanks, > > Matt > > Thank you all. > > Marco Cisternino > > > From: Matthew Knepley <[email protected] <mailto:[email protected]>> > Sent: lunedì 21 marzo 2022 18:16 > To: Mark Adams <[email protected] <mailto:[email protected]>> > Cc: Marco Cisternino <[email protected] > <mailto:[email protected]>>; [email protected] > <mailto:[email protected]> > Subject: Re: [petsc-users] Null space and preconditioners > > On Mon, Mar 21, 2022 at 12:06 PM Mark Adams <[email protected] > <mailto:[email protected]>> wrote: > The solution for Neumann problems can "float away" if the constant is not > controlled in some way because floating point errors can introduce it even if > your RHS is exactly orthogonal to it. > > You should use a special coarse grid solver for GAMG but it seems to be > working for you. > > I have lost track of the simply way to have the KSP solver clean the constant > out, which is what you want. > > can someone help Marco? > > I have not had time to look at the code. However, here are two ways we use to > fix the pure Neumann solution: > > 1) Attach a null space to the operator using > https://petsc.org/main/docs/manualpages/Mat/MatSetNullSpace.html > <https://petsc.org/main/docs/manualpages/Mat/MatSetNullSpace.html> > > 2) Use a coarse grid solver that does least-squares > > -mg_coarse_pc_type svd > > Thanks, > > Matt > > Mark > > > > > > On Mon, Mar 21, 2022 at 8:18 AM Marco Cisternino <[email protected] > <mailto:[email protected]>> wrote: > Good morning, > I’m observing an unexpected (to me) behaviour of my code. > I tried to reduce the problem in a toy code here attached. > The toy code archive contains a small main, a matrix and a rhs. > The toy code solves the linear system and check the norms and the mean of the > solution. > The problem into the matrix and the rhs is the finite volume discretization > of the pressure equation of an incompressible NS solver. > It has been cooked as tiny as possible (16 cells!). > It is important to say that it is an elliptic problem with homogeneous > Neumann boundary conditions only, for this reason the toy code sets a null > space containing the constant. > > The unexpected (to me) behaviour is evident by launching the code using > different preconditioners, using -pc-type <pctype> > I tested using PCNONE (“none”), PCGAMG (“gamg”) and PCILU (“ilu”). The > default solver is KSPFGMRES. > Using the three PC, I get 3 different solutions. It seems to me that they > differ in the mean value, but GAMG is impressive. > PCNONE gives me the zero mean solution I expected. What about the others? > > Asking for residuals monitor, the ratio ||r||/||b|| shows convergence for > PCNONE and PCILU (~10^-16), but it stalls for PCGAMG (~10^-4). > I cannot see why. Am I doing anything wrong or incorrectly thinking about the > expected behaviour? > > Generalizing to larger mesh the behaviour is similar. > > Thank you for any help. > > Marco Cisternino > > > > > -- > What most experimenters take for granted before they begin their experiments > is infinitely more interesting than any results to which their experiments > lead. > -- Norbert Wiener > > https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/> > > > -- > What most experimenters take for granted before they begin their experiments > is infinitely more interesting than any results to which their experiments > lead. > -- Norbert Wiener > > https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
