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