On Fri, 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 > I agree with Barry that this should not happen. I would not object to PCSetFromOptions_Factor calling it on the matrix. I think this rule that we only consult options from SetFromOptions should be explored. Its certainly more modular, and makes it easy to revamp how options are consulted, etc. I am guessing we will need to change our interface sometime to allow provenance information. Is there a conceptual problem with storing the view options? My problem is that it seems possible that you know almost nothing about how to setup at the time of SetFromOptions() and you end up storing almost all the options. Matt > 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. > > > 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. > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener
