<div class="gmail_quote">On Mon, May 28, 2012 at 5:10 PM, Dmitry Karpeev <span dir="ltr"><<a href="mailto:karpeev@mcs.anl.gov" target="_blank">karpeev@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, May 28, 2012 at 5:02 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


This is an enormous amount of new code and changes to put in during a code freeze, but my test case works now. </blockquote></div><div>We can revert, if it starts causing problems.  The extra code is due to the API chance, hence several new interface functions.</div>
<div class="im">

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A couple comments  from looking at the patch:<div><br></div><div>I'm not sure I like the direction of the link in DMSetEmbedding(DM dm, IS embedding, DM ambientdm). Normally the composite DM knows how to fit its pieces together, but the sub-DM does not have "upward links" to the global problem.</div>


</blockquote></div><div>This is to be able to combine domain and field splits: sometimes a subDM has to know how to "relativize" itself with respect to another subDM. </div></blockquote><div><br></div><div>I don't believe it has to. The current approach in PETSc has always been that we store links going the other direction. I don't like the inconsistency and I think the model is much more sustainable to hold downward links only.</div>
<div><br></div><div>What algorithm can only be implemented with these upward links?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div><br></div><div>There are dead links in your documentation because you reference functions that don't exist (were renamed), e.g. DMCreateDecomposition() in the DMSetEmbedding() man page. There may be more. You should generate the docs and check the man pages. </div>


</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>How does your interface support "Neumann" subdomains? </div></blockquote><div> </div></div><div>I think this issue is orthogonal to the definition of the decomposition, since there has to be additional support at the PC</div>


<div>and Mat level to assemble the Neumann subproblems.  At this point you would have to do some combination of PCASMSetModifySubmatrices() with nullspace removal.</div></blockquote><div><br></div><div>Sure, you have to assemble to a different format, but what interface are we going to use. In the linear case, we can, in principle, do everything with matrices. For the nonlinear case, we need DM APIs. So in the nonlinear context, how are we going to build Neumann problems?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div></div><div>Your DMCreateDomainDecomposition() seems to provide nominally overlapping index sets, but how do we determine what part is owned? (RASM, especially, needs both an overlapping decomposition and a (non-overlapping) partition.</div>


</blockquote></div><div>My intent was to have these be nonoverlapping and expand them with another call (e.g., DMDomainDecompositionIncreaseOverlap(). </div></blockquote><div><br></div><div>But with separate functions, we have to jump through extra hoops to use a user-specified decomposition (e.g. that carefully selects Lagrange multipliers or pressure variables to maintain inf-sup stability).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> The current API plays better with GASM, since that PC assumes that the basic subdomains are nonoverlapping. That fix will have to wait for the next release, I guess. </div>
</blockquote></div><br><div>PCGASMSetSubdomains() also has two IS arguments, so I don't know what you mean.</div><div><br></div><div><br></div><div>We need to work out an interface for nonlinear DD (like ASPIN) this summer, but I don't think it belongs in this release. I'm not so wild about putting new interfaces into this release that will be changed immediately after.</div>