[petsc-dev] Fwd: Problematic Merge of FieldSplit

Matthew Knepley knepley at gmail.com
Fri Jul 6 08:17:46 CDT 2012


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"

     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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120706/a2077a8c/attachment.html>


More information about the petsc-dev mailing list