On Wed, 14 Oct 2009, Joa Ljungvall wrote: > When I loop over the nodes, find a face that is on the boundary, and > then move the nodes the problem is, if I understood it correct, that > I might move a hanging node out of the line between the nodes of the > not so refined neighbour.
This is not the only possible failure case: You also might move a vertex node without moving a hanging node (even a non-boundary hanging node) that depends on it. That's the only failure mode in 2D, in fact. > But I can check if this is the case, and instead of moving only the > hanging node I move all three nodes keeping them on a line to > minimize the error vis-a-vis the geometry. Or move all 6 nodes, in case you moved node A which depends on node B and C, node C depends on D and E, and node F depends on nodes B and G? In 3D this is not an extremely unlikely possibility, even with tets. That's why I suggested just fixing things with the constraint equations. It sounds great to optimize the geometry error, but one step at a time. > If this is a region where the solution changes fast this not so > refined element will be refined allowing an improved description of > the geometry. Also, in 3D "this not so refined element" may be "these not so refined elements", since any number of tets can share a boundary node or a boundary edge. --- Roy ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
