Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

## libmesh-users

 Re: [Libmesh-users] Question about integration on sides From: Kirk, Benjamin (JSC-EG) - 2008-10-29 13:54:27 ```You might also consider FEXYZ. I put this together for finite-volume type computations, but works for dg too. The idea is that the degrees of freedom are coefficients which scale physical coordinates, not reference ones... That is 1 (x-xc) (y-yc) .... Where (xc,yc) are element centroid locations. Since you do not need reference element coordinates with this approach there is no need for an inverse map. The physical face quadrature points as defined by the rhs element can be transformed algebraically to the basis function values for both the lhs and rhs elements. -Ben ----- Original Message ----- From: Adam Arbree To: Roy Stogner Cc: libmesh-users@... Sent: Wed Oct 29 08:45:31 2008 Subject: Re: [Libmesh-users] Question about integration on sides Thanks again. I will go with the inverse transformation. Adam ________________________________ From: Roy Stogner [mailto:roystgnr@...] Sent: Tue 10/28/2008 10:53 PM To: Adam Arbree Cc: libmesh-users@... Subject: Re: [Libmesh-users] Question about integration on sides On Tue, 28 Oct 2008, Adam Arbree wrote: > I am trying to integrate a jump term over the interior boundary between two > 3D elements. To do a sanity check on my code, I run the code snippet at the > end of this mail. It fails at the last assertion and I cannot figure out > why. Just because the two neighboring elements are using an identical quadrature rule doesn't mean they're going to get matching points. For a simple example: Imagine two cubes touching each other. Now, rotate one of them 90 degrees around their common axis. The side quadrature points rotate with it, so even if they matched the other cube's quadrature points before, they won't after. And yet both meshes are perfectly valid. > I am sorry if I am missing something simple. Simple but disappointing: we can make no guarantees, even on conforming meshes, that quadrature points will match the way you want them to. The robust thing to do is the inverse maps that I suggested in a recent mailing list entry. Do it the way JumpErrorEstimator does it and your code will work even for non-conforming interfaces. If you're determined to avoid the inverse maps you could try to get the quadrature points on one element in terms of face xi-eta coordinates, figure out which coordinate (xi, eta, 1-xi, whatever) each of those corresponds to on the face of the adjoining element, and then use the result as a face quadrature rule there. But I wouldn't recommend it; the code I'm imagining wouldn't have to do any Newton solves but it would be a huge morass of switch statements and linear transformations. --- Roy ------------------------------------------------------------------------- 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 Libmesh-users@... https://lists.sourceforge.net/lists/listinfo/libmesh-users ```