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
------------------------------------------------------------------------------
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
