On Tue, Feb 28, 2012 at 12:11 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  The DM public interface is the _single_ interface that provides all the information the algebraic solvers need to do their thing.<br>
<br>
   Barry<br>
<br>
   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).</blockquote>
<div><br></div><div>But this is what is causing the trouble. Vecs need to hold a DM to tell them how to write themselves, but DMs need</div><div>those Vecs to pass to sovlers. These are very different jobs, and thus cause loops.</div>
<div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
On Feb 28, 2012, at 11:50 AM, Matthew Knepley wrote:<br>
<br>
> On Tue, Feb 28, 2012 at 11:47 AM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>> wrote:<br>
> On Tue, Feb 28, 2012 at 11:03, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> So you think this has nothing to do with<br>
>   - Refinement/coarsening<br>
>   - Local evaluation<br>
>   - Partitioning<br>
> It is all implied, and in fact only really works completely for Cartesian stuff.<br>
><br>
> 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.<br>

><br>
><br>
><br>
>  - Modeling approximation (like function spaces, projectors)<br>
><br>
> This is only in the DM interface through coarsening and interpolation.<br>
><br>
> You also need to know this to piece together local evaluations.<br>
><br>
> *If* that is the interface you want DMXX users to implement to expose their physics. The concept is not in the DM interface.<br>
><br>
><br>
><br>
>  - Modeling equations (including decompositions, variable substitutions)<br>
><br>
> 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.)<br>

><br>
> The equations are there explicitly in all these function pointers it is holding. What are you talking about?<br>
><br>
> The local function stuff is in DM_DA, not in DM. The DM interface _only_ exposes collective evaluation.<br>
><br>
> Then I think you are mixing levels, but it appears that the DMs are being passed around to provide this<br>
> "hidden" information which is actually necessary to make everything work underneath, and it is this that<br>
> creates dependency loops.<br>
><br>
>     Matt<br>
><br>
> --<br>
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
> -- Norbert Wiener<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>