From: Norbert Stoop <norbert@st...>  20081111 15:05:05

Kirk, Benjamin (JSCEG) wrote: > Phi_ etc... Are the basis functions of the fe discretication, psi are the mapping functions. > > Btw, you are using shells and only solving on the manifold(?), or is there an interior volume problem too? No, it's only solved on the manifold. You would suggest using CloughTocher elements instead? 
From: Norbert Stoop <norbert@st...>  20081111 15:05:05

Kirk, Benjamin (JSCEG) wrote: > Phi_ etc... Are the basis functions of the fe discretication, psi are the mapping functions. > > Btw, you are using shells and only solving on the manifold(?), or is there an interior volume problem too? No, it's only solved on the manifold. You would suggest using CloughTocher elements instead? 
From: Norbert Stoop <norbert@st...>  20081111 15:14:25

Kirk, Benjamin (JSCEG) wrote: > No, I'm not suggesting anything I'm particular, I was just speculating about how we wound define a C1 surface... > > If anyone is interested I think I have some subdivision surface code I got from Bob Haimes at MIT. I'll see if I can dig it up... Yes, I am, definitely... ;)  Norbert 
From: Kirk, Benjamin (JSCEG) <Benjamin.K<irk1@na...>  20081111 15:16:46

Well, I was just thinking about the various places we use the inverse map... If they are affine the newton iteration would be fast, but setting up the map would be be (some unquantified amount) more expensive than in the lagrange case. Not to mention how much memory we'd be wasting to hold the higherorder (0 valued) coefficients for the affine elements in the volume. Ben  Original Message  From: Roy Stogner <roystgnr@...> To: Kirk, Benjamin (JSCEG) Cc: Libmeshusers@... <Libmeshusers@...> Sent: Tue Nov 11 09:09:05 2008 Subject: Re: [Libmeshusers] Subdivision surface based FEM On Tue, 11 Nov 2008, Benjamin Kirk wrote: > To keep the code anything resembling efficient, we'd need to make sure > multiple mapping types are supported at the same time... I'd think we want > to use the C1 map *only* on elements with a face or edge trace on the > boundary of interest. Are the Lagrange bases so much more efficient that that would be worthwhile? I think as long as the majority of our elements are interior with affine maps we're fine.  Roy 
From: Roy Stogner <roystgnr@ic...>  20081111 15:22:12

On Tue, 11 Nov 2008, Kirk, Benjamin (JSCEG) wrote: > Well, I was just thinking about the various places we use the inverse > map... If they are affine the newton iteration would be fast, but setting > up the map would be be (some unquantified amount) more expensive than in > the lagrange case. That's a good point. > Not to mention how much memory we'd be wasting to hold the higherorder > (0 valued) coefficients for the affine elements in the volume. Also true.  Roy 
From: Kirk, Benjamin (JSCEG) <Benjamin.K<irk1@na...>  20081111 15:43:57

(Roy, obviously we were *both* thinking of the 3D volume case...) So we should be able to proceed with element refinement as usual, but then afterward process all the boundary faces with a defined geometry and snap points to it... The final step then would need to do something like 'enforce_constraints_exactly' on the hanging edges so as not to introduce topological 'tears'... Ben 
From: Kirk, Benjamin (JSCEG) <Benjamin.K<irk1@na...>  20081111 17:40:45

Tell me if this bizarre suggestion has merit... Pass in a standard 6noded quadratic triangulation which discretuzes the manifold. Declare a 'geometry system' which uses some C1 fe basis (cloughtocher does come to mind...). The unknowns in the system would be (xC1,yC1,zC1)  the weights for the C1 surface representation. Project your geometry to this system. Implement another fe.reinit() flavor which takes userspecified mapping values. In this case, the maps are precomputed for the current element from the 'geometry system.' Since he is solving on a manifold, the memory used is probably acceptable... Is there a showstopper I am overlooking? Ben  Original Message  From: Derek Gaston <friedmud@...> To: Roy Stogner <roy@...> Cc: Libmeshusers@... <Libmeshusers@...> Sent: Tue Nov 11 11:25:22 2008 Subject: Re: [Libmeshusers] Subdivision surface based FEM On Nov 11, 2008, at 10:02 AM, Roy Stogner wrote: > On Tue, 11 Nov 2008, Norbert Stoop wrote: > >> To summarize, we abuse the traditional mesh as a control mesh. We >> define >> a parametrization of the limit surface which naturally gives us the >> needed mathematical objects such as derivatives, surface patches etc. >> Since we *know* where each control point converges to in the limit, >> we >> can assign back calculated nodal values to the control points and >> assemble the system as usual. >> >> Hope this helps to clarify... It seems like if you could use Clough Touchers (or hermites) as the map then that would solve this problem... but as you mentioned earlier that's probably not doable with our current architecture. Derek  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://moblincontest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmeshusers mailing list Libmeshusers@... https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: Roy Stogner <roystgnr@ic...>  20081111 17:56:59

On Tue, 11 Nov 2008, Kirk, Benjamin (JSCEG) wrote: > Pass in a standard 6noded quadratic triangulation which discretuzes the > manifold. > > Declare a 'geometry system' which uses some C1 fe basis (cloughtocher > does come to mind...). CloughTocher may not be ideal. Since they're not hhierarchic, you can't refine without (very slightly) changing the result. That's not a problem for my applications but it may be for this one. I'd suggest implementing Argyris or PowellSabinHeindl elements instead. But (and this is embarrassing, since I know some of these elements started out precisely for use in geometric approximation) I'm not certain what your global degrees of freedom would look like this way. Right now we assume that "x" and "y" are well defined globally by the Lagrange mapping, and we have C1 global dofs that are gradients or fluxes in xy space. How does that work if "x" and "y" are only defined by the C1 mapping? xi and eta aren't well defined globally, and I don't see how to define something similar without making limiting assumptions that wouldn't handle arbitrary manifold topologies. > Since he is solving on a manifold, the memory used is probably > acceptable... Certainly.  Roy 
From: Benjamin Kirk <benjamin.kirk@na...>  20081111 19:19:48

>> Declare a 'geometry system' which uses some C1 fe basis (cloughtocher >> does come to mind...). > > CloughTocher may not be ideal. Since they're not hhierarchic, you > can't refine without (very slightly) changing the result. That's not > a problem for my applications but it may be for this one. > > I'd suggest implementing Argyris or PowellSabinHeindl elements > instead. > > But (and this is embarrassing, since I know some of these elements > started out precisely for use in geometric approximation) I'm not > certain what your global degrees of freedom would look like this way. > Right now we assume that "x" and "y" are well defined globally by the > Lagrange mapping, and we have C1 global dofs that are gradients or > fluxes in xy space. How does that work if "x" and "y" are only > defined by the C1 mapping? xi and eta aren't well defined globally, > and I don't see how to define something similar without making > limiting assumptions that wouldn't handle arbitrary manifold > topologies. Well, what we can provide now is phi(X) = phi(X(xi)) and (dphi/dX)(X) = [(dphi/dxi)(dxi/dX)](X(xi)) Where phi is whatever your finite element says it is and X(xi) is the C0 map provided by the Lagrange basis. (dxi/dX) is obtained directly by inverting the (dX/dxi) transformation map. My understanding of the issue is that this is no good because X(xi) needs to be C1 so that the curvature is square integrable... So why not compute instead phi(Xc) = phi(Xc(X)) = phi(Xc(X(xi))) and (dphi/dXc)(Xc) = [(dphi/dxi)(dxi/dX)(dX/dXc)](Xc(X(xi))) Where Xc(X) is the C1 geometry representation provided by the "geometry system" described previously. The additional terms needed to compute (what I think is) the right map are (dX/dXc) at the quadrature points, which can be constructed analytically from (dXc/dX), which the user computes from the "geometry system." So in some sense there ate two jacobian transformations which are required... Since Roy's worked with a lot more C1 systems than me (read: 0), I ultimately defer to him as to whether this is possible or just a bunch of nonsense... Ben 
From: Roy Stogner <roystgnr@ic...>  20081111 21:26:47

On Tue, 11 Nov 2008, Benjamin Kirk wrote: > So why not compute instead > > phi(Xc) = phi(Xc(X)) = phi(Xc(X(xi))) and > (dphi/dXc)(Xc) = [(dphi/dxi)(dxi/dX)(dX/dXc)](Xc(X(xi))) > > Where Xc(X) is the C1 geometry representation provided by the "geometry > system" described previously. This is what I was thinking of when I said that arbitrary topologies would be the tricky part. X needs to be in the 2D plane for Xc(X) to make sense with our current setup. That's not even possible if your desired manifold Xc is closed and unbounded, which I'm guessing would be a pretty common case. My best idea right now is: let X be the "faceted" C0 representation of the manifold (which on any C1 element is already implicit as the first order Lagrange interpretation of the vertex dofs), and at every node or edge take some "average" of the surrounding elements to get a local coordinate system on which you can take welldefined derivatives. Easy to state, not quite as easy to picture, probably not easy at all to code. My second best idea: actually go back to the geometry literature and find out how this has been done in the past. I'd have done so already, but the only useful articles I can recall off the top of my head aren't online.  Roy 