Setting options on matrices obtained from a DM

[Matthew Knepley]

Actually, this seems like the same problem that Lisandro is having, just
with
different functions. I propose making data structures do the work for us
rather than complicated organization in an imperative program.

We could use the same mechanism we use in configure to handle issues of
object setup. We have a setup object that takes

  a) an object to be setup

  b) a set of functions to be called for setup, and

  c) any functions which must be called prior to each given function

This way we can flexibly add as many functions as necessary, and then they
can be topologically sorted and executed.

There will be some implementation issues in C, due to severe limitations
with
calling conventions, but I think these can all be solved.

Comments?

   Matt

On Tue, Jul 21, 2009 at 7:47 PM, Jed Brown <jed at 59a2.org> wrote:

> 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
>
>


-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20090721/072f81e6/attachment.html>