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?

   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

Reply via email to