Setting options on matrices obtained from a DM

[Matthew Knepley]

No comments? Not even "This is complete shit!"?

  Matt

On Tue, Jul 21, 2009 at 8:56 PM, Matthew Knepley <knepley at gmail.com> wrote:

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



-- 
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/20090722/0a1e13cc/attachment.html>