On Tue, Feb 28, 2012 at 11:03, Matthew Knepley <[email protected]> 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.