[petsc-dev] viewing factored matrices

[Dmitry Karpeyev]

On Fri, Nov 22, 2013 at 1:21 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

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

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?

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?
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131122/c3c2a22b/attachment.html>