On Tue, 20 Oct 2009, Tim Kroeger wrote: > Well, actually I don't know what Clough-Tocher elements are, hence it is > possible that they are exactly what I am meaning, although I don't think so.
No; they're still technically composite elements since they involve a subelement partitioning, but with the CLOUGH elements it's just a fixed partitioning to enable smoother shape functions with lower degree polynomials. > Let me explain in my own words what I mean: If a complicated geometry is > involved in a problem (which can either mean that the computational domain > has a complicated geometry or the boundary between subdomains has a > complicated shape -- or both), an alternative to the usage of a grid that > resolves these shapes sufficiently well is to use just a grid of uniform > squares/cubes (on a larger domain, if necessary) and to modify the shape > functions on those squares/cubes that intersect with the complicated > boundary. That is, if there are eg. subdomains with different diffusion > coefficients, the shape functions on squares/cubes that intersect with the > boundary will include the required gradient jump conditions. Got it. Yes, this is the second type of "composite element" I was referring to, and there's currently no support for it in libMesh. >> CFEs would definitely be welcome, since they ought to be able to fit >> onto the FEBase API without changing the latter too much. The >> tricky question is "how do you automatically solve the subproblem" >> with them... You'd basically have to hot swap an entire new Mesh (and >> corresponding DoF numbering and algebraic discretizations) in and out >> from underneath the EquationSystems. Or you'd have to require the >> user to have an FEMSystem or some other API that provides physics at a >> non-global level. > > If I understand you correctly and if were're talking about the same thing, > you are refering to the question how the library should know (and store) > which cells would have to use modified shape functions and in which way they > are modified. I currently don't know how other FEM libraries manage this, > but I guess there is some solution. It's definitely possible; I'm just not sure how easily we could make it automatic and transparent to the user. It would definitely be less modularized than most of our current code. Right now our FE objects know nothing about the user's physics; a composite subclass would have to be an exception if we wanted to build proper internal jump conditions automatically. --- Roy ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
