<div dir="ltr">On Thu, Nov 7, 2013 at 11:30 AM, Michael Lange <span dir="ltr"><<a href="mailto:michael.lange@imperial.ac.uk" target="_blank">michael.lange@imperial.ac.uk</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I am trying to integrate an application code with DMPlex and I'm hitting the following problem: The application code requires owned and ghost DoFs to be numbered contiguously, whereas DMPlex numbers them by entity class, so that the vertex dofs and edge dofs are disjoint. In order to get around this problem I am trying to re-order the DMPlex object vertically by using DMPlexPermute() with a custom mapping such that the closure of cells is numbered contiguously (except for repeated sieve points). This, however, causes DMPlexCreateSection() to create wrong sections, because the depth/height strata are not contiguous anymore; although I can create the appropriate section from the original DMPlex and permute it with the same mapping to get the correct section. From this I am now trying to extract the appropriate information for my halo exchange via the DefaultSF and the LocalToGlobalMap, and what I was wondering is:<br>

<br>
1) Is there an easy way to re-create the appropriate DefaultSF and LocalToGlobalMap after the permutation, since these are ignored in DMPlexPermute()?<br>
<br>
2) Is it possible to use DMLabelGetStratumIS with the "depth" label instead of DMPlexGetDepthStratum in DMPlexCreateSection() in order to make this work with a vertically numbered DMPlex?<br></blockquote><div><br>
</div><div>There is a misunderstanding here. You are confusing point numbering, which is what is in DMPlex and what is modified by</div><div>DMPlexPermute, and dof numbering, which is handled by PetscSection. The point numbering was originally arbitrary, which</div>
<div>made the code complex and slow. I don't think that the stratified scheme will change.</div><div><br></div><div>However, I think all you need to interface with your legacy code is to change the PetscSection ordering. This is fairly simple.</div>
<div>Right now, you set sizes and PetscSectionSetUp() calculated offsets, but nothing in the code assumes that the offsets are</div><div>strictly ordered. Thus, you can just recalculate the offsets traversing along your permuted ordering and calling PetscSectionSetOffset().</div>
<div>Does this make sense?</div><div><br></div><div>  Thanks,</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">
Kind regards,<br>
<br>
Michael Lange<br>
</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
</div></div>