[petsc-dev] viewing factored matrices

[Barry Smith]

On Nov 22, 2013, at 3:34 PM, Dmitry Karpeyev <karpeev at mcs.anl.gov> wrote:

> 
> 
>   
>  
> Sometimes the solver throws an error before completing (e.g., zero pivot somewhere in the bowels of PCFieldSplit), and -ksp_view never fires. Why not have KSPView() called after KSPSetUp(), too?
> 
    We may want a whole set of trigger points that one could indicate giving you this kind of flexibility. Currently we have hard wired _pre and regular.

   Barry


> Dmitry.
> 
>     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?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>