On Tue, Feb 28, 2012 at 11:47 AM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@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">
<div class="gmail_quote"><div class="im">On Tue, Feb 28, 2012 at 11:03, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>So you think this has nothing to do with</div><div>  - Refinement/coarsening</div><div>  - Local evaluation</div>
<div>  - Partitioning</div><div>It is all implied, and in fact only really works completely for Cartesian stuff.</div></blockquote><div><br></div></div><div>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.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div class="gmail_quote"><div> </div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div> - Modeling approximation (like function spaces, projectors)</div>



</div></blockquote><div><br></div></div><div>This is only in the DM interface through coarsening and interpolation.</div></div></blockquote><div><br></div></div><div>You also need to know this to piece together local evaluations.</div>

</blockquote><div><br></div></div><div>*If* that is the interface you want DMXX users to implement to expose their physics. The concept is not in the DM interface.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div> </div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div class="gmail_quote"><div><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div> - Modeling equations (including decompositions, variable substitutions)</div></div></blockquote><div><br></div></div><div>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.)</div>


</div></blockquote><div><br></div></div><div>The equations are there explicitly in all these function pointers it is holding. What are you talking about?</div></blockquote></div></div><br><div>The local function stuff is in DM_DA, not in DM. The DM interface _only_ exposes collective evaluation.</div>

</blockquote></div><div><br></div>Then I think you are mixing levels, but it appears that the DMs are being passed around to provide this<div>"hidden" information which is actually necessary to make everything work underneath, and it is this that</div>
<div>creates dependency loops.</div><div><br></div><div>    Matt<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>
</div>