Setting options on matrices obtained from a DM

[Barry Smith]

On Jul 21, 2009, at 7:47 PM, Jed Brown 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().

     This is just a limitation of the current implementation due to  
the way the design evolved over time.
There is nothing intrinsic to the abstract design of PETSc that  
prevents the type from being
properly processed before the sizes are set.

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

    This is really yucky API you propose here; that no sane person  
would propose except to work
around a shortfall in the current implementation.

    Barry



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