Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project!

## Re: [Libmesh-users] avoid inverse mapping

 Re: [Libmesh-users] avoid inverse mapping From: John Peterson - 2009-05-29 14:23:53 ```On Fri, May 29, 2009 at 5:57 AM, Lorenzo Botti wrote: > Hi all,I'm trying to avoid inverse mapping for side integration with the > following procedure. > 1) search for the elem local nodes indices on the side (they are stored in > side_nodes_map). > 2) use a method that returns reference space nodes coordinates for the > element. > 3) map the side quadrature points on the element's side using reference > space coordinates. Nodes ordering match map ordering. > > This works for boundary side integration. > > For internal side integration (DG) > 4) search for the neighbor local nodes indices on the element's side (the > local indices ordering will be different from side_nodes_map). >    This could be done with: >    loop over side nodes (side is the side of the element) >      loop over neighbor nodes >         if side node id is equal to neighbor node id store the neighbor > loop index. > >    Maybe you have better ideas... Hi Lorenzo, It occurs to me that so-called "rotational-invariant" quadrature rules could be a great optimization for interior DG integration and some of the integration routines in Kelly/JumpErrorEstimator. Such rules are invariant under rotations of the reference element in the sense that: if quadrature point q exists in the original rule, then it also exists (and with the same weight) under all possible symmetry-preserving rotations (and reflections, etc, in general) of the reference element. For example, the tensor product Gaussian quadrature rules on Quads have this property, and a number of the rules for triangles do as well. This implies that there is only a simple permutation matrix needed to map between the rule on one side of the interior face and the rule on the other. Since there are a finite number of possible orientations that two face neighbors can share, these permutation matrices could be precomputed and stored (as bitsets if you wanted) ahead of time. I had not bothered to implement such an optimization in the past because I did not see how to generalize it for adapted grids with hanging nodes/faces, but I think it could be valuable for uniform grid DG calculations. I'd actually be surprised if it wasn't fairly common practice... -- John ```

 [Libmesh-users] avoid inverse mapping From: Lorenzo Botti - 2009-05-29 10:57:54 ```Hi all,I'm trying to avoid inverse mapping for side integration with the following procedure. 1) search for the elem local nodes indices on the side (they are stored in side_nodes_map). 2) use a method that returns reference space nodes coordinates for the element. 3) map the side quadrature points on the element's side using reference space coordinates. Nodes ordering match map ordering. This works for boundary side integration. For internal side integration (DG) 4) search for the neighbor local nodes indices on the element's side (the local indices ordering will be different from side_nodes_map). This could be done with: loop over side nodes (side is the side of the element) loop over neighbor nodes if side node id is equal to neighbor node id store the neighbor loop index. Maybe you have better ideas... 5) use the same method of point 2) 6) map the side quadrature points on the neighbor's side using reference space coordinates. Nodes ordering match map ordering. This works for conforming meshes and uses the side mapping we have already computed. For non conforming meshes I would like to use embedded matrix to compute neighbor reference space side coordinates. Is it possible to get the side child number from the element child number? I know that sides have no parents but it would be useful. Thanks Lorenzo ```
 Re: [Libmesh-users] avoid inverse mapping From: John Peterson - 2009-05-29 14:23:53 ```On Fri, May 29, 2009 at 5:57 AM, Lorenzo Botti wrote: > Hi all,I'm trying to avoid inverse mapping for side integration with the > following procedure. > 1) search for the elem local nodes indices on the side (they are stored in > side_nodes_map). > 2) use a method that returns reference space nodes coordinates for the > element. > 3) map the side quadrature points on the element's side using reference > space coordinates. Nodes ordering match map ordering. > > This works for boundary side integration. > > For internal side integration (DG) > 4) search for the neighbor local nodes indices on the element's side (the > local indices ordering will be different from side_nodes_map). >    This could be done with: >    loop over side nodes (side is the side of the element) >      loop over neighbor nodes >         if side node id is equal to neighbor node id store the neighbor > loop index. > >    Maybe you have better ideas... Hi Lorenzo, It occurs to me that so-called "rotational-invariant" quadrature rules could be a great optimization for interior DG integration and some of the integration routines in Kelly/JumpErrorEstimator. Such rules are invariant under rotations of the reference element in the sense that: if quadrature point q exists in the original rule, then it also exists (and with the same weight) under all possible symmetry-preserving rotations (and reflections, etc, in general) of the reference element. For example, the tensor product Gaussian quadrature rules on Quads have this property, and a number of the rules for triangles do as well. This implies that there is only a simple permutation matrix needed to map between the rule on one side of the interior face and the rule on the other. Since there are a finite number of possible orientations that two face neighbors can share, these permutation matrices could be precomputed and stored (as bitsets if you wanted) ahead of time. I had not bothered to implement such an optimization in the past because I did not see how to generalize it for adapted grids with hanging nodes/faces, but I think it could be valuable for uniform grid DG calculations. I'd actually be surprised if it wasn't fairly common practice... -- John ```
 Re: [Libmesh-users] avoid inverse mapping From: Lorenzo Botti - 2009-05-30 00:50:25 ```> > It occurs to me that so-called "rotational-invariant" quadrature rules > could be a great optimization for interior DG integration and some of > the integration routines in Kelly/JumpErrorEstimator. Such rules are > invariant under rotations of the reference element in the sense that: > if quadrature point q exists in the original rule, then it also exists > (and with the same weight) under all possible symmetry-preserving > rotations (and reflections, etc, in general) of the reference element. > > For example, the tensor product Gaussian quadrature rules on Quads > have this property, and a number of the rules for triangles do as > well. This implies that there is only a simple permutation matrix > needed to map between the rule on one side of the interior face and > the rule on the other. Since there are a finite number of possible > orientations that two face neighbors can share, these permutation > matrices could be precomputed and stored (as bitsets if you wanted) > ahead of time. > > > -- > John I see what you mean but I have to warn about this practice. If you are using modal basis functions, even with rotational-invariant quadrature rules, you have to take care of the orientation of the element not to integrate your odd modes differently on opposite sides. You could have also problems with non-linear numerical fluxes when you compute the solution at a physical space side quadrature point for the element and his neighbor. The procedure I've written on the previous mail works well for conforming meshes and is faster than inverse mapping. It is simply a mapping to the reference space for the element and his neighbor (once the correct ordering of nodes is defined). For non-conforming meshes I don't know how to identify the side child number from the parent, the child and the side. With the side child number i could use embedding matrix to compute the neighbor nodes coordinates in reference space. Thank you for any suggestion. Lorenzo ```