## Re: [Libmesh-users] Subdivision surface based FEM

 Re: [Libmesh-users] Subdivision surface based FEM From: Norbert Stoop - 2008-11-11 14:43:54 ```Roy Stogner wrote: > > 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. Hm, I'm not sure if I understand your last comment, but yes, the surface is C1 only in the limit case. Given an initial "control" mesh and knowing the subdivision scheme, one can find a local parametrization x(xi,eta) of the limit surface. This is given by a linear combination of the (limit surface) shape functions. Derivatives of this parametrization are continuous since they're formulated in the C1 limiting sense. If Loop's subdivision scheme is used, the shape functions are found to be quartic b-splines for the limit surface. My understanding is that the only inaccuracy is the quality of the initial control mesh, but this is not an issue in my case (simulation of spherical shells). A reference is this paper here: Subdivision surfaces: A new paradigm for thin-shell finite-element analysis, F. Cirak, M. Ortiz, P. Schröder (2000) The scheme was recently extended for adaptive refinement support. >> 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. Good. >> 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. I see. These mappings are expressed in the phi_map, dphidxi_map etc., right? So, as a dirty hack, *in principle* one could overwrite the FE::init_shape_functions and others to do the mapping right for this particular subdivision element. Is my understanding correct? Thanks in advance, Norbert ```