[petsc-dev] Fwd: Problematic Merge of FieldSplit
Matthew Knepley
knepley at gmail.com
Fri Jul 6 21:35:45 CDT 2012
On Fri, Jul 6, 2012 at 8:18 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
> I don't understand this thread but I see nothing wrong with options like
>
> -fieldsplit_0_fieldsplit_0_fieldsplit_0....
>
> when using three nested levels of fieldsplit in the same way that three
> levels of block Jacobi (or ASM) gives -sub_sub_sub....
>
> The recursive nature of the prefixes should be completely natural and
> not require any special code ....
>
> Providing a prefix in the command line for other options seems terrible
> to me. Using the word inner also seems terrible; when you have _sub_sub
> that is clearly inner
>
> Could someone explain to me what prefixes are being generated that
> are not the normal recursive process and why?
Sure, that is how it works in general. The point here is the distinction
between A^{-1} in the (0,0) block and
A^{-1} embedded in S, which I will call A^{-1}_S. Right now we have
a) A^{-1}_S and S have the same prefix
which Dmitry does not want (perfectly reasonable). Before we had
b) A^{-1} and A^{-1}_S had the same prefix
which I do not want since it makes things like SIMPLE hard. I wanted
c) A^{-1}_S has prefix <prefix of S>_sub
but Dmitry said this was a hassle for normal setups and suggested that
we have some option that allows A^{-1} and A^{-1}_S to have different
prefixes.
Matt
>
> Barry
>
> On Jul 6, 2012, at 8:39 AM, Matthew Knepley wrote:
>
> > On Fri, Jul 6, 2012 at 7:28 AM, Dmitry Karpeev <karpeev at mcs.anl.gov>
> wrote:
> >
> > On Fri, Jul 6, 2012 at 8:17 AM, Matthew Knepley <knepley at gmail.com>
> wrote:
> > On Fri, Jul 6, 2012 at 5:06 AM, Dmitry Karpeev <karpeev at mcs.anl.gov>
> wrote:
> > Here's the line in question (also see the immediately preceding code):
> > http://petsc.cs.iit.edu/petsc/petsc-dev/rev/0d4ccb990bb8#l1.127
> >
> > As long as we are fixing this, I would rather not repeat the prefix,
> since we will likely want to
> > configure this differently than the block 0 solve. Is any thing wrong
> with
> >
> > schurprefix+"_sub"
> > If the inner and outer KSP prefixes are different, it will force one to
> repeat all of the configuration options for the inner and outer A00
> solvers, even when it is desirable to keep them identical.
> > This becomes tedious, if the A00 solvers configuration is involved
> (e.g., a nested fieldsplit with separate options for the splits etc.).
> > I would advocate making the inner solver use the same prefix as the
> outer solver by default, and allowing the user to specify
> > a separate prefix for the inner solver, if it is to be configured
> differently. For example:
> > -fieldsplit_0_schur_prefix fieldsplit_0_inner -fieldsplit_0_ksp_type
> gmres -fieldsplit_0_inner_ksp_type preonly etc.
> >
> > As long as there is a way to do it.
> >
> > Matt
> >
> > Dmitry.
> >
> >
> >
> > Matt
> >
> > Dmitry.
> >
> >
> > ---------- Forwarded message ----------
> > From: Dmitry Karpeev <karpeev at mcs.anl.gov>
> > Date: Fri, Jul 6, 2012 at 6:04 AM
> > Subject: Re: [petsc-dev] Problematic Merge of FieldSplit
> > To: For users of the development version of PETSc <petsc-dev at mcs.anl.gov
> >
> >
> >
> > I have the following problem with the prefix choice for the
> MatSchurComplement KSP introduced in this changeset (
> http://petsc.cs.iit.edu/petsc/petsc-dev/rev/0d4ccb990bb8).
> > I'm talking about the "inner" KSP for A00, effecting inv(A00) in the
> definition S = A11 - A10 inv(A00) A01.
> > We also have the "outer" inv(A00) KSP, which gets prefix "0". I
> recently set the "inner" inv(A00) KSP
> > prefix to "0", simply by inheriting it from the "outer" solver. Now, it
> is completely reasonable
> > to expect the inner and outer A00 KSPs to have different prefixes so
> that they can be configured differently.
> > In fact, there was a recent petsc-users request related to this (
> http://lists.mcs.anl.gov/pipermail/petsc-users/2012-June/014005.html).
> > However, currently the inner A00 KSP inherits the prefix from the A11
> KSP corresponding to the "1" field. With this prefix choice
> > I end up configuring inv(A00) and inv(S) identically, which isn't what I
> want at all.
> > I'm not sure what the right approach is, but the current one doesn't
> work for me.
> >
> > Note also that if A00 is treated with a recursive split, there may be
> numerous options for the A00 KSP.
> > Do we want to repeat them for the inner and outer KSPs, if we want to
> configure them identically?
> > It's automatic, if the two A00 KSPs share a prefix. Again, this takes
> away some flexibility, so maybe it's not the best solution,
> > but I think retaining a simple option for using identical configurations
> is also highly desirable.
> >
> > Any ideas on how to handle this?
> > Dmitry.
> >
> > On Tue, Jun 26, 2012 at 6:13 AM, Matthew Knepley <knepley at gmail.com>
> wrote:
> > It turns out that 'hg rollback' during an 'hg rebase' does not do what I
> thought it did. I think
> > everything is cleaned up with this push, but if you made FS changes in
> the past month, please
> > check that it is doing what you want with prefixes, etc.
> >
> > Now, nested fieldsplits from the command line work, ala
> >
> > -ksp_type fgmres
> > -pc_type fieldsplit -pc_fieldsplit_type additive
> > -pc_fieldsplit_0_fields 0,1
> > -fieldsplit_0_pc_type fieldsplit
> > -fieldsplit_0_pc_fieldsplit_type schur
> -fieldsplit_0_pc_fieldsplitschur_factorization_type full
> > -fieldsplit_0_fieldsplit_velocity_ksp_type preonly
> > -fieldsplit_0_fieldsplit_velocity_pc_type lu
> > -fieldsplit_0_fieldsplit_pressure_ksp_rtol 1e-10
> > -fieldsplit_0_fieldsplit_pressure_pc_type jacobi
> > -pc_fieldsplit_1_fields 2
> > -fieldsplit_temperature_ksp_type preonly
> > -fieldsplit_temperature_pc_type lu
> >
> > A split with only one field gets the field name, and otherwise a split
> number.
> >
> > Matt
> >
> > --
> > 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
> >
> >
> >
> >
> >
> > --
> > 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
> >
> >
> >
> >
> > --
> > 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
>
>
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120706/ce573d84/attachment.html>
More information about the petsc-dev
mailing list