On Mon, 6 Oct 2008, Roy Stogner wrote:
> Looks like a bug of mine; I think when I coded it I must have assumed
> that we'd chosen our ordering to ensure that elem->node(n) was the
> same as elem->child(n)->node(n). Too bad we didn't; that one-liner
> return value is going to turn into something that takes a Karnaugh map
> to optimize.
I settled on this patch:
--- src/geom/face_quad.C (revision 3082)
+++ src/geom/face_quad.C (working copy)
@@ -122,7 +122,10 @@
libmesh_assert (c < this->n_children());
libmesh_assert (s < this->n_sides());
- return (c == s || c == (s+1)%4);
+ // A quad's children and nodes don't share the same ordering:
+ // child 2 and 3 are swapped;
+ unsigned int n = (c < 2) ? c : 5-c;
+ return (n == s || n == (s+1)%4);
}
Would you give it a look?
I recall catching myself making this same incorrect assumption
elsewhere in the past (in FEBase::coarsened_dof_values(), it looks
like), but I didn't realize I hadn't caught all of its effects.
Thanks again for the help,
---
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
