<div dir="ltr"><div dir="ltr">On Wed, Oct 2, 2019 at 10:02 AM Fabian.Jakub <<a href="mailto:Fabian.Jakub@physik.uni-muenchen.de">Fabian.Jakub@physik.uni-muenchen.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Matt,<br>
I see now that it does not have anything to do with the overlap, it is<br>
just the distribute itself.<br>
<br>
I attach two images with the cell ownership of the mesh on four ranks.<br>
Once before and once after the distribute call.<br>
<br>
I guess this comes from the way in which I generate the mesh.<br>
I start with a 2D triangle mesh horizontally, which is distributed.<br>
After that, I extrude the mesh vertically.<br>
<br>
Now it seems that the partitioner deems a different partitioning better<br>
for the 3D mesh.<br>
<br>
Can I prevent DMPlexDistribute to do that?<br></blockquote><div><br></div><div>So you want Distribute to somehow keep together columns? I see at least three ways to do this, all of which</div><div>involve some coding:</div><div><br></div><div>1) Code your own partitioner: Distribute() just takes input from a PetscPartitioner, so you could make your own</div><div>    that did completely what you want.</div><div><br></div><div>2) GIve edge weights to ParMetis: Calculating the weights would involve determining which cells were vertical</div><div>     neighbors, which would involve writing some code.</div><div><br></div><div>3) Partition a 2D mesh: This is like 1) since you could implement it this way:</div><div><br></div><div>    a) Pull off the top surface as a submesh (not hard)</div><div><br></div><div>    b) Partition it (not hard)</div><div><br></div><div>    c) Compute a partition of the 3D mesh based on the 2D partition (as hard as 2)</div><div><br></div><div>  Thanks,</div><div><br></div><div>     Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Many Thanks,<br>
Fabian<br>
<br>
<br>
On 10/2/19 12:19 PM, Matthew Knepley wrote:<br>
> On Tue, Oct 1, 2019 at 7:39 PM Fabian.Jakub via petsc-users <<br>
> <a href="mailto:petsc-users@mcs.anl.gov" target="_blank">petsc-users@mcs.anl.gov</a>> wrote:<br>
> <br>
>> Dear Petsc team,<br>
>> dear Matt,<br>
>><br>
>> I have a 3D, distributed DMPlex with 0 overlap in FVM adjacency.<br>
>> Now, I would like to add overlap but not change the local portions.<br>
>> I was wondering if you could suggest how to do that best/easiest.<br>
>><br>
>> My problem is that just using DMPlexDistribute changes the partitioning,<br>
>> i.e. cells change owners.<br>
>><br>
>> I guess I could trace the steps you took in<br>
>> DMPlexDistributeOverlap<br>
>><br>
> <br>
> DistributeOverlap() should not change the partition. Are you sure it does?<br>
> I think you just call that.<br>
> <br>
>   Thanks,<br>
> <br>
>     Matt<br>
> <br>
> <br>
>> and the following stuff you have in<br>
>> DMPlexDistribute() { if overlap > 0 }<br>
>><br>
>> Another thought was to use a custom partitioner so as not to change the<br>
>> local layouts. Is this a good idea?<br>
>><br>
>> In case that you suggest to go for first steps (the duplication of the<br>
>> DMPlexDistributeOverlap stuff) could you add a fortran stub for it?<br>
>><br>
>> Many thanks,<br>
>><br>
>> Fabian<br>
>><br>
> <br>
> <br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>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><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>