[petsc-users] Is PCFactorSetZeroPivot() effective?

[Jozsef Bakosi]

On 05.31.2012 18:05, Jed Brown wrote:
> On Thu, May 31, 2012 at 5:26 PM, Jozsef Bakosi <jbakosi at lanl.gov> wrote:
> 
> > Great. Thanks. When I pass these options on the command line, how can I
> > get a feedback to see if the option has actually been used or not?
> >
> 
> -options_left shows whether the option was queried
> 
> -ksp_view will have a line "tolerance for zero pivot" telling you what was
> actually used
> 
> 
> > > > > What discretization are you using?
> > > >
> > > > Straightforward Galerkin FEM Poisson solver.
> > > >
> > >
> > > What boundary conditions? I'm guessing the constant is in the null space,
> > > in which case the coarse space really should be singular and you should
> > not
> > > be trying to solve it with a direct solver.
> >
> > I do set the additive constant. I have no problem with this on lower
> > core-counts.
> >
> 
> What do you mean by "set the additive constant"? How do you enforce it?
> Best option is usually to tell the KSP about the null space and use an
> inexact coarse level solver. If you use ML with default options, the coarse
> levels are generally small enough that you can brute-force it by using
> -mg_coarse_redundant_pc_type svd. If you need big coarse spaces, you'll
> probably need to use an inexact coarse level solver (possibly use a shift,
> as in -pc_coarse_redundant_pc_factor_shift_type nonzero.

I mean I grab one node with a Dirichlet condition and apply a Neumann on
all boundaries, i.e. the problem is well-posed: the additive constant,
up to which the solution is determined, is accounted for.

> > I did another test and set the PETSC_OPTIONS environment variable to
> > '-options_table -options_left', then I get:
> >
> > ...
> >
> > [49]PETSC ERROR: Zero pivot row 537 value 9.36276e-13 tolerance 1e-12!
> >
> 
> This is an error. How do you get to the output shown below?

I'm not sure if I understand your question. I set PETSC_OPTIONS
environment variable to '-options_table -options_left'.

> 
> > ...
> >
> > #PETSc Option Table entries:
> > -mg_levels_ksp_norm_type no
> > -mg_levels_ksp_richardson_scale 0.90
> > -mg_levels_ksp_type richardson
> > -mg_levels_pc_type bjacobi
> > -mg_levels_sub_ksp_norm_type no
> > -mg_levels_sub_ksp_type preonly
> > -mg_levels_sub_pc_type icc
> > -options_left
> > -options_table
> > -pc_asm_overlap 1
> > -pc_mg_cycle_type v
> > -pc_mg_smoothdown 1
> > -pc_mg_smoothup 1
> > -pc_ml_maxCoarseSize 1500
> > -pc_ml_maxNlevels 10
> > -pc_type asm
> > -sub_pc_factor_levels 0
> > -sub_pc_factor_zeropivot 1e-20
> > -sub_pc_type ilu
> > #End of PETSc Option Table entries
> > There are no unused options.
> >
> > So how do I tell, which zeropivot setting (the 1e-20 or the 1e-12) is the
> > one petsc is using?

It seems like your suggestion 

-mg_coarse_redundant_pc_factor_zeropivot <2.22045e-14>: Pivot is considered zero if less than (PCFactorSetZeroPivot)

remedies the problem as I'm not getting the zeropivot error anymore. I
guess the problem was at the coarsest MG level. I set
mg_coarse_redundent_pc_factor to 1.0e-20 and that helped.

Thanks,
Jozsef