From: Joa L. <li...@jo...> - 2009-10-28 17:33:46
|
Hm... I almost giving up on this one... Looping through the elements, and moving nodes on the boundaries, it is not too difficult to make sure that the element I'm looking at isn't modified in a bad way. However, that node also belongs to a hole line of other elements, that might get destroyed. On top of that, when checking and correcting for hanging nodes, some of the elements that were good, just might go bad. I feel that if I move a node on the boundary given all the conditions I have to for fill I will not be able to improve very much over the "flat" surface approximation already in there. Maybe time to rethink the strategy: Since I produce the first mesh inside my code, using OpenCASCADE+Gmsh I'm thinking maybe I can let Gmsh regenerate a mesh for at each iteration, with the refined mesh of libmesh as a background mesh... or, I claim that I have regions that not are of interest... Why do I bother including them in the first place? cheers Joa On Mon, Oct 26, 2009 at 12:21:35PM -0500, Roy Stogner wrote: > > On Mon, 26 Oct 2009, Joa Ljungvall wrote: > > >What I'm trying to do is: > > > >1) Refine the mesh > >2) Find and store hanging nodes > >3) Move points on boundary to the "real" boundary > >then I do a do{...}While() including > >4) Check that Jacobian>0, if not switch node 0 and 2 (the pointers in the elem) > > I'm not sure this doesn't mess up something for neighbors.. > > This merely hides a symptom without fixing the problem. If you have > two elements ABC and CBD, and you invert one of them by moving a node > too far: > > A---------C A---------C > \ /| \ .-'/ > \ / | \ D / > \ / | \ | / > \ / | \|/ > B----D B > > Changing CBD into CDB doesn't actually make that second mesh valid; > instead of an inverted element you'd have two overlapping elements! > And I'm pretty sure you'll break some of our mesh topology assumptions > (and thereby break the find_neighbors routine, leading to that > remote_elem bug) in the process. > --- > Roy |