Actually, this seems like the same problem that Lisandro is having, just with<br>different functions. I propose making data structures do the work for us<br>rather than complicated organization in an imperative program.<br>
<br>We could use the same mechanism we use in configure to handle issues of<br>object setup. We have a setup object that takes<br><br>  a) an object to be setup<br><br>  b) a set of functions to be called for setup, and<br>
<br>  c) any functions which must be called prior to each given function<br><br>This way we can flexibly add as many functions as necessary, and then they<br>can be topologically sorted and executed.<br><br>There will be some implementation issues in C, due to severe limitations with<br>
calling conventions, but I think these can all be solved.<br><br>Comments?<br><br>   Matt<br><br><div class="gmail_quote">On Tue, Jul 21, 2009 at 7:47 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org">jed@59a2.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">Barry Smith wrote:<br>
<br>
>    Could you call MatSetFromOptions() twice, once before the<br>
> DAGetMatrix() call to set the type and then after the DAGetMatrix() to<br>
> set particular options for what you set?<br>
<br>
</div>This is okay as long as we don't get more global matrix options (this<br>
state appears to be stable).  It's a little clumsy to have to call that<br>
function twice, and because preallocation comes last in the usual idiom:<br>
<br>
  MatCreate<br>
  MatSetSizes<br>
  MatSetFromOptions<br>
  MatXXXSetPreallocation<br>
<br>
If the matrix type wants anything (programmatic) to be done before<br>
preallocation, we don't have a way to do it with your scheme.  That is,<br>
although we might have "set the type" before calling DAGetMatrix(), the<br>
type isn't actually set until the sizes are known, so we can't call any<br>
MatXXXSetYYY() before calling DAGetMatrix().  At the moment, I can't<br>
think of a case were this would be a problem.  The same applies to<br>
anything that could be set by MatSetFromOptions_XXX, but needs to be<br>
done before preallocation.  The hypothetical<br>
<br>
  DMGetMatrix               /* sets sizes, not preallocation or type */<br>
  MatSetOptionsPrefix<br>
  MatSetFromOptions<br>
  DMSetMatPreallocation<br>
<br>
makes it possible to set all the options in MatSetFromOptions, and<br>
allows any MatXXXSetYYY to be called before preallocation.  I can't<br>
think of a case where this is more limiting, but that doesn't mean it<br>
doesn't exist.  It does mean two DM functions rather than one which is<br>
not ideal.<br>
<div class="im"><br>
>    We decided along time ago to cluster all the option setting in<br>
> XXXSetFromOptions() but it does impose some limitations. Too many<br>
> limitations. Are there other models? Having random XXGetOption() in<br>
> any old method is dangerous because it is hard to know what and where<br>
> options are going to be set so I think we are stuck with the<br>
> XXXSetFromOptions() model.<br>
<br>
</div>I agree that keeping as much as possible in XXXSetFromOptions is the<br>
best alternative.  I've seen the mess caused by having too many places<br>
in which options are consulted.  The PETSc creation model is much nicer<br>
to work with than factory objects which enforce more sequencing.<br>
<font color="#888888"><br>
Jed<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener<br>