dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Aug 22, 2008 at 10:18:11AM +0200, Kent-Andre Mardal wrote:
> 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 

As I mentioned before, what we need to do is to extend the
MeshGeometry class so that it can store additional geometry data.

A simple solution that would work for P2 mappings would be to just
store an extra list of coordinates for edge midpoints.

-- 
Anders

Attachment: signature.asc
Description: Digital signature