On Nov 22, 2013, at 3:34 PM, Dmitry Karpeyev <[email protected]> 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?
>
>
>
>
>
>
>
>
>
>
>
>
>
