From: Xi Y. <hil...@ho...> - 2007-03-06 05:21:17
|
I am considering add shell elements to libmesh but not quite sure how to do it. The first probelm I encounter is how to build the shape function of such kind of elements. For shell elements, we need know the thickness and fiber vector of all FE nodes. But in libmesh, no such informations. I am considering add those variables into mesh_data and rewrite the function of shape function calculation like Real FE<2,LAGRANGE>::shape(const ElemType type, const Order order, const unsigned int i, const Point& p, const real thickness, real* fibervector) But it looks a little awkward because it changes the basic structure of this soft. Is there any suggestion about it? _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/ |
From: Roy S. <roy...@ic...> - 2007-03-06 12:42:24
|
On Tue, 6 Mar 2007, Xi YUAN wrote: > I am considering add shell elements to libmesh but not quite sure how to do > it. Could you post a few references for the element type you'd like to add? > The first probelm I encounter is how to build the shape function of such > kind of elements. For shell elements, we need know the thickness and fiber > vector of all FE nodes. But in libmesh, no such informations. I am > considering add those variables into mesh_data and rewrite the function of > shape function calculation like > > Real FE<2,LAGRANGE>::shape(const ElemType type, const Order order, const > unsigned int i, > const Point& p, const real thickness, real* fibervector) > > But it looks a little awkward because it changes the basic structure of this > soft. Is there any suggestion about it? Well, we definitely don't want a new shape method signature. The thing to do will be to use the other shape function signature (which, except for Lagrange mapping functions, is the one that gets called anyway): Real FE::shape(const Elem* elem, const Order o, const unsigned int i, const Point& p) But then the question becomes "how do we get that extra data from an Elem *". The closest analogous case we've got is the infinite element support, but I'm not sure you'd like to add a new geometric Elem subclass for every plate type you want. --- Roy |