Matthew Knepley <[email protected]> writes: > On Fri, Nov 22, 2013 at 1:33 PM, Jed Brown <[email protected]> wrote: > >> 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.
Sorry, I meant for the empty matrix to be created in advance so that PCSetFromOptions_Factor could call MatSetFromOptions. > 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. Yeah, and I don't know how to do it without a lot more plumbing. Creating empty objects for the various parts is possible without much boilerplate, but then the options are gotten before we have much information so it becomes harder to set defaults. The handling of KSPSetPCSide and KSPSetNormType (having a default value that is collapsed lazily if not set in advance) is one possible model for options where we want dependent defaults.
pgplf9huMlNHs.pgp
Description: PGP signature
