On Mon, 6 Oct 2008, Gong Ding wrote:
> A bug about _embedding_matrix of file face_quad4.C
>
> The matrix for child 2 and child 3 needs to be exchanged.
>
> Or the function
>
> bool Quad::is_child_on_side(const unsigned int c,
> const unsigned int s) const
> {
> assert (c < this->n_children());
> assert (s < this->n_sides());
>
> return (c == s || c == (s+1)%4);
> }
>
> Can not give correct answer
The embedding matrix is older than the is_child_on_side() API, and
changing the embedding matrix could cause problems with compatibility
with saved .xdr/a files that include refined meshes, so we should
change the Quad::is_child_on_side() implementation instead.
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.
Thanks very much for finding this! I hope it didn't trigger too nasty
a bug for you.
> BTW: I think replace family_tree_by_neighbor by family_tree_by_side is
> suitable.
We could add a family_tree_by_side() function if you really need one,
but the by_neighbor() semantics work the way we want them to for the
library's internal use.
---
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