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>