<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 5, 2017 at 6:03 AM, Francesco Caimmi <span dir="ltr"><<a href="mailto:francesco.caimmi@polimi.it" target="_blank">francesco.caimmi@polimi.it</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Michael,<br>
<br>
thanks for the prompt reply!<br>
<br>
While I am happy I mostly got it right, this means I have some kind of problem<br>
I cannot solve on my own. :(<br>
<br>
I have this very simple 2D mesh I am experimenting with: a rectangle with 64<br>
vertexes and 45 cells (attached in exodus format as cantilever.e); I am using<br>
in this very simple petsc4py program to read it, define a section and output a<br>
vector. The overlay value can be controlled by the -o command line switch. The<br>
program is executed as:<br>
mpiexec -np 2 python overlay-test.py -o <overlap_value> -log_view.<br>
<br>
<br>
Everything works smoothly for <overlap_value> = 0 or to 1, but for values >2<br>
the program fails with the error message captured in the attached file<br>
error.log. Changing the number of processors does not alter the behavior. Note<br>
also that the same holds if I use a mesh generated by DMPlexCreateBoxMesh.<br></blockquote><div><br></div><div>Francesco, I will reproduce your problem, but it may take me a few days.</div><div><br></div><div>It is strange since we have tests for overlap > 1 that do use CreateBoxMesh. For example,</div><div><br></div><div> cd src/dm/impls/plex/examples/tests</div><div> make ex12</div><div> mpiexec -n 8 -test_partition -overlap 2 -dm_view ::ascii_info_detail</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">
I would really appreciate hints on how to solve this issue and I will of<br>
course provide any needed additional information.<br>
<br>
Thank you very much,<br>
FC<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
On mercoledì 5 aprile 2017 10:50:59 CEST you wrote:<br>
> Hi Francesco,<br>
><br>
> Your description is almost correct: the overlap defines the topological<br>
> depth of shared entities as counted in "neighboring cells", where a cell<br>
> counts as a neighbor of an owned cell according to the defined adjacency<br>
> style. So for overlap=0 only facets, edges and vertices may be shared<br>
> along the partition boundary, whereas for overlap=1 you can expect one<br>
> additional "layer" of cells around each partition (the partitioning is<br>
> done based on cell connectivity). For second neighbors, however, you<br>
> need overlap=2. And yes, there is conceptually no upper bound on the<br>
> overlap.<br>
><br>
> Hope this helps,<br>
><br>
> Michael<br>
><br>
> On 05/04/17 10:27, Francesco Caimmi wrote:<br>
> > Dear all,<br>
> ><br>
> > I was playing with DMPlex objects and I was trying to exactly figure out<br>
> > what the `overlap` parameter in DMPlexDistribute does.<br>
> ><br>
> > From the tutorial "Flexible, Scalable Mesh and Data Management<br>
> ><br>
> > using PETSc DMPlex" (slide 10) and from the work by Knepley et al.<br>
> > "Unstructured Overlapping Mesh Distribution in Parallel" I somehow got the<br>
> > idea that it should control the "depth" of the mesh overlap.<br>
> > That is, given the partition boundary, if overlay is set to 0 only the<br>
> > entities adjacent (in the DMPlex topological sense and with the "style"<br>
> > defined by the AdjacencyUse routines) to entities at the boundary are<br>
> > shared, if overlay is 1 the first and the second neighbors (always in the<br>
> > DMPlex topological sense) are shared and so on, up to the point were we<br>
> > have a full duplicate of the mesh on each process (i.e. there is no upper<br>
> > bound on `overlap`).<br>
> ><br>
> > Is this correct or am I -totally- misunderstanding the meaning of the<br>
> > parameter?<br>
> ><br>
> > I am asking this because I see some behavior I cannot explain at varying<br>
> > the value of the overlap, but before going into the details I would like<br>
> > to be sure to understand exactly what the overlap parameter is supposed<br>
> > to do.<br>
> ><br>
> > Many thanks,<br>
<br>
<br>
</div></div><div class="gmail-HOEnZb"><div class="gmail-h5">--<br>
Francesco Caimmi<br>
<br>
Laboratorio di Ingegneria dei Polimeri<br>
<a href="http://www.chem.polimi.it/polyenglab/" rel="noreferrer" target="_blank">http://www.chem.polimi.it/<wbr>polyenglab/</a><br>
<br>
Politecnico di Milano - Dipartimento di Chimica,<br>
Materiali e Ingegneria Chimica “Giulio Natta”<br>
<br>
P.zza Leonardo da Vinci, 32<br>
I-20133 Milano<br>
Tel. <a href="tel:%2B39.02.2399.4711" value="+390223994711">+39.02.2399.4711</a><br>
Fax <a href="tel:%2B39.02.7063.8173" value="+390270638173">+39.02.7063.8173</a><br>
<br>
<a href="mailto:francesco.caimmi@polimi.it">francesco.caimmi@polimi.it</a><br>
Skype: fmglcaimmi (please arrange meetings by e-mail)<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">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></div>