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