> 2.) *Any* refinement pattern for the pyramid will likely involve a > splitting where some children have a different type than the parent. > Since this would be the only element with such an inhomogeneous > splitting, I'd like to discuss the best way to do this in the present > context of the embedding matrix. Since embedding_matrix() is a > virtual function, it can be redefined in Pyramid sub-classes to do > whatever we want, e.g. we could place -1 entries in the actual tables > and just ensure, through embedding_matrix(), that those entries are > never accessed. The real issue seems to be determining where in the > library, if anywhere, we've assumed that all the children have the > same geometric type. I'd be glad to hear your comments there.
I'll have to look way back in the logs. Before the embedding_matrix we actually did pyramids with the first split you proposed. I'd rather go to the second (only sub-pyramids on the base) for a reimplementation. One issue which has to be addressed is the recursive sideset stuff. That is why the pyramid has a 'nonstandard' side numbering: 0,1,2,3 are the triangular sides, and 4 is the square base. It has to be that way so the child tets (which only have 4 sides) can inherit bcs from the same side in the parent. So that is not a problem, but an issue that must be addressed. The only other thing that comes to mind is places like constraint calculation where we compute on a parent and child. We just need to be careful there is no assumption that they are the same type... I don't think this is an issue at all for Lagrange elements, because constraints are only calculated using the sides, which are of the same type. But perhaps some of Roy's more exotic FE spaces? -Ben ------------------------------------------------------------------------- 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-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
