[Dune] how to integrate curvilinear tetrahedral elements into DUNE/Alugrid ?

Thu Jan 23 15:48:01 CET 2014

On Thu, Jan 23, 2014 at 01:40:49PM +0000, Andreas Dedner wrote:
> A final suggestion I could make:
> start a new project on the dune user wiki.
> Move the geometrygrid files from dune-grid/dune/grid/geometrygrid
> to newproject/dune/grid/geometrygrid
> Now you should be able to test everything including dune-geometrygrid as
> before and everything can be easily copied back to dune-grid when completed.

Sounds good

Christian

> Andreas
> 
> On 23.01.2014 14:04, Benedikt Oswald wrote:
> > hello DUNE
> >
> > so, reflecting the comments the approach to get curvilinear meshes
> > should be along those lines:
> >
> > 1) extend the gush reader to read tetrahedral grids up to 3rd order
> >     gmsh at present works up to 3rd order, higher order mesh generation
> >     crashes
> >
> > 2) use the grid factory facility to create the grid in dune
> >
> > 3) implement the curvilinear geometry grid in
> >
> > 	a) multilineargeometry.hh
> > 	b) geometry-grid
> >
> >
> > 4) since we would like to integrate this into Dune as soon as it is mature,
> >     hearing all the suggestions, where should we put the work ?
> >
> >     keep it on our machines ? keep it in a project on the Dune user wiki ?
> >
> >  Greetings, Benedikt
> >
> >    
> >
> >
> >
> >
> >
> > On Jan 23, 2014, at 11:48 AM, Oliver Sander <sander at igpm.rwth-aachen.de> wrote:
> >
> >> Am 23.01.2014 10:25, schrieb Andreas Dedner:
> >>> What I would suggest would be to setup a project on the dune user wiki and
> >> A good idea, but while doing that I suggest to keep in mind that in the long
> >> run it may be preferable to merge your code into GeometryGrid proper.
> >> You are implementing a more general version of GeometryGrid; it is not obvious
> >> why it should be a completely separate implementation (except to get you started).
> >>
> >>> giving it public access - that hopefully will give you some help from the
> >>> experienced dune developers if you get stuck.
> >>> I'm terrible with naming so will not make a suggestion but
> >>> CurvilinearGeometryGrid and simply CurvilinearGrid comes to mind.
> >> -1, I think this is too unspecific.  If you intend to implement polynomial
> >> geometries how about PolynomialGrid?  Or QuadraticGrid or SecondOrderGrid
> >> if you only want to do quadratic geometries?
> >>
> >> Best,
> >> Oliver
> >>
> >>> Best
> >>> Andreas
> >>>
> >>> On 23.01.2014 10:13, Benedikt Oswald wrote:
> >>>> Hello Andreas, thanks.
> >>>>
> >>>> Then, I shall do so!
> >>>>
> >>>> However, not being an expert in Dune internals programming,
> >>>> where would I start ?
> >>>>
> >>>> would the extension of dune / grid / geometry grid / coordfunction be
> >>>> the right place ?
> >>>>
> >>>> And, more technically speaking, should copy the geometry grid
> >>>> directory into my
> >>>> own source tree, implement the things there and, once it works, submit
> >>>> back to Dune?
> >>>>
> >>>> What about naming the new implementation ?
> >>>>
> >>>> Greetings, 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
> >>>> <mailto:benedikt.oswald at lspr.ch>
> >>>> --------------------------------------------------------------------------------------------------------------------------------------------------------------
> >>>>
> >>>> On Jan 23, 2014, at 10:04 AM, Andreas Dedner <a.s.dedner at warwick.ac.uk
> >>>> <mailto:a.s.dedner at warwick.ac.uk>> wrote:
> >>>>
> >>>>> Hi Benedikt.
> >>>>> You would need to extend GeometryGrid (something many of us would
> >>>>> really appreciate). Basically GeometryGrid replaces the geometries of
> >>>>> the host grid
> >>>>> using the GenericGeometries which are only "linear". This part of
> >>>>> GeometryGrid
> >>>>> would need to be replaced with something higher order, e.g., some
> >>>>> curvilinear approximation.
> >>>>> Best
> >>>>> Andreas
> >>>>>
> >>>>> On 23.01.2014 08:32, Benedikt Oswald wrote:
> >>>>>> Dear Dune
> >>>>>>
> >>>>>> as it happens we are forced to consider drastic steps to increase
> >>>>>> the efficiency of our electromagnetic solvers,
> >>>>>> especially in the frequency domain.
> >>>>>>
> >>>>>> Recently, Peter Bastian suggested we use curvilinear elements in
> >>>>>> order to model our curved geometry and domain
> >>>>>> boundaries. In fact, we believe that this will help us enormously
> >>>>>> since the element count will be much reduced.
> >>>>>>
> >>>>>> Peter also suggested we use the geometry grid on top of ALUGrid in
> >>>>>> order to achieve this.
> >>>>>>
> >>>>>> Now, my concrete questions is: given an existing curvilinear mesh
> >>>>>> (e.g. from gush), how would we do this ?
> >>>>>>
> >>>>>> I read that geometry grid manages the vertices of the underlying
> >>>>>> grid, but, a curvilinear tetrahedral element has
> >>>>>> vertices not only in the corners but also on the edges, faces and
> >>>>>> inside the volume.
> >>>>>> Perhaps my question is trivial, nevertheless, I'd appreciate your
> >>>>>> suggestions.
> >>>>>>
> >>>>>> I should say that gmsh is capable of generating quite nice
> >>>>>> curvilinear tetrahedral meshes, at least up to 3rd order.
> >>>>>>
> >>>>>> Greetings and thanks in advance, 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
> >>>>>> <mailto:benedikt.oswald at lspr.ch>
> >>>>>> --------------------------------------------------------------------------------------------------------------------------------------------------------------
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Dune mailing list
> >>>>>> Dune at dune-project.org
> >>>>>> http://lists.dune-project.org/mailman/listinfo/dune
> >>>>> _______________________________________________
> >>>>> Dune mailing list
> >>>>> Dune at dune-project.org <mailto:Dune at dune-project.org>
> >>>>> http://lists.dune-project.org/mailman/listinfo/dune
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Dune mailing list
> >>> Dune at dune-project.org
> >>> http://lists.dune-project.org/mailman/listinfo/dune
> >>>
> >>
> >> _______________________________________________
> >> Dune mailing list
> >> Dune at dune-project.org
> >> http://lists.dune-project.org/mailman/listinfo/dune
> >
> >
> > _______________________________________________
> > Dune mailing list
> > Dune at dune-project.org
> > http://lists.dune-project.org/mailman/listinfo/dune
> 

> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune


-- 
Prof. Dr. Christian Engwer 
Institut für Numerische und Angewandte Mathematik
Fachbereich Mathematik und Informatik der Universität Münster
Einsteinstrasse 62
48149 Münster

E-Mail	christian.engwer at uni-muenster.de
Telefon	+49 251 83-35067
FAX		+49 251 83-32729