[petsc-dev] viewing factored matrices

[Barry Smith]

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

> Barry Smith <bsmith at mcs.anl.gov> writes:
> 
>>   No, I don’t think so. XXXView() has no business calling a
>>   YYSetFromOptions() or YYYViewFromOptions(). In fact I go so far as
>>   saying MatViewFromOptions() should be removed.
>> 
>> I thought we were adopting the model that only XXSetFromOptions()
>> queried the database, not any old random function?
> 
> What if PCSetUp_LU created an empty Mat, set its prefix (to
> "-pc_factor_"), and called MatSetFromOptions?  Then instead of creating
> a new Mat, MatGetFactor would fill up the one that was passed in.  This
> seems compatible with the direction we are going in many other interfaces.

   Yes, this is possible (I realize you suggested this initially). Of course since the Mat is empty no subclass specific stuff about the Mat could be set but this is a known drawback of the “only XXXSetFromOptions() calls should access the database” model.

> 
>>   I was wrong to suggest -pc_factor_mat_view, we don’t need that or want it I think.
> 
> I used to be able to do this from the command line.
> 
>  http://scicomp.stackexchange.com/a/880/119
> 
> I don't care exactly what the options look like, but I'd like to be able
> to do this again.
> 
> The natural place to display the factors is when they are factored
> rather than at the end of KSPSolve().  Note that the same factors might
> be used for many KSPSolves.

    Let’s make this simpler to capture the crux of the issue, which has nothing to do with -pc_factor_mat_view specifically.

    Say we have a KSP problem. The user calls KSPView() to view the entire hierarchy of the solvers/matrices and KSPView() calls the PCView() which calls the MatView() etc ALL ON THE SAME VIEWER.  Now say the user wants to view JUST the PC with a specific viewer (like a draw). In the code they can do KSPGetPC(), PCView() with that specific viewer. 

   Now we want to reproduce that same capability via the options database. -ksp_view OPTIONS triggers a hierarchical view of KSP, PC, Mat with the given OPTIONS (and possible viewer in the options). When does the view actually take place? for KSP I guess it makes sense after KSPSolve. 

    Now it seems doing -pc_view OPTIONS should have the same effect as KSPGetPC(), PCView() and where does the view actually take place? As you point out after the PCSetUp() is a logically place.  Note that one could anally argue we  should use the option -ksp_pc_view but let’s not.

   Ok now let’s consider the given case for viewing the matrix. In the code one could do KPSGetPC(), PCFactorGetMatrix(), MatView() so anally the option could be -ksp_pc_factor_mat_view and when would the view get triggered? Well it makes sense right after the factorization. And if we shorten the option name out completely we get -mat_view (but we already have a mat_view for the originally matrix so to prevent problems we could have -factor_mat_view or -pc_factor_mat_view. 

   My conclusion based on the above is that Jed was right and this is the complete model. To implement we can do the following 

1) Each XXXSetFromOptions() looks for -prefix_xxx_view and scarfs up the viewer and stashes it internally

2) Each XXX has a “trigger point” where the actual view is done (if the viewer exists in the option) for regular Mat it is MatAssemblyEnd() for factored matrix it is after the factorization, for PC it is after PCSetUp() for KSP after KSPSolve, for SNES after SNES solver for TS after TSSolve

3) Each XXX also a a variant of the trigger point for “before the operation” (that is used for example by the SAWs view, currently called -ksp_view_pre), for KSP for example it is before KSPSolve.

  The current implementation more or less mimics this from the user point of view except some, like -pc_factor_mat_view disappeared or don’t exist and the options checks are generally done at the trigger point instead of in the setfromoptions.

   I am fine with this model and over time “fixing” the code to move the checks into the appropriate setfromoptions and out of KSPSolve etc.

   Barry

Final note: since someone may want to have -mat_view draw -mat_view ascii in the same run we actually need to maintain a collection of viewers for each trigger point not just one so we should bump this operation process up to the level of PetscObject to get reuse of the code rather than rewriting the management Mat, PC, KSP etc etc. Someone should add this to the issues list on the bitbucket site. Just cut and paste this email?