Setting options on matrices obtained from a DM

[Jed Brown]

Barry Smith wrote:

>    Could you call MatSetFromOptions() twice, once before the
> DAGetMatrix() call to set the type and then after the DAGetMatrix() to
> set particular options for what you set?

This is okay as long as we don't get more global matrix options (this
state appears to be stable).  It's a little clumsy to have to call that
function twice, and because preallocation comes last in the usual idiom:

  MatCreate
  MatSetSizes
  MatSetFromOptions
  MatXXXSetPreallocation

If the matrix type wants anything (programmatic) to be done before
preallocation, we don't have a way to do it with your scheme.  That is,
although we might have "set the type" before calling DAGetMatrix(), the
type isn't actually set until the sizes are known, so we can't call any
MatXXXSetYYY() before calling DAGetMatrix().  At the moment, I can't
think of a case were this would be a problem.  The same applies to
anything that could be set by MatSetFromOptions_XXX, but needs to be
done before preallocation.  The hypothetical

  DMGetMatrix               /* sets sizes, not preallocation or type */
  MatSetOptionsPrefix
  MatSetFromOptions
  DMSetMatPreallocation

makes it possible to set all the options in MatSetFromOptions, and
allows any MatXXXSetYYY to be called before preallocation.  I can't
think of a case where this is more limiting, but that doesn't mean it
doesn't exist.  It does mean two DM functions rather than one which is
not ideal.

>    We decided along time ago to cluster all the option setting in
> XXXSetFromOptions() but it does impose some limitations. Too many
> limitations. Are there other models? Having random XXGetOption() in
> any old method is dangerous because it is hard to know what and where
> options are going to be set so I think we are stuck with the
> XXXSetFromOptions() model.

I agree that keeping as much as possible in XXXSetFromOptions is the
best alternative.  I've seen the mess caused by having too many places
in which options are consulted.  The PETSc creation model is much nicer
to work with than factory objects which enforce more sequencing.

Jed

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20090722/5b139481/attachment.sig>