## Re: [Libmesh-devel] Finding parent nodes...

 Re: [Libmesh-devel] Finding parent nodes... From: Derek Gaston - 2006-07-10 20:36:22 ```On 7/10/06, Roy Stogner wrote: > On Mon, 10 Jul 2006, Derek Gaston wrote: > > > I've also solve my problem... finding parent nodes that is. I just > > have to go through and check for refinement level (like you said)... > > then use neigh->which_neighbor_am_i() to figure out which side the > > hanging node is on... and then pull out the two vertices that make up > > that side... which will be the parent ones I need to use. > > > > I'm getting this idea from looking through compute_proj_constraints() > > in fe.C (around line 694 through 709) > > > > Does that sound about right? > > That's right in 2D with first order elements (and you're probably also > implicitly assuming that a level one rule is enforced). That should > work to start. > --- > Roy > Heh... at some point I'm going to have to step up and quit assuming things! But of course that time is not now..... ;-) Yes I will be assuming a level one rule for now... not sure if her code handles anything else (I think you can only constrain one hanging node with two non-hanging nodes... and that's it). In 3d things will definitely get more interesting! /me raises his mug.... "To Assumptions!" Derek ```

 [Libmesh-devel] Finding parent nodes... From: Derek Gaston - 2006-07-10 18:02:59 ```Hello all.... I'm trying to get smoothing with adaptivity running... and I've got a brain teaser.... 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? 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. 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? 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? Thanks for any help! Derek ```
 Re: [Libmesh-devel] Finding parent nodes... From: Roy Stogner - 2006-07-10 18:50:06 ```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. > 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 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. > 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 either. --- Roy ```
 Re: [Libmesh-devel] Finding parent nodes... From: Derek Gaston - 2006-07-10 19:23:57 ```On 7/10/06, Roy Stogner 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 > either. 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. > --- > Roy > 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 work on! Derek ```
 Re: [Libmesh-devel] Finding parent nodes... From: Roy Stogner - 2006-07-10 19:37:34 ```On Mon, 10 Jul 2006, Derek Gaston wrote: > 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. I know Larisa has presented results on elements with curved/curvable edges. I don't know whether she was doing a quadratic mapping on those or what. >> 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 >> either. > > 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. When a hanging node moves outside its element side, the mesh will either have a hole (if the node moves away from the coarse element) or an overlap (if the node moves toward the coarse element). Depending on your problem and formulation, that could be disasterous. When a non-hanging node moves outside its element side, I don't think System::project vector will work correctly, and it might even error() out. Since you've been doing refine first, smooth second, this shouldn't have been a problem for you yet, but it's possible that you'll have to turn off project_vector (there's a per-vector bool in the System class) when doing more complicated combinations of refinement and smoothing. > Thank you very much for the reply! No problem... but please take any advice this afternoon with a grain of salt; I had an early flight this morning and so I only got about 5 hours sleep last night... much of my "there should be a function that gives you X" handwaving is because I'm too tired to remember actual method names. :-( --- Roy ```
 Re: [Libmesh-devel] Finding parent nodes... From: Derek Gaston - 2006-07-10 19:47:49 ```On 7/10/06, Roy Stogner wrote: > > > > 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. > > When a hanging node moves outside its element side, the mesh will > either have a hole (if the node moves away from the coarse element) or > an overlap (if the node moves toward the coarse element). Depending > on your problem and formulation, that could be disasterous. > > When a non-hanging node moves outside its element side, I don't think > System::project vector will work correctly, and it might even error() > out. Since you've been doing refine first, smooth second, this > shouldn't have been a problem for you yet, but it's possible that > you'll have to turn off project_vector (there's a per-vector bool in > the System class) when doing more complicated combinations of > refinement and smoothing. I have been uniformly refining first... then smoothing... without incident. Is it just happenstance? > > > Thank you very much for the reply! > > No problem... but please take any advice this afternoon with a grain > of salt; I had an early flight this morning and so I only got about 5 > hours sleep last night... much of my "there should be a function that > gives you X" handwaving is because I'm too tired to remember actual > method names. :-( Heh... no problem... I have all the source anyway... and I can figure it out ;-) > --- > Roy > Derek ```
 Re: [Libmesh-devel] Finding parent nodes... From: Roy Stogner - 2006-07-10 20:07:36 ```On Mon, 10 Jul 2006, Derek Gaston wrote: > I have been uniformly refining first... then smoothing... without > incident. Is it just happenstance? That should always work; you're not just being lucky. The potential for failure comes when you first refine, then smooth, then coarsen. In System::project_vector(), any newly coarsened element C will try to set its new degree of freedom coefficients based on the solution on its fine children F_i, and there's an implicit assumption that C == union(F_i). When you smooth you may be pushing refined elements outside of their parents (or pulling their neighbors inside) and breaking that assumption. Of course, if you're doing smoothing, you've got to have your own solution projection code anyway, so the fix is to just turn off the automatic calls to System::project_vector() and avoid the bug entirely. --- Roy ```
 Re: [Libmesh-devel] Finding parent nodes... From: Derek Gaston - 2006-07-10 20:26:31 ```On 7/10/06, Roy Stogner wrote: > On Mon, 10 Jul 2006, Derek Gaston wrote: > > > I have been uniformly refining first... then smoothing... without > > incident. Is it just happenstance? > > That should always work; you're not just being lucky. > > The potential for failure comes when you first refine, then smooth, > then coarsen. In System::project_vector(), any newly coarsened > element C will try to set its new degree of freedom coefficients based > on the solution on its fine children F_i, and there's an implicit > assumption that C == union(F_i). When you smooth you may be pushing > refined elements outside of their parents (or pulling their neighbors > inside) and breaking that assumption. > > Of course, if you're doing smoothing, you've got to have your own > solution projection code anyway, so the fix is to just turn off the > automatic calls to System::project_vector() and avoid the bug > entirely. > --- > Roy > I see. I've also solve my problem... finding parent nodes that is. I just have to go through and check for refinement level (like you said)... then use neigh->which_neighbor_am_i() to figure out which side the hanging node is on... and then pull out the two vertices that make up that side... which will be the parent ones I need to use. I'm getting this idea from looking through compute_proj_constraints() in fe.C (around line 694 through 709) Does that sound about right? Derek ```
 Re: [Libmesh-devel] Finding parent nodes... From: Roy Stogner - 2006-07-10 20:32:51 ```On Mon, 10 Jul 2006, Derek Gaston wrote: > I've also solve my problem... finding parent nodes that is. I just > have to go through and check for refinement level (like you said)... > then use neigh->which_neighbor_am_i() to figure out which side the > hanging node is on... and then pull out the two vertices that make up > that side... which will be the parent ones I need to use. > > I'm getting this idea from looking through compute_proj_constraints() > in fe.C (around line 694 through 709) > > Does that sound about right? That's right in 2D with first order elements (and you're probably also implicitly assuming that a level one rule is enforced). That should work to start. --- Roy ```
 Re: [Libmesh-devel] Finding parent nodes... From: Derek Gaston - 2006-07-10 20:36:22 ```On 7/10/06, Roy Stogner wrote: > On Mon, 10 Jul 2006, Derek Gaston wrote: > > > I've also solve my problem... finding parent nodes that is. I just > > have to go through and check for refinement level (like you said)... > > then use neigh->which_neighbor_am_i() to figure out which side the > > hanging node is on... and then pull out the two vertices that make up > > that side... which will be the parent ones I need to use. > > > > I'm getting this idea from looking through compute_proj_constraints() > > in fe.C (around line 694 through 709) > > > > Does that sound about right? > > That's right in 2D with first order elements (and you're probably also > implicitly assuming that a level one rule is enforced). That should > work to start. > --- > Roy > Heh... at some point I'm going to have to step up and quit assuming things! But of course that time is not now..... ;-) Yes I will be assuming a level one rule for now... not sure if her code handles anything else (I think you can only constrain one hanging node with two non-hanging nodes... and that's it). In 3d things will definitely get more interesting! /me raises his mug.... "To Assumptions!" Derek ```