add -coarse_pc_type to PETScPreconditioner

Asked by Nico Schlömer on 2013-04-04

I'd like to set -coarse_pc_type in the PETScPreconditioner, but I've got no idea where in the file I should reasonably put the corresponding statement. Hints?

Question information

Language:
English Edit question
Status:
Answered
For:
DOLFIN Edit question
Assignee:
No assignee Edit question
Last query:
2013-04-04
Last reply:
2013-04-09
Garth Wells (garth-wells) said : #1

On 5 April 2013 01:51, Nico Schlömer
<email address hidden> wrote:
> New question #225891 on DOLFIN:
> https://answers.launchpad.net/dolfin/+question/225891
>
> I'd like to set -coarse_pc_type in the PETScPreconditioner, but I've got no idea where in the file I should reasonably put the corresponding statement. Hints?
>

If you take a look the code section in PETScPreconditioner.cpp related
to ML, you'll see come code where this is hardwired (to use something
better than the PETSc LU solver, which is dead slow for anything more
than a extremely small coarse level problem).

We should probably create a PETScMGPreconditoner class to cope with
the large and growing number of multigrid options/parameters. I'll
probably add nested parameters sets to make it easy to set smoothers
for each level. The size of PETScPreconditioner has been growing
considerably with the addition of multigrid options.

Garth

> --
> You received this question notification because you are a member of
> DOLFIN Team, which is an answer contact for DOLFIN.

Nico Schlömer (nschloe) said : #2

Why is it necessary to have a translation layer between FEniCS and PETSc options?
It would seem straightforward to just hand through a dictionary of options over to PETSc, have PETSc decide whether those options make sense or not.
The way it's currently done, it seems one has to constantly catch up with the -- as you point out correctly -- quickly growing number of options PETSc has to offer.

Garth Wells (garth-wells) said : #3

On 8 April 2013 07:56, Nico Schlömer
<email address hidden> wrote:
> Question #225891 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/225891
>
> Nico Schlömer posted a new comment:
> Why is it necessary to have a translation layer between FEniCS and PETSc options?

It's not necessary. The present implementation suited the usage of
preconditioners at the time that it was implemented. The options that
we now make available has outgrown the implementation.

> It would seem straightforward to just hand through a dictionary of options over to PETSc, have PETSc decide whether those options make sense or not.

This is probably the best approach. The downside is that we will
effectively bypass the DOLFIN parameters system, with the upside that
it will be maintainable. PETSc parameter checking is limited when
PETSc is not compiler in debug mode. Another issue/downside is the
control of parameters that are common to different preconditioner
backends.

Garth

> The way it's currently done, it seems one has to constantly catch up with the -- as you point out correctly -- quickly growing number of options PETSc has to offer.
>
> --
> You received this question notification because you are a member of
> DOLFIN Team, which is an answer contact for DOLFIN.

Anders Logg (logg) said : #4

On Tue, Apr 09, 2013 at 06:41:23AM -0000, Garth Wells wrote:
> Question #225891 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/225891
>
> Garth Wells proposed the following answer:
> On 8 April 2013 07:56, Nico Schlömer
> <email address hidden> wrote:
> > Question #225891 on DOLFIN changed:
> > https://answers.launchpad.net/dolfin/+question/225891
> >
> > Nico Schlömer posted a new comment:
> > Why is it necessary to have a translation layer between FEniCS and PETSc options?
>
> It's not necessary. The present implementation suited the usage of
> preconditioners at the time that it was implemented. The options that
> we now make available has outgrown the implementation.
>
> > It would seem straightforward to just hand through a dictionary of
> options over to PETSc, have PETSc decide whether those options make
> sense or not.
>
> This is probably the best approach. The downside is that we will
> effectively bypass the DOLFIN parameters system, with the upside that
> it will be maintainable. PETSc parameter checking is limited when
> PETSc is not compiler in debug mode. Another issue/downside is the
> control of parameters that are common to different preconditioner
> backends.

We might rely on command-line parameters for PETSc in combination with
KrylovSolver::set_options_prefix.

--
Anders

Can you help with this problem?

Provide an answer of your own, or ask Nico Schlömer for more information if necessary.

To post a message you must log in.