On Fri, Nov 22, 2013 at 1:21 PM, Barry Smith <[email protected]> wrote:
> > On Nov 22, 2013, at 1:33 PM, Jed Brown <[email protected]> wrote: > > > Barry Smith <[email protected]> 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? > > > > > > > > > >
