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
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
