[petsc-users] Petsc DMPlex GetSupport() issue

Matthew Knepley knepley at gmail.com
Sat Jun 29 15:06:28 CDT 2019


On Sat, Jun 29, 2019 at 12:47 PM Paul Seibert via petsc-users <
petsc-users at mcs.anl.gov> wrote:

> Dear Sir or Madam,
>
> my name is Paul Seibert, I want to use PETSC for developing new CFD
> methods at the Technical University of Dresden (Germany). I would like to
> thank Barry for the quick help regarding the configuration. Now I have a
> problem getting the support of a node in a DMPlex. I hope, this is the
> right address for this issue.
>
> My problem is as follows (please find the source code in the appendix):
>
>    - For the moment I just want to solve a poisson equation on a DMPlex
>    grid (which is regular though). I create a 10x10x10 finite volume mesh by
>    specifying the coordinates of all vertices and the cones of all cells and
>    calling DMPlexCreateFromDAG() and DMPlexInterpolate(). Then, I define a
>    scalar field in the cell centres.
>    - I set the adjacency useCone=True and useClosure=True. When I then
>    assemble a matrix and view it (using mpiexec -n 1 ex1f -mat_view draw
>    -draw_pause -1 > tempoutput.txt) I see the correct band-structure of the
>    matrix. So I think, the DAG in correct.
>    - (Not sure why I have to use the closure though. Also, I would prefer
>    to get only the "star" neighbors, not the "box" including diagonal
>    neighbors, but those are minor issues)
>
>
To get the start neighbors, its just useClosure=False

>
>    - Then, I want to set the values in the matrix. For this to work in
>    general, I want to go through the cells and set the matrix entry to each
>    neighbor, and I want to find the neighbor of a cell c by getting the
>    support of all elements in the cone of c. In the source code, I do this for
>    cell 133 (as an example), which is not at the border of the domain and has
>    the neighbors 132,134,123,143,33,233 and some more according to the matrix.
>    The cone size is correct (6), however, the support size doesn't seem to be
>    2 but 1 for all faces except the first two, the support of which is also
>    correct. All the other faces' supports only contain the cell c itself. Find
>    the data by searching the tempoutput.txt file for "cone size".
>
>  The assumption we have for parallelism is that if point c is present in
the PetscSF (meaning that it is shared with some other process)
then cone(c) will also be present. This is not true for support(c). One
could imagine a symmetric implementation with this assumption,
but we have not implemented that. Thus, in parallel, you will not see
neighboring cells owned by another process. Is this what is happening
in your case?

A possible remedy for this is to use overlap=1 when partitioning, and then
checking for ghost cells when assembling.

  Thanks,

     Matt

> My questions are as follows:
>
>    - Why don't I get the correct support?
>    - Is my way how this is supposed to be done or is there a more elegant
>    approach?
>
> Any help would be very appreciated.
>
> Best regards,
>
> Paul Seibert
>


-- 
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

https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20190629/6c2ae71f/attachment.html>


More information about the petsc-users mailing list