On 7/10/06, Roy Stogner <roystgnr@...> wrote:
> On Mon, 10 Jul 2006, Derek Gaston wrote:
> > Let's say I have an edge with two nodes (1,2) like so:
> > 1----2
> > That edge gets refined so that it now looks like:
> > 1--3--2
> > Firstly.... if 3 is a hanging node... I need to be able run through
> > the mesh and detect that... what would be the best way to detect a
> > hanging node?
> Hmm... well, you can detect which sides have hanging nodes by
> comparing elem->level() to elem->neighbor(n)->level(). For first
> order geometric elements you can find hanging nodes pretty easily
> because they will be pointed to by the fine element but not by the
> coarse element - in fact depending on how you define "hanging node"
> that should work for second order elements too.
Ok... for first order elements I think I understand. I think higher
order are going to have to wait. I think that this might end up being
some of my original contribution from my masters... as I don't think
her code handles anything other than first order elements.
> > Further... if it is a hanging node I need to be able to find it's
> > "parent nodes" (ie 1,2) so that I can constrain its movement.
> Oh, it's even more complicated than that - for second order elements
> in 3D, a hanging node's position may depend on the positions of up to
> 9 unconstrained nodes. You'll want to find the coarse neighbor
> element, find the side that the hanging node is on, and then use all
> the coarse element's nodes on that side to generate the constraints.
> If you need more detailed help, see me in the lab tomorrow afternoon.
I will take you up on that, but maybe not until I get things running
with first order. Like I said, her stuff has no idea about _any_ FE
stuff on the mesh... it's all just working with the physical vertexes.
> > I know that we do constraints in the matrix assembly stuff in this
> > way... is there already a builtin way to return the two immediate
> > parents of this node?
> If you assume isogeometric Lagrange elements, you might be able to
> reuse the DofMap's constraints set. To do things right in general I
> think you'd have to duplicate some of the functionality in
> dof_map_constraints.C and fe_lagrange.C, but the code probably isn't
> flexible enough to reuse as is.
Indeed... I've been looking through that code a bit... I'll have to
dig in a bit further I suppose!
> > My last question.... when we do refinement we always split edges in
> > half. Does the code rely on this new node always lying halfway
> > between the two parent nodes? If the smoother tries to move around
> > new nodes will that make something blow up?
> As long as hanging nodes lie on the element side defined by the
> non-hanging nodes, most code should work fine. The only thin ice
> you've been treading on is System::project_vector(), but if your
> non-AMR code hasn't been breaking that, your AMR code probably won't
Hmmm.... so the node could "slip" along an edge defined by the two
parent nodes.... but not move "outside" of that edge.... Is that true
even when it's a non-hanging node? Or only when it's a hanging node?
I mean right now I move non-hanging nodes that are created through
uniform refinement and don't have any problems.
Thank you very much for the reply! I can see now that getting
smoothing with AMR going might be a little bit of a larger project
than I had initially thought! But that just means more good stuff to