← Back to team overview

dolfin team mailing list archive

Re: XML format for Higher Order meshes

 

On to., 2008-08-21 at 22:51 -0400, Shawn Walker wrote:
> Hello, all.  I've been thinking about this higher order mesh stuff, and I 
> need to be more clear about what I want to do.   I'm not sure it would be 
> good to make an ultra-general higher order mesh format.  It seems to be 
> more trouble than it is worth (right now).
> 
> What I would like to have is a format for higher order meshes based on 
> polynomial mappings (ONLY!).  Currently, everything in FENICS assumes that 
> a P1 map is used for each element in the mesh.  Of course, this only 
> requires knowledge of the vertex coordinates of the element.  If a higher 
> order polynomial map is used, all you need are the positions of the extra 
> control points.  And this would extend the P1 map quite naturally.  For 
> the .xml format, I think the data for the control points should contain 
> the usual vertex coordinates also (not just the extra control points). 
> This would be redundant, but a little simpler to read in from the XML 
> file.  Note that storing the coordinates for each element separately would 
> not be good, because even the edge mid-point positions would be used by 2 
> (or more) elements, so you need to keep this connectivity information.
> 
> One advantage of using a polynomial map (besides for free boundary 
> problems) is that the element tensor can be computed exactly in some cases 
> (but not for a stiffness matrix).  This isn't bad.
> 
> Anyway, I know this is probably boring some of you.  And I know this is 
> not a high priority, but I am willing to put in time implementing this 
> (mostly because it would be useful to me).  I will repost another format 
> for the mesh.xml file and see what people think.

This is definitly not boring to me, I would very much like a
higher-order mesh in Dolfin! And I would consider it a great improvement
of Dolfin. 

But as you have noticed there are some nice features concerning eg. the 
topology that probably should not be messed with. It might even be that
the mesh should be left alone and that an additional structure can 
store the extra coordinates and their relation to mesh in therms of
facets etc. 

Anyway, it seems that every concern is getting on the table and that it 
is a matter of sorting it out before implementing, hopefully. 

Finally, there is another option as well. You may write your own
assembly routine that employs another mesh than the Dolfin mesh. UFC was
originally designed such that it should be "easy" to use another mesh. 
But we have not really tested it. 

Kent 





Follow ups

References