Setting options on matrices obtained from a DM

[Matthew Knepley]

On Thu, Jul 23, 2009 at 8:15 AM, Jed Brown <jed at 59a2.org> wrote:

> Matthew Knepley wrote:
> > 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.
>
> What would the calling sequence look like for getting a Mat from a DM?


MatCreate()
<in any order the setup functions, such as
  MatSetSizes()
  MatPreallocate()
  MatSetType()
each one of these calls a private function like
  MatSetSizes_outoforder()
which registers the method and user data for later processing>
MatSetUp() (which can be called by anyone, executes)


>
> Who calls execute?  Am I not allowed to call MatSetXXX() after


Whoever calls setup. This allows the user to choose to do it, or not,
and its the current paradigm for most objects in PETSc.


>
> MatExecute()?  What about MatGetXXX() before MatExecute()?

It will reregister that function, so you would need another SetUp()
call, exactly the same interface we have now.

MatGet() has exactly the same interface too, namely things might not
be available.


>
>
> > That object would not have to be seen. You would just have a
> >
> >   pc.require("SetSizes", m, n);
> >   pc.require(...)
> >   pc.setup()
>
> Is the Mat/PC/whatever interface or implementation calling this?


No, wrappers as I show above. The user interface would not change.


>
> The config object would need to take ownership of the various arguments,
> including those that are not PetscObject (like preallocation arrays).


No, the registered call would.


>
> The fact that someone has to explicitly call execute makes this solution
> look a lot like a factory, minus the type-level distinction.  With
> configure, the environment is fixed and once a given set of dependencies
> are satisfied, an immutable object can be created.  With PETSc objects,
> the user might insert arbitrary imperative code (including queries and
> setting up one object based on the state of another) during the
> definition of the environment.  I fear that a "set properties, then
> execute" model would be frusratingly restrictive.


It is what we have now. I do not understand any of your objections.

  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/20090723/f7c8c3ff/attachment.html>