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

 Re: [Libmesh-devel] Finding parent nodes... From: Derek Gaston - 2006-07-12 18:54:28 ```On 7/12/06, Derek Gaston wrote: > Ben... did you get a reply in there that didn't go to the list? I > don't see a reply from you. > I just now received Ben's reply... that should have come in before Roy's... weird. Derek ```

 Re: [Libmesh-devel] Finding parent nodes... From: Kirk, Benjamin \(JSC-EG\) - 2006-07-12 16:49:53 ```Have a look at the embedding matrices in src/geom/face_quad4.C, for example. These define how children's new nodes are created from old nodes.=20 For your 1--3--2=20 example, you can simply re-compute node 3's location based on an updated 1&2 during a smoothing step. Of course, some day we might be able to solve the smoothing linear system the same way we solve all others, then the dof_map constraints could be applied directly. -Ben -----Original Message----- From: libmesh-devel-bounces@... [mailto:libmesh-devel-bounces@...] On Behalf Of Derek Gaston Sent: Monday, July 10, 2006 3:36 PM To: Roy Stogner Cc: libmesh-devel@... Subject: Re: [Libmesh-devel] Finding parent nodes... 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=20 > > 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=20 > > hanging node is on... and then pull out the two vertices that make=20 > > up that side... which will be the parent ones I need to use. > > > > I'm getting this idea from looking through=20 > > 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=20 > 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 ------------------------------------------------------------------------ - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ Libmesh-devel mailing list Libmesh-devel@... https://lists.sourceforge.net/lists/listinfo/libmesh-devel ```
 Re: [Libmesh-devel] Finding parent nodes... From: Roy Stogner - 2006-07-12 17:22:14 ```On Wed, 12 Jul 2006, Kirk, Benjamin (JSC-EG) wrote: > Have a look at the embedding matrices in src/geom/face_quad4.C, for > example. These define how children's new nodes are created from old > nodes. Good catch - I completely forgot about that. > Of course, some day we might be able to > solve the smoothing linear system the same way we solve all others, then > the dof_map constraints could be applied directly. Only for isogeometric Lagrange elements. I've updated more than enough old code that used to only work with Lagrange elements; could we please try to make new code more generalized from the start? One of these days I'm going to get fed up and switch the default FE type from Lagrange to Hierarchic, just to see how much of everyone else's code breaks after their next CVS update. :-P --- Roy ```
 Re: [Libmesh-devel] Finding parent nodes... From: Roy Stogner - 2006-07-12 17:27:59 ```On Wed, 12 Jul 2006, Roy Stogner wrote: > Only for isogeometric Lagrange elements. I mean isoparametric, of course. I promise I'm not catching NURBS-fever. --- Roy ```
 Re: [Libmesh-devel] Finding parent nodes... From: Derek Gaston - 2006-07-12 17:52:40 ```Ben... did you get a reply in there that didn't go to the list? I don't see a reply from you. On 7/12/06, Roy Stogner wrote: > On Wed, 12 Jul 2006, Kirk, Benjamin (JSC-EG) wrote: > > > Have a look at the embedding matrices in src/geom/face_quad4.C, for > > example. These define how children's new nodes are created from old > > nodes. Thanks for pointing me there... I think that's the "right" way to do it... I have cludged up something that works for Quad4's with a level one rule... but it will totally destroy itself for anything else (including triangles). I have written it as a seperate mesh_tools method... if anyone is interested let me know.... not that cludgy narrow minded code is all that interesting.... > > Good catch - I completely forgot about that. > > > Of course, some day we might be able to > > solve the smoothing linear system the same way we solve all others, then > > the dof_map constraints could be applied directly. This would, of course, be the end goal... but it's still a long way off. > > Only for isogeometric Lagrange elements. I've updated more than > enough old code that used to only work with Lagrange elements; could > we please try to make new code more generalized from the start? I have tried to write my code as generally as I can... but even when I think it is general it almost always breaks with anything other than plain quads or tris... the reason being that I just don't have enough experience with all the different FE types yet... at the end of my time here I hope to leave a good clean base that doesn't make any assumptions. We'll see... One of my big problems is that smoothing is inherently tied to the physical mesh (meaning vertexes) reconciling that with nodes and dofs has been tough for me... but I'm coming around. Derek ```
 Re: [Libmesh-devel] Finding parent nodes... From: Derek Gaston - 2006-07-12 18:54:28 ```On 7/12/06, Derek Gaston wrote: > Ben... did you get a reply in there that didn't go to the list? I > don't see a reply from you. > I just now received Ben's reply... that should have come in before Roy's... weird. Derek ```