On Sun, Aug 24, 2008 at 08:16:59PM -0400, Shawn Walker wrote: > > 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.
Yes, this looks good. But maybe the local indices for the higher-order cells should not start at zero: <higher_order_cells size="2"> <triangle index="0" affine="false" v3="4" v4="5" v5="6"/> <triangle index="1" affine="true" v3="8" v4="6" v5="7"/> </higher_order_cells> ? -- Anders >> 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
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@fenics.org http://www.fenics.org/mailman/listinfo/dolfin-dev