Hi Matt,
Are there any updates on this?
Thanks,
Michael
On 23/02/14 20:50, Matthew Knepley wrote:
On Fri, Feb 21, 2014 at 6:56 AM, Michael Lange
<[email protected] <mailto:[email protected]>>
wrote:
Hi Matt,
Have you had a chance to think about the cell overlap problem? I'm
proposing to make the center dimension a general Plex attribute
with the current behaviour as the default. We can then generate
the cell overlap in DMPlexDistribute according to the center
dimension using a utility function for point adjacency, something
like DMPlexGetAdjacentPoints(dm, p).
I'm happy to provide a pull request for this change, just tell me
if you agree with this approach or if you see any problems.
Yes, you are correct in this. We are having another discussion on
petsc-maint about the kinds of partitions that are
appropriate for different problems. I will try and get through this as
quickly as I can, and I will solicit your feedback
when I get the plan for implementation done.
Thanks,
Matt
Thanks and kind regards,
Michael
On 03/02/14 11:32, Michael Lange wrote:
Hi Matt,
On 31/01/14 05:11, Matthew Knepley wrote:
On Tue, Jan 28, 2014 at 8:57 AM, Michael Lange
<[email protected]
<mailto:[email protected]>> wrote:
Hi,
I noticed that the cell overlap created during
DMPlexDistribute does not include cells that only share a
vertex but no edge with an owned cell. This causes problems
when performing local assembly (MAT_IGNORE_OFF_PROC_ENTRIES)
based on information from the plex, because one contribution
to the shared vertex is missing.
As an example consider the 2x2 square with 8 cells
(attached). When partitioned across two ranks with overlap=1
each rank owns 4 cells and in the current version knows
about 2 halo cells, giving a total of 6 cells. The central
vertex, however, touches 3 owned and 3 non-owned cells, one
of which doesn't share an edge with any owned cells. So, in
order to correctly assemble the central vertex locally, the
rank owning it needs to know about 7 cells in total.
I have attached a patch that fixes this problem by going
over the inverse closure of all vertices associated with a
given cell instead of using the provided edge graph. Please
tell me what you think and whether there might be an easier
way to fix this.
This is true, but unfortunately not what everyone wants. FVM
people want just what is there now. This
same choice comes up in preallocation. There I have put in the
"center dimension" which says what
kind of point do you use for the center, vertex or face? I guess
we need that here as well.
Yes, I think the center dimension is exactly what we need here,
because my proposed fix is to switch from using star(cone(p)) to
star(closure(p)). So, do you want to make the center dimension a
general Plex attribute and move the Set/Get functions to plex.c?
If so, what would be the default? In that case a
DMPlexGetAdjacentPoints(dm, p) function might also be helpful if
this is used in several places? I'm happy to provide a pull
request, just tell me how you want this to be structured.
Thanks
Michael
--
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
