On Sun, 24 Aug 2008, Anders Logg wrote: > On Sun, Aug 24, 2008 at 03:55:49PM -0400, Shawn Walker wrote: >> >> On Sun, 24 Aug 2008, Anders Logg wrote: >> >>> The main problem here seems to be how to even represent a higher-order >>> mesh. Are there any existing conventions for this? >> >> Not that I know of, other than the 'obvious' way. >> >>> Doing it locally is fine. For each cell, we have a convention for how >>> we number vertices, edges and faces (it's in the UFC manual) but we >>> don't have a convention for how to number mesh entities globally. >>> >>> We could use the dof map (for Lagrange elements) that FFC computes >>> based on the numbering of mesh entities, but that computation is based >>> on a global numbering of edges and faces, and that numbering depends >>> on the algorithm for computing these entities (in TopologyComputation). >>> >>> So, the only solution I see is to store the coordinates cell-wise, >>> which would mean duplicating the data, both in the XML file and for >>> storing the coordinates in MeshGeometry. >> >> I think this would be ok. But it must still be possible to update the >> mesh geometry (i.e. update the coordinates of all the control points for >> the curved triangle geometries) in, say, a time-stepping loop. For >> example, you would need this for ALE moving mesh applications. This >> means you must update the individual cell geometries in a 'compatible' >> way. I haven't actually thought about this. Would this be do-able? If >> so, I have no problem with keeping the higher order mesh geometry >> completely local. So the question is: "Is it possible to access and >> change the local higher order mesh geometry such that the higher order >> mesh coordinates stay consistent?" >> >> - Shawn > > Yes, we just need to have a global list of coordinates, and then > mappings from all cells to the coordinate indices of those cells. > > Then one can move a coordinate once and it will affect all cells > sharing that coordinate. > > My suggestion would be to have one single list of coordinates like we > do now in MeshGeometry. The first N coordinates would be the vertex > coordinates (like now) and then the remaining coordinates (if any) > would be stored per cell, so that coordinate N is the coordinate for > the first edge midpoint of the first cell, coordinate N + 1 is the > coordinate for the second edge midpoint of the first cell etc.
ok, just to be clear, you mean: Have a list of coordinates of length N+Q, where 0 through N-1 is for the coordinates used now, and the remaining N to N+Q-1 coordinates contains coords that lie on the faces/edges of the mesh. And N through N+Q-1 is ordered by cell index grouping. That seems fine. How would the .xml file look? Perhaps this: <?xml version="1.0" encoding="UTF-8"?> <dolfin xmlns:dolfin="http://www.fenics.org/dolfin/";> <mesh celltype="triangle" dim="2" map_type="P2"> <vertices size="4"> <vertex index="0" x="0.0" y="0.0"/> <vertex index="1" x="1.0" y="0.0"/> <vertex index="2" x="0.0" y="1.0"/> <vertex index="3" x="-1.0" y="0.0"/> </vertices> <cells size="2"> <triangle index="0" v0="0" v1="1" v2="2"/> <triangle index="1" v0="3" v1="0" v2="2"/> </cells> <higher_order_vertices size="5"> <vertex index="4" x="0.5" y="0.05"/> <vertex index="5" x="0.6" y="0.6"/> <vertex index="6" x="0.0" y="0.5"/> <vertex index="7" x="-0.5" y="0.5"/> <vertex index="8" x="-0.5" y="0.0"/> </higher_order_vertices> <higher_order_cells size="2"> <triangle index="0" affine="false" v0="4" v1="5" v2="6"/> <triangle index="1" affine="true" v0="8" v1="6" v2="7"/> </higher_order_cells> </mesh> </dolfin> Or should it be grouped by triangle face? This also should be extensible to say cubic edges, or even higher. > The other option would be to store all coordinates for the first cell, > then the second etc, but I think it's advantageous to store all vertex > coordinates first since that is what we mostly use. That's fine. - Shawn _______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@fenics.org http://www.fenics.org/mailman/listinfo/dolfin-dev
