<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi.<br>
<br>
To make one thing clear from the start, I think this is a great
project and very useful for dune.<br>
That was for me always clear. But what I was missing was a clear
idea what the plan was, i.e.,<br>
a list like the one you just wrote. Of course there are many dune
projects going on where I have at<br>
best an idea of what the aim is and no more - and that is fine.
But to provide any useful input, <br>
a clearer idea helps and just discussing it with Peter does not
provide me or others with a clear picture.<br>
<br>
Even after reading your description of the project I am still a
bit unsure about the partitioning.<br>
To summarize my understanding:<br>
In one case, one has a partitioned gmsh file. Then repartitioning
is probably not required?<br>
In the other case, the gmsh file is on one process only and the
gmsh reader adds everything into<br>
the (meta)gridfactory. Is now the idea that the gridfactory first
stores the inserted element/vertices<br>
itself (so does not call the insert methods on the hostgrid). Then
in the createGrid method<br>
the inserted elements are partitioned and then each element calls
the insert method on the host<br>
gridfactory for its own elements? That sounds like a very useful
"MetaGridFactory" in its own right, i.e.,<br>
independent of a CurvilinearGeometryGrid. But perhaps<i> I
misunderstood the idea. </i><br>
If that is the idea, I would suggest to consider a callback
approach similar to the one we are using <br>
for the repartitioning in ALUGrid. So the method createGrid gets a
callback object which it can ask<br>
for a partition number to which to send the process. That would
mean that the code would not be<br>
restricted to ParMetis.<br>
<br>
Best<br>
Andreas<br>
<br>
On 16/10/14 08:47, Benedikt Oswald wrote:<br>
</div>
<blockquote cite="mid:21530D1C-1075-4491-8E4C-19A9E3085D00@lspr.ch"
type="cite">
<pre wrap="">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, <a class="moz-txt-link-abbreviated" href="mailto:benedikt.oswald@lspr.ch">benedikt.oswald@lspr.ch</a> - labor vincit omnia improbus
--------------------------------------------------------------------------------------------------------------------------------------------------------------
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Dune mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dune@dune-project.org">Dune@dune-project.org</a>
<a class="moz-txt-link-freetext" href="http://lists.dune-project.org/mailman/listinfo/dune">http://lists.dune-project.org/mailman/listinfo/dune</a>
</pre>
</blockquote>
<br>
</body>
</html>