[Dune-devel] Semantics of {ghost,overlap}Size

Peter Bastian peter.bastian at iwr.uni-heidelberg.de
Thu Nov 7 20:22:14 CET 2013


Dear all,

clearly this has not been completely thought to the end once upon atime.

I see that you need a specification of overlap for codim 0 and codim dim.

Codim dim (vertices) is needed for standard overlapping DD methods.
I would define two vertices as connected if they are subentites of a common
codim 0 entity. With that Graph defined the distance ist clear.
Then of course the data decomposition is still with respect to codim 0
entites

likewise two codim 0 entites are connected if they share an intersection.

I am not sure whether the "overlap size" has any real application. In the numerical
methods it is usually not needed.

I am in favor of a meeting. Do you think about small cosmetic changes or something
bigger? If it is bigger then we should also consider extensions due to hybrid
parallelism, i.e. multithreading.


-- Peter

----------------------------------------
Peter Bastian,
IWR, Universität Heidelberg,
INF 368, D-69120 Heidelberg

> Am 07.11.2013 um 16:10 schrieb Martin Nolte <nolte at mathematik.uni-freiburg.de>:
> 
> Hi,
> 
> actually, I wonder whether anybody uses these methods at all (except for checking the return value for 0).
> 
> Otherwise, I totally agree with Markus that semantics of the methods are completely unclear:
> - They are not mentioned in the papers on dune-grid.
> - The documentation of the interface does not give a definition
>  (what is the size of a "region"? Why is this integral?).
> - The tests do not verify the result of these methods at all
>  (though it seems the information can be obtained by grid traversal).
> 
> A mere hint in the documentation of YaspGrid is absolutely insufficient.
> 
> Implementation node: SPGrid only implements these methods for codim 0, returning the number of elements in the corresponding partition. Up to now nobody complained about this.
> 
> Given the current status, we might just replace these methods by capabilities like hasGhosts or hasOverlap.
> 
> Anyway, in my opionion (as stated on the wish list for the developer meeting) the parallel part of the dune-grid interface should be revised in the near future. I think there are several points worth discussion. I was already thinking about a "small" meeting of those directly involved in the parallel interface (both on the user's and on the developer's side). What do the others feel?
> 
> Best,
> 
> Martin
> 
>> On 11/07/2013 11:39 AM, Andreas Dedner wrote:
>> Hi.
>> I've wondered about that as well and am thinking that the method really only
>> makes sense for codim 0 (where it the semantics seems clear enough).
>> 
>> In DUNE everything boils down to codim 0 anyway (i.e. what leaf entities
>> are for example). So if I have an overlap of 2 codim 0 entities then
>> I would expect that the corresponding entities of higher codimension are
>> there
>> as well....
>> 
>> Does anybody use that method for c>0?
>> 
>> Best
>> Andreas
>> 
>> PS: should these method be deprecated on the grid class?
>> 
>>> On 07/11/13 10:33, Markus Blatt wrote:
>>> Hi,
>>> 
>>> I recently looked at the documentation off these methodsbut this did
>>> not help me understand what they are doing. It reads "Return size of
>>> ghost region for a given codim on the leaf grid" but it is not clear
>>> to me what this size is.
>>> 
>>> In the documentation of yaspgrid it says that size is the distance in
>>> graph, which is not really clearer. I assume that means the smallest
>>> path between any two entities on different borders of that
>>> region. Which still leaves the question open what the graph
>>> of an enitity set of a given codim is. The vertices are of course the
>>> codim entities. Seems like the edges would be the codim 1 entities for
>>> elements and for all other entities with codim c the ones with codim c+1.
>>> 
>>> Is there a precise definition somewhere?
>>> 
>>> Markus
>> 
>> 
>> _______________________________________________
>> Dune-devel mailing list
>> Dune-devel at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune-devel
> 
> -- 
> Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>
> 
> Universität Freiburg                                   phone: +49-761-203-5630
> Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
> Hermann-Herder-Straße 10
> 79104 Freiburg, Germany
> 
> _______________________________________________
> Dune-devel mailing list
> Dune-devel at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-devel




More information about the Dune-devel mailing list