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
