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

Tue Jul 1 21:08:37 CEST 2014

Wow, a lot time has gone by without further action. It seems like many
of the interested people will be at PDESoft in Heidelberg this month.

Maybe we can seize the opportunity to hold a public informal meeting
there around this theme. Maybe on the so-called coding days?

Currently, it seems like there are even more issues coming up (at
least judging from the list).

Markus

On Thu, Nov 07, 2013 at 08:55:06PM +0100, Martin Nolte wrote:
> to be honest, I am not sure how much can be achieved with a single meeting.
> 
> The idea originated from the observation that the topic
> "parallelism" was carefully avoided on the last "big" developer
> meetings. It was my impression that on the one hand "only" around
> 50% of the core developers are interested in this feature, while on
> the other hand there are some extremely interested users (e.g.,
> Bernd who has provided substantial contributions to parallel UG).
> 
> I think such a smaller group focussing entirely on this topic might
> achieve more progress. It goes without saying that the "real
> decisions" must be made by a formal vote of all core developers.
> 
> If there is enough interest in such a meeting, I suggest to set up a
> page on the user wiki, so that we can collect the topics we're
> interested in. We then might be able to judge the size of this
> thing. We can always shorten the list, if it becomes too large.
> Given interest, I would be prepared to organize such a meeting in
> (or near) Freiburg.
> 
> Best,
> 
> Martin
> 
> 
> 
> On 11/07/2013 08:22 PM, Peter Bastian wrote:
> >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
> >>
> 

-- 
Do you need more support with DUNE or HPC in general? 

Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Hans-Bunte-Str. 8-10, 69123 Heidelberg, Germany
Tel.: +49 (0) 160 97590858
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20140701/bc9f0d3f/attachment.sig>