Thank you, Matt.

  1.  I already set the null space and test it in the toy code
  2.  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.

Thank you all.

Marco Cisternino


From: Matthew Knepley <[email protected]>
Sent: lunedì 21 marzo 2022 18:16
To: Mark Adams <[email protected]>
Cc: Marco Cisternino <[email protected]>; [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

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/>

Reply via email to