On Mon, 25 Aug 2008, Jed Brown wrote: > For what it's worth, mesh formats like exodusII and VTK accept quadratic > elements. They view a quadratic element as a different topology, for > instance there is VTK_HEXAHEDRON=12 and VTK_QUADRATIC_HEXAHEDRON=25. Of > course each of these has a canonical numbering for the nodes. All > vertices are kept in one array, then connectivity for each topology > (either a separate array for each topology or interlaced with a topology > ID for every element).
Yeah, the quadratic mesh is stored in the standard P2 format, i.e. each triangle has 6 nodes associated with it, and they are ordered (locally) in the `standard' way. > I'm not aware of any standard for cubic and higher order meshes (or any > visualization software that could use it). In that case, I think the > most reasonable thing is to store full element connectivity without > reference to vertices, that is (Region->Face), (Face->Edge), > (Edge->Vertex) and then store coordinates as a function over this space > (however you store such things, such as by indexing interior degrees of > freedom for every element/facet). Note that there are many more > coordinates than vertices. I agree that for visualization, you probably don't need 3rd order or higher. But I can definitely envision PDE problems (discretized) that may require it for other reasons. I am a little confused by what you said for storing the coordinates. So the full element connectivity would still require changing MeshTopology? > Providing a canonical numbering for nodes on say, a cubic hex, requires > 98 vertices. Also, the mesh function approach plays nicely with mixed > order discretization, modal bases, and nonconforming meshes. how exactly would the mesh function approach work? Do you mean use MeshFunction? > So it might be reasonable to just implement the quadratic topologies now > and wait for cubic and higher order since it is a major undertaking to > do in a flexible manner. I agree that this should all be tested with quadratic elements first. - Shawn _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
