This is from my phone, sorry for any typos. -- Norbert Stoop http://tsonny.ch/
On 18.11.2008, at 19:06, Roy Stogner <[EMAIL PROTECTED]> wrote: > > > On Tue, 18 Nov 2008, Norbert Stoop wrote: > >> Roy Stogner wrote: >> >>> Does this have to be stored as a vector? Or stored at all? >>> Patch::add_point_neighbors() should do what you want on the fly. If >>> it's worthwhile a caching version of that could be created. >> >> Hm, the patch needs a special numbering scheme, which should look >> like this >> >> N+4 - N+1 - N+2 >> / \ / \ / \ >> / \ / \ / \ >> N+5 -- N --- 1 -- N+3 >> \ / \ e / \ / >> \ / \ / \ / >> N-1--- 0 --- 2 >> \ /|\ / >> \ / | \ / >> 5 -4- 3 >> >> where e is the element we consider and N is the valence of vertex 0 >> (which is irregular in this example). > > Ah - then I was completely misunderstanding what you had said before > about irregular vertices; I had hanging nodes in mind. > > What do you do about non-conforming adaptivity? You can probably > ignore more refined neighbors, but what about coarser neighbors? I recently found a Paper which deals with adaptive refinement. I can send you the ref when i'm back at my computer. Instead of the mesh the basis function space is somehow enlarged. They claim it is way easier than traditional amr.. In other words, i dont care about amr at the moment. > You couldn't get this scheme out of a Patch set very easily. But > because you've got more of a special case problem (all triangles at > the same level) you could get this kind of patch more efficiently: > find the neighbor at a side, find which side of his you are, decrement > modulo 3 to get the new side, and repeat until you get back to the > original element. Do that for all three original sides. Yep, thats what i do right now in reinit() >>> Could you describe this in more detail? Do you just need the FE >>> object to be able to fill in xyz/dxyz/d2xyz properly, or is it more >>> than that? >> >> What I need in particular, and probably all people solving stuff on a >> manifold, is the local surface metric at the quadrature points. >> To get this, one needs the C1 parametrization x(eta,xi). The >> derivatives >> wrt xi and eta give two tangents, from which the normal can be >> constructed. Together they basically define the metric. > > That sounds like what xyz and dxyz äre. Ah, lacking a proper browser i cannot find the precise Definition for xyz, but if it is meant as the map from xi,eta to xyz then this is definitely the right place to store it... >> The problem is, x(xi,eta) is given as a sum of >> phi(i)*nodal_xyz_position(i) where i goes over all vertices of the >> above >> patch. >> >> Now, either the finite element class exposes an interface to the >> parametrization x(xi,eta) (and its derivatives) > > Already done at the quadrature points. > >> and the metric, > > This we'd probably want the user code to calculate from dxyz. > >> or the node patch is exposed and the user constructs what actually >> is needed (since the phi's are already at hand). > > That may be what you fall back on, but if it could be put into the > library cleanly that would be nice. Provided i can put the metric into xyz, i could derive from fe<> and cache the current element patch, valences etc. in global scope like is done for the clough element coefficients. Is my understanding correct and would this be acceptable? Thanks for your help! -norbert ------------------------------------------------------------------------- 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
