[petsc-dev] viewing factored matrices

[Barry Smith]

On Nov 22, 2013, at 5:57 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Barry Smith <bsmith at mcs.anl.gov> writes:
>>> What about -mg_levels_2_mat_view or -fieldsplit_pressure_mat_view?  If
>>> the number of levels or the fieldsplit names are obtained automatically
>>> From the matrix, then the object cannot reasonably exist at
>>> PCSetFromOptions.  Or is there a way?
>> 
>>  Ahh, but the XXX/PCSetFromOptions for the inner PC IS called after
>>  the inner KSP/PC is created! Hence
>>  -fieldsplit_pressure_factor_mat_view should work. Search for
>>  KSPSetFromOptions() in field split.c and mg.c
>> 
>>   The key is that the calls to the inner XXXSetFromOptions() are not
>>   nested in the calls to the outer XXSetFromOptions() (obviously
>>   because the inner ones do not exist when the outer one is called).
> 
> Indeed, but I thought we wanted to avoid this because it can lead to
> options being checked on each iteration

    No, no, and no.  Look in mg.c 

 if (!pc->setupcalled) {
    for (i=0; i<n; i++) {
      ierr = KSPSetFromOptions(mglevels[i]->smoothd);CHKERRQ(ierr);

  in fieldsplit.c 

   if (!jac->suboptionsset) {ierr = KSPSetFromOptions(ilink->ksp);CHKERRQ(ierr);}

   You are correct that currently there are other unprotected calls in fieldsplit.c but I think they can be easily fixed so that the inner SetFromOptions() is called only when setup called is zero. Having non-nested XXXSetFromOptions() has nothing to do with things being check every iteration stuff.

   My concern is that the PetscOptionsGetXXX() checks in KSPSolve() etc be moved into the SetFromOptions.

> and it's crappy for interactive
> configuration.

   YOU don’t like it for the interactive configuration; I don’t mind it at all :-) because I don’t believe the user needs to go back out the outer options after they have set the inner options.

   I believe it is impossible to nest all the set from options for XXSetFromOptions() and I don’t think this matters at all. And regardless it is orthogonal to 

1) checking options outside of XXXSetFromOptions()

2) making sure that checking options is not in the main stream code when doing computations

> 
> [Two examples that are hard]
> When you use GAMG, you don't know how many levels will exist until
> running with the matrix.  Even the same nonzero pattern can create
> different numbers of levels due to thresholding.

   I don’t see this as relevant to the discussion. 
> 
> Also look where PCFieldSplitSetDefaults() is called from.  The number of
> splits may not be known until PCSetUp_FieldSplit.

    Again, so what?