Setting options on matrices obtained from a DM

[Matthew Knepley]

On Wed, Jul 22, 2009 at 3:57 PM, Jed Brown <jed at 59a2.org> wrote:

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

They way we resole this in configure is to have an "execute" function. I
think
this would be pretty much the behavior people expect.


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


Yes, this pretty simple. Our interface is easy. Take a look at the configure
class Framework and the method require().


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


That object would not have to be seen. You would just have a

  pc.require("SetSizes", m, n);
  pc.require(...)
  pc.setup()


>
> 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)


This already sounds needlessly complicated to me. It also sounds like we are
introducing this complication because the language stinks, not because we
have not figured out an easy way to do it (which we already use elsewhere
for
the exact same purpose).

  Matt


>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20090722/0082cb1c/attachment.html>