[petsc-dev] viewing factored matrices

Jed Brown jedbrown at mcs.anl.gov
Fri Nov 22 13:51:41 CST 2013

Matthew Knepley <knepley at gmail.com> writes:

> On Fri, Nov 22, 2013 at 1:33 PM, Jed Brown <jedbrown at mcs.anl.gov> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131122/99c1dde1/attachment.sig>

More information about the petsc-dev mailing list