On Tue, 11 Nov 2008, Norbert Stoop wrote: > Recently, subdivision surfaces were suggested as an alternative way to > construct C1 (and higher) conforming surface meshes for finite element > simulations.
Interesting. I've heard of subdivision elements being used for surface mesh refinement, but in a context where the subdivision surface was only C1 in the limiting sense; each discrete mesh was still faceted. We could do something like that relatively easily, but of course it wouldn't be as accurate unless your formulation is insensitive to domain boundary discontinuities. > Assuming triangular elements, the subdivision surface approach results > in 12 b-spline shape functions per element. The isoparametric map to > real space is a combination of them multiplied with the real space > position of the triangle's nodes *and* its next neighbor nodes (the > 1-ring of triangles around the element). This is a problem, but a minor one - the nodal neighbor elements always exist as at least ghost elements on even a distributed mesh, and I think we've already got some nice Patch API for accessing them; it probably wouldn't be hard to write something similar for collecting the set of only all nodal neighbors on a surface. > Looking at existing libmesh elements (lagrange, clough), I see that only > the ::shape, ::shape_deriv and ::shape_second_deriv are typically > overwritten, and the mapping to real space is done by libmesh > (fe_base.C, I think). This would be much harder, because to do the mapping right would require a major code refactoring. Right now, we combine a geometric element Elem and a finite element space FE to produce results, and it's understood that the mapping is always done by a Lagrange FE. We'd probably want to add a mapping element (returned from a factory method in Mesh?) to that combination, and I suspect that because of the way they calculate shape functions, most of our FE objects would not be immediately suitable as mapping objects. > As pointed out above, the subdivision elements have a special mapping to > real space, which needs to take the neighboring nodes' position into > account. Is there a way to accomplish this in the current code No. > or would it be possible to extend it in that way? Yes, but not easily. --- Roy ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
