[Dune] How to implement point to point communication

[Andreas Dedner]

Hi.

To make one thing clear from the start, I think this is a great project 
and very useful for dune.
That was for me always clear. But what I was missing was a clear idea 
what the plan was, i.e.,
a list like the one you just wrote. Of course there are many dune 
projects going on where I have at
best an idea of what the aim is and no more - and that is fine. But to 
provide any useful input,
a clearer idea helps and just discussing it with Peter does not provide 
me or others with a clear picture.

Even after reading your description of the project I am still a bit 
unsure about the partitioning.
To summarize my understanding:
In one case, one has a partitioned gmsh file. Then repartitioning is 
probably not required?
In the other case, the gmsh file is on one process only and the gmsh 
reader adds everything into
the (meta)gridfactory. Is now the idea that the gridfactory first stores 
the inserted element/vertices
itself (so does not call the insert methods on the hostgrid). Then in 
the createGrid method
the inserted elements are partitioned and then each element calls the 
insert method on the host
gridfactory for its own elements? That sounds like a very useful 
"MetaGridFactory" in its own right, i.e.,
independent of a CurvilinearGeometryGrid. But perhaps/I misunderstood 
the idea. /
If that is the idea, I would suggest to consider a callback approach 
similar to the one we are using
for the repartitioning in ALUGrid. So the method createGrid gets a 
callback object which it can ask
for a partition number to which to send the process. That would mean 
that the code would not be
restricted to ParMetis.

Best
Andreas

On 16/10/14 08:47, Benedikt Oswald wrote:
> Dear Dune,
>
> for ca. 3 months now we have been working to implement a higher order curvilinear grid manager,
> using the concept of the metagrid on top of a host grid.
>
> In particular, Aleksejs Fomins is in charge of this project within LSPR AG.
>
> I should also mention that the sources of this project are publicly available on github
> (clone of dune-geometry, dune-curvilineargrid)
>
>
> The plan has been as follows:
> =======================
>
> 1) implement the curvilinear geometry in the class LagrangeGeometry which handles
>      the curvilinear, tetrahedral geometry using Lagrange polynomials
>
>      we comment that at present we implement up to order 5 but in principle
>      we can implement higher orders as well, if required.
>
>      status: implemented & tested
>
>
> 2) use the concept of the meta grid, embodied in the GeometryGrid
>
>
> 3) after discussions with Peter Bastian, we decided to create a new Dune module,
>      i.e.dune-curvilineargrid that uses sources from GeometryGrid which have been
>      renamed to reflect the new module name; in particular, GeometryGrid in its
>      present form simply does not do what is needed.
>
>      We have decided to use the new dune-alugrid module as the host grid and
>      we appreciate the ALUGrid effort very much.
>
>      status: in progress
>
>
> 4) we wish to avoid the bottleneck of reading the whole mesh on the master node only
>      and have therefore implement a parallel gmsh reader which reads the full curvilinear
>      gmsh .msh format, including tags and everything
>
>     status: operational
>
>
> 5) as a consequence, we need to repartition the mesh before we create the grid,both
>      that is the reason why Aleksejs asked for advice on how to communicate elements
>      between the MPI processes;  in fact, we have found a solution and use the well
>      known CLINK protocol
>
>
> 6) as a result, we estimate that we will have a first version of the parallel dune-curviineargrid
>      module operational in December;
>
>      the Dune community is very welcome to test it and comment on it.
>
>
> We really appreciate the support given to us from the Dune mailing list and we appreciate
> the Dune effort enormously. On the other hand, we openly admit that, sometimes in the past,
> we perceived certain comments as a tad 'grossfürstlich'.
>
>
> with the best of intentions and wishes for a wonderful day,
>
> Benedikt
>
>
>
>
>
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------
> Dr. sc. techn. Benedikt Oswald - first engineer - LSPR AG - phone - +41 43 366 90 74
> Technoparkstrasse 1, CH-8005 Zürich, benedikt.oswald at lspr.ch - labor vincit omnia improbus
> --------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>
>
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20141016/20517cb8/attachment.htm>