Setting options on matrices obtained from a DM

[Jed Brown]

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