<div class="gmail_quote">On Mon, Jun 6, 2011 at 22:05, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@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">> The argument here is just that an inner object might not have a unique parent. In such cases, it would seem easier to manage if the first parent (or a direct call by the user) took precedence instead of the last parent.<br>

<br>
</div>  Hmm.  Weak argument?<br></blockquote><div><br></div><div>Yeah, this might be an edge case in which a little extra user code is fine.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
    I don't think there is a perfect solution to handling the nesting and I certainly don't think we have enough experience to come up with a great model to handle the nesting yet. We need to start down that road and see where it leads (look we don't even handle the nesting of DM well yet).<br>
</blockquote><div><br></div><div>Note that if the user is actually using a DM, then they can use it to hold their application context. I think this is preferable. Setting the application context directly is (IMO) targeted at users who don't use DM at all.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">  You can use PetscContainerCreate() to keep the pointer to the struct.</div>
<div class="im"><br></div></blockquote><div><br></div><div>Ah, good point.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">  Sounds like something special to MatNest()? Why not just have special MatNest code?</div>
</blockquote></div><br><div>Yeah, that's reasonable. I anticipate the same issue with FETI-DP or anything else that naturally uses a hierarchical matrix format. The current solution is to always have an assembled non-hierarchical representation, but we have mostly focused on Dirichlet Schwarz methods. We can keep it all separate for now and consolidate if it becomes necessary. False sharing is worse than duplicating MatScale_X().</div>