[petsc-users] Understanding DMPlexDistribute overlap

[Matthew Knepley]

On Wed, Apr 5, 2017 at 6:03 AM, Francesco Caimmi <francesco.caimmi at polimi.it
> wrote:

> Hi Michael,
>
> thanks for the prompt reply!
>
> While I am happy I mostly got it right, this means I have some kind of
> problem
> I cannot solve on my own. :(
>
> I have this very simple 2D mesh I am experimenting with: a rectangle with
> 64
> vertexes and 45 cells (attached in exodus format as cantilever.e); I am
> using
> in this very simple petsc4py program to read it, define a section and
> output a
> vector. The overlay value can be controlled by the -o command line switch.
> The
> program is executed as:
> mpiexec -np 2 python overlay-test.py -o <overlap_value> -log_view.
>
>
> Everything works smoothly for <overlap_value> = 0 or to 1, but for values
> >2
> the program fails with the error message captured in the attached file
> error.log. Changing the number of processors does not alter the behavior.
> Note
> also that the same holds if I use a mesh generated by DMPlexCreateBoxMesh.
>

Francesco, I will reproduce your problem, but it may take me a few days.

It is strange since we have tests for overlap > 1 that do use
CreateBoxMesh. For example,

  cd src/dm/impls/plex/examples/tests
  make ex12
  mpiexec -n 8 -test_partition -overlap 2 -dm_view ::ascii_info_detail

  Thanks,

     Matt


> I would really appreciate hints on how to solve this issue and I will of
> course provide any needed additional information.
>
> Thank you very much,
> FC
>
> On mercoledì 5 aprile 2017 10:50:59 CEST you wrote:
> > Hi Francesco,
> >
> > Your description is almost correct: the overlap defines the topological
> > depth of shared entities as counted in "neighboring cells", where a cell
> > counts as a neighbor of an owned cell according to the defined adjacency
> > style. So for overlap=0 only facets, edges and vertices may be shared
> > along the partition boundary, whereas for overlap=1 you can expect one
> > additional "layer" of cells around each partition (the partitioning is
> > done based on cell connectivity). For second neighbors, however, you
> > need overlap=2. And yes, there is conceptually no upper bound on the
> > overlap.
> >
> > Hope this helps,
> >
> > Michael
> >
> > On 05/04/17 10:27, Francesco Caimmi wrote:
> > > Dear all,
> > >
> > > I was playing with DMPlex objects and I was trying to exactly figure
> out
> > > what the `overlap` parameter in DMPlexDistribute does.
> > >
> > >  From the tutorial "Flexible, Scalable Mesh and Data Management
> > >
> > > using PETSc DMPlex" (slide 10) and from the work by Knepley et al.
> > > "Unstructured Overlapping Mesh Distribution in Parallel" I somehow got
> the
> > > idea that it should control the "depth" of the mesh overlap.
> > > That is, given the partition boundary, if overlay is set to 0 only the
> > > entities adjacent (in the DMPlex topological sense and with the "style"
> > > defined by the AdjacencyUse routines) to entities at the boundary are
> > > shared, if overlay is 1 the first and the second neighbors (always in
> the
> > > DMPlex topological sense) are shared and so on, up to the point were we
> > > have a full duplicate of the mesh on each process (i.e. there is no
> upper
> > > bound on `overlap`).
> > >
> > > Is this correct or am I -totally- misunderstanding the meaning of the
> > > parameter?
> > >
> > > I am asking this because I see some behavior I cannot explain at
> varying
> > > the value of the overlap, but before going into the details I would
> like
> > > to be sure to understand  exactly what the overlap parameter is
> supposed
> > > to do.
> > >
> > > Many thanks,
>
>
> --
> Francesco Caimmi
>
> Laboratorio di Ingegneria dei Polimeri
> http://www.chem.polimi.it/polyenglab/
>
> Politecnico di Milano - Dipartimento di Chimica,
> Materiali e Ingegneria Chimica “Giulio Natta”
>
> P.zza Leonardo da Vinci, 32
> I-20133 Milano
> Tel. +39.02.2399.4711
> Fax +39.02.7063.8173
>
> francesco.caimmi at polimi.it
> Skype: fmglcaimmi (please arrange meetings by e-mail)
>



-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20170405/961dfffb/attachment-0001.html>