I see that you want to keep the mesh topology separated from the geometry, right? But, even now, this is slightly violated in the current .xml format, because with each vertex index, you give the coordinates. If all you wanted was the topology, then the coordinates would not be necessary. The coordinates are only need to make sense of the geometry of the mesh (i.e. whether there is overlap of triangles or inverted triangles, etc). So, technically, there should be a list of topological vertices and a separate list of geometric vertices.
Is this what you mean? - Shawn On Wed, 20 Aug 2008, Garth N. Wells wrote: > > > Shawn Walker wrote: >> I understand what you are saying, but the ordering of the vertices is such >> that the first three vertices (0,1,2) are exactly the same as they were >> before. This would be done no matter what order polynomial map you used. >> So, it seems to me it should be fine. >> > > This is the usual FEM approach, but the point as I see it is that a vertex > should really be a vertex. If it's not, it becomes a slippery slope with > ad-hoc extensions. It would be nice to come up with a solution which is more > elegant and extensible than the usual approach. > > Garth > >> However, to be sure, I can modify the ufc stuff such that the coordinates >> variable only reads in the first three vertices. So this would be EXACTLY >> as it was before. I would then create a new ufc::cell variable called >> `map_coordinates' (if you have a better name, please suggest) and this >> would read in the 6 vertices. And in Tabulate_Tensor, if higher order is >> desired, then the `map_coordinates' will be used to compute the FEM >> matrix. >> >> This seems safe, though a little redundant. Of course, one must be >> careful when creating the higher order mesh .xml file and ensure that the >> first three vertices correspond to the usual triangle vertices. >> >> I also want to make sure that the extra `map_coordinates' is available to >> be modified with a loop in dolfin. This would be necessary for an ALE >> method when the mesh is deforming. >> >> - Shawn >> >> On Wed, 20 Aug 2008, Anders Logg wrote: >> >> > On Wed, Aug 20, 2008 at 07:15:06PM +0100, Garth N. Wells wrote: >> > > >> > > Anders Logg wrote: >> > > > I'm not sure this will work. If you attach 6 vertices to a triangle >> > > > by >> > > > >> > > > <triangle index="0" affine="false" v0="0" v1="1" v2="2" v3="4" >> > > > v4="5" v5="6"/> >> > > > >> > > > then all sorts of things will break (I imagine). A triangle always >> > > > has >> > > > three vertices. >> > > > >> > > I noticed this too. It would make some things troublesome. >> > > >> > > > The geometry of the triangles is separate. >> > > > >> > > > Maybe we could just add extra data which could be "control points" >> > > > for >> > > > the cell facets? For P2 it would be the edge/face midpoints. >> > > > >> > > I like the idea of defining facet data which would contain the >> > > necessary >> > > info. >> > A problem with defining facet data is that the facet numbering is not >> > known a priori. It depends on the algorithm used by DOLFIN to compute >> > the facets from the cells. So we can't store for example a mesh >> > function over the facets since the facet numbering may change. >> > >> > When we read input from VMTK, we need to read facet data (boundary >> > markers) and these are stored relative to the cell to which the facet >> > belongs and the local number of the facet relative to the cell (which >> > is unique). >> > >> > There is an example in data/meshes/aneurysm.xml.gz. >> > >> > -- >> > Anders >> > >> _______________________________________________ >> DOLFIN-dev mailing list >> [email protected] >> http://www.fenics.org/mailman/listinfo/dolfin-dev > > _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
