[petsc-dev] SNES, Coloring, DM, and TS

[Matthew Knepley]

On Tue, Feb 28, 2012 at 12:11 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
>  The DM public interface is the _single_ interface that provides all the
> information the algebraic solvers need to do their thing.
>
>   Barry
>
>   Yes it involves bits and pieces of information about the topology, the
> geometry, the function spaces, and the particular equations being solved.
> This does not mean that all those things need be wrapped up inside one
> monolithic class on the back end (though they are for DA).


But this is what is causing the trouble. Vecs need to hold a DM to tell
them how to write themselves, but DMs need
those Vecs to pass to sovlers. These are very different jobs, and thus
cause loops.

   Matt


> On Feb 28, 2012, at 11:50 AM, Matthew Knepley wrote:
>
> > On Tue, Feb 28, 2012 at 11:47 AM, Jed Brown <jedbrown at mcs.anl.gov>
> wrote:
> > On Tue, Feb 28, 2012 at 11:03, Matthew Knepley <knepley at gmail.com>
> wrote:
> > So you think this has nothing to do with
> >   - Refinement/coarsening
> >   - Local evaluation
> >   - Partitioning
> > It is all implied, and in fact only really works completely for
> Cartesian stuff.
> >
> > It's not in the DM *interface*. Implementing the interface for an
> unstructured grid, etc, will involve *doing* these things, but it doesn't
> mean that the logic needs to be in your DM_XXX() or that we need another
> public object to share stuff between DMs.
> >
> >
> >
> >  - Modeling approximation (like function spaces, projectors)
> >
> > This is only in the DM interface through coarsening and interpolation.
> >
> > You also need to know this to piece together local evaluations.
> >
> > *If* that is the interface you want DMXX users to implement to expose
> their physics. The concept is not in the DM interface.
> >
> >
> >
> >  - Modeling equations (including decompositions, variable substitutions)
> >
> > This is only in the DM interface with collective semantics. (For
> nonlinear ASM, I would be in favor of getting a subdomain DM which would
> have collective semantics on the subcommunicator instead of putting "local"
> evaluation into the public interface.)
> >
> > The equations are there explicitly in all these function pointers it is
> holding. What are you talking about?
> >
> > The local function stuff is in DM_DA, not in DM. The DM interface _only_
> exposes collective evaluation.
> >
> > Then I think you are mixing levels, but it appears that the DMs are
> being passed around to provide this
> > "hidden" information which is actually necessary to make everything work
> underneath, and it is this that
> > creates dependency loops.
> >
> >     Matt
> >
> > --
> > 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/20120228/90f8cb47/attachment.html>