Setting options on matrices obtained from a DM

[Barry Smith]

On Jul 21, 2009, at 7:00 PM, Jed Brown wrote:

> Barry Smith wrote:
>>
>>    My eventual goal is to remove all "hidden" MatCreate()'s and
>> instead have Mat's passed in as arguments. So MatLoad() would take a
>> Mat as an argument, as would DAGetMatrix() One could then set as much
>> or a as little as a Mat as they like before passing it in.  They  
>> could
>> set the type, they could set the sizes, they could set the prefix.
>
> Right, though setting sizes before DAGetMatrix() wouldn't be  
> meaningful.
>
>>   I think this is the direction you want? Will it satisfy all your  
>> needs?
>>
>>   MatCreate().
>>   MatSetOptionsPrefix()
>>   MatSetFromOptions()
>>   DAGetMatrix()
>
> This will work at present, but it's not perfect (without Mat
> adjustments).  Some options would be set as a consequence of the
> MatSetSizes() which occurs within DMGetMatrix() (ops->create() is  
> saved
> until the sizes are known).  If a matrix type implements
> MatSetFromOptions (currently just SchurComplement), that function  
> would
> never get called in this scheme (because that operation won't be set
> until the sizes are known).  This could be handled by modifying the
> matrix types so that MatCreate_XXX() could be called before
> MatSetSizes(), but this is nontrivial.
>

    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?

    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.




    Barry

> Jed
>