## RE: [Libmesh-devel] Mesh smoother

 RE: [Libmesh-devel] Mesh smoother From: - 2005-01-04 19:28:32 ```KIRK, BENJAMIN (JSC-EG) (NASA) writes: > With regard to computing the node positions based on already moved nodes, > this corresponds to a Gauss-Siedel-type iteration of the smoother. The > proposed patch is more like a Jacobi iteration. When the intent is to > perform multiple steps until the nodes no longer move from one iteration to > the next then the Gauss-Siedel iteration is more appropriate. Maybe we can > support both options? Right, if the only intent is to move some nodes, then computing based on already moved nodes might make sense. However when the mesh is severly deformed (advected nodes), then a mesh relaxation is definitively more appropriate. The approach I implemented is equivalent to a network of springs that finds a new equilibrium position (well, after some steps), thus there is more overall smoothing, which I need. The Gauss-Seidel approach deforms the mesh even in areas where the mesh is perfect (try this on an undeformed square mesh to see what I mean). Does that make sense? Martin ```

 RE: [Libmesh-devel] Mesh smoother From: KIRK, BENJAMIN (JSC-EG) (NASA) - 2005-01-03 16:10:48 ```Thanks! With regard to computing the node positions based on already moved = nodes, this corresponds to a Gauss-Siedel-type iteration of the smoother. The proposed patch is more like a Jacobi iteration. When the intent is to perform multiple steps until the nodes no longer move from one = iteration to the next then the Gauss-Siedel iteration is more appropriate. Maybe we = can support both options? -Ben -----Original Message----- From: libmesh-devel-admin@... [mailto:libmesh-devel-admin@...] On Behalf Of Martin = L=FCthi Sent: Saturday, January 01, 2005 6:58 PM To: libmesh-devel Subject: [Libmesh-devel] Mesh smoother Happy new year! The Laplace mesh_smoother did not work correctly for quadratic = elements. There was also a bug for linear elements (the new node positions were calculated based on already moved nodes). This patch does o fix the bug (introducing a vector storing the new positions) o smoothing the mesh for 2nd order elements (by placing the nodes in the weighted center of the adjacent vertices). o fixes a bug in MeshTools::Modification::distort Sometimes extra nodes (not in any element) were not identified correctly due to a comparison with 1.e20 of different types (float and Real=3Ddouble). Comparison for <1.e20 helps. Also the logic was altered. o everything works with Quad4, Quad8, Quad9, Hex8, Hex20, Hex27 Best, Martin ```
 RE: [Libmesh-devel] Mesh smoother From: - 2005-01-04 19:28:32 ```KIRK, BENJAMIN (JSC-EG) (NASA) writes: > With regard to computing the node positions based on already moved nodes, > this corresponds to a Gauss-Siedel-type iteration of the smoother. The > proposed patch is more like a Jacobi iteration. When the intent is to > perform multiple steps until the nodes no longer move from one iteration to > the next then the Gauss-Siedel iteration is more appropriate. Maybe we can > support both options? Right, if the only intent is to move some nodes, then computing based on already moved nodes might make sense. However when the mesh is severly deformed (advected nodes), then a mesh relaxation is definitively more appropriate. The approach I implemented is equivalent to a network of springs that finds a new equilibrium position (well, after some steps), thus there is more overall smoothing, which I need. The Gauss-Seidel approach deforms the mesh even in areas where the mesh is perfect (try this on an undeformed square mesh to see what I mean). Does that make sense? Martin ```