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
