Matthew Knepley wrote: > No comments? Not even "This is complete shit!"?
Heh, it might be overkill and, if I understand you correctly, I think it could be a headache. There is a reasonable amount of code in the various interfaces to ensure some sequencing, but delayed evaluation is tough to reason about. When I call a function, I expect strict evaluation, but if you somehow store that call away until it's dependencies are satisfied, I'm likely to see confusing behavior. > 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 How would you specify these? In the general case, we have a partial ordering on setup functions. I suppose you are suggesting that any time you register a setup function, all dependencies would be given explicitly (hence added to the DAG, or referenced if they were already there). It seems to me that we have rather few setup steps that require a particular sequence, some of which are not necessary. I would rather refactor to eliminate unnecessary dependencies than deal with delayed evaluation. If that looks especially complex, some dependency-handling object might help (probably just within the implementations for which it is necessarily complex), but I don't think it should be visible to the user. I think it would help to enumerate the dependencies that really are fundamental, and those that could (with work) be eliminated. Here's a start, I'm certainly missing some. Vec * sizes before type, not fundamental Mat * sizes before type, not fundamental, currently cached when type is "set" first which causes other problems * type before preallocation, fundamental KSP/PC * operators set before SetFromOptions, is this fundamental? * operators set before SetUp, fundamental SNES * function/Jacobian before SetFromOptions, is this fundamental? * function/Jacobian before SetUp, fundamental TS * similar to SNES Some cases, such as PC_ASM and PC_FieldSplit, would need different options management in order to set all the options in SetFromOptions. They create new matrices and KSP objects from the preconditioning matrix which doesn't exist before Solve/SetUp. It would be possible to move most of this into PCSetFromOptions_XXX if we could call KSPSetFromOptions before KSPSetOperators. It would also make it possible for the user to control these programmatically (currently the inner KSP cannot be created until solve, at which point it's too late for the user to manipulate it). Ideally we would have no dependencies between "personality" (types and options) and "mechanics" (for lack of a better term -- sizes, operators, preallocation). The former can influence the latter (changing the type changes the mechanics), but I think a mandatory ordering is bad (except where necessary, setting an option for a specific type obviously must happen after that type is set). Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20090722/f03e611c/attachment.pgp>