# Non orthogonal cells in T-Rex boundary layer mesh

 User Name Remember Me Password
 Register Blogs Members List Search Today's Posts Mark Forums Read

July 30, 2019, 08:53
Non orthogonal cells in T-Rex boundary layer mesh
#1
New Member

Patryk
Join Date: May 2019
Posts: 5
Rep Power: 6
Hello,

I have created a hybrid surface mesh for my geometry and created a T-Rex farfield block around it. The bounding box of the surface mesh is of dimensions, more less, 1.5 x 2 x 2. The surface mesh is a combination of structured domains (visible on image 1) and unstructured T-Rex domains (image 2).

I initially set the mesh up using first cell height of 2e-4, but to keep y+<1 in my simulation I need to use 2e-6. The algorithm created 40 to 70 layers of hexes around the surface mesh. After examining the new mesh I noticed that some hexagonal cells right at the surface are severely non orthogonal (70-80) (image 1, 2). I do not know how it is possible, since they are all just very flat hexes aligned with the geometry. The geometry is slightly wavy, but there are no angles high enough to justify non orthogonality of 70+. As seen on images 1 and 2, very orthogonal cells (<0.2, blue) are often showing up right next to the red ones. Image 3 shows a close up of one of the problematic areas with a cutting plane right on top of some of the non orthogonal cells.

What is interesting is that I haven't seen any cells like that when I used the first cell height of 2e-04. Only started happening on much lower first cell height. I managed to recreate the problem on a much simpler geometry (image 4), where I created a rectangle with a wavy top edge using 4 connectors, used normal hyperbolic extrusion with initial spacing of 2e-08 and then translated the mesh to the side with 20 steps. The result (image 5) is that majority of initial structured hexes are severely non-orthogonal (80+). For this geometry I tried model size between 1 and 1000 (the connectors are of length 5 to 20), default node and connector tolerance and grid tolerance of 1e-12.

Is this a tolerance/precision related problem? For the main geometry I used model size 10.0, default node and connector setting and grid point tolerance of 1e-07. I tried lowering it to 1e-12 and rerunning farfield block creation but results are identical. For the record, same (or almost the same) cells are marked by openFOAM checkMesh as severely non orthogonal (>70). Is there anything I can do to get rid of those non orthogonal cells? I do not understand why they are non orthogonal in the first place and have run out of ideas to rectify that issue.

Many thanks,
Patryk
Attached Images
 1.jpg (156.7 KB, 101 views) 2.jpg (154.6 KB, 77 views) 3.jpg (164.9 KB, 72 views) 4.jpg (110.5 KB, 66 views) 5.jpg (98.8 KB, 47 views)

 July 30, 2019, 11:58 #2 Senior Member   Travis Carrigan Join Date: Jul 2010 Location: Arlington, TX Posts: 161 Rep Power: 15 Hello Patryk, What version of Pointwise are you running? Travis __________________ Travis Carrigan Manager, Business Development Pointwise, Inc.

 July 31, 2019, 05:31 #3 New Member   Patryk Join Date: May 2019 Posts: 5 Rep Power: 6 Hi Travis, Thanks for your response. I am using Pointwise V18.2 R1 (Optimized Build 0225131519 (2018-09-13 15:19:00) Windows 64-bit). Patryk

 August 1, 2019, 10:22 #4 Senior Member   Travis Carrigan Join Date: Jul 2010 Location: Arlington, TX Posts: 161 Rep Power: 15 Patryk, The latest release candidate includes a fix for the non-orthogonality calculation that may address this issue. You can contact support with your customer ID and they'll be able to send you a link. Regards, Travis __________________ Travis Carrigan Manager, Business Development Pointwise, Inc.

 August 1, 2019, 11:55 #5 New Member   Patryk Join Date: May 2019 Posts: 5 Rep Power: 6 Hi Travis, Does the latest release only change the way non-orthogonality is calculated by the Examine function? If that's correct, then I am not sure this would fix my issue, as these cells I've shown are also flagged by openFoam's checkMesh utility as severely non-orthogonal. Thanks, Patryk

 August 1, 2019, 12:15 #6 Senior Member   Travis Carrigan Join Date: Jul 2010 Location: Arlington, TX Posts: 161 Rep Power: 15 Patryk, That is correct. So, if OpenFOAM is flagging them, then it is likely they are being reported correctly by Pointwise. My second thought was that those quad elements are slightly warped. As the initial spacing becomes smaller, the hex cells inherit that characteristic. To get around this, you can convert your structured domains to unstructured quads using the diagonalize command. Next, allow T-Rex to split quads into triangles if necessary to improve quality. Travis __________________ Travis Carrigan Manager, Business Development Pointwise, Inc.

August 2, 2019, 09:54
#7
New Member

Patryk
Join Date: May 2019
Posts: 5
Rep Power: 6
Hi Travis,

Thanks for the suggestion. However, the main reason I am using Pointwise in my project is because it allows me to create high quality quad/hex dominant unstructured domains and boundary layer mesh. I would rather not switch to triangles/prisms right now.

Is the non orthogonality of cells close to the wall potentially a non-intended behaviour (i.e. a bug) though? As seen on attached image 5 in my original post, the quads on the sides of the geometry are not warped and their non orthogonality reaches 80+. This can also be reproduced on the 2DAirfoil geometry from the tutorial - when applying hyperbolic normal extrusion with initial spacing of 1e-07, the non orthogonality of some of the cells close to the surface reaches 85 (attached image).

I understand that such spacing is not commonly required in typical applications, but if this is indeed a bug that is affecting my mesh, I would be interested in a possible resolution or a workaround. If it is supposed to work like this, then I will think about altering my simulation setup to accomodate for or eliminate these low quality cells.

Thanks,
Patryk
Attached Images
 6.jpg (110.1 KB, 50 views)

Last edited by patys3; August 2, 2019 at 10:55.

 August 5, 2019, 18:13 #8 Senior Member   Travis Carrigan Join Date: Jul 2010 Location: Arlington, TX Posts: 161 Rep Power: 15 Patryk, We looked into this case a bit further. It is behaving correctly. Those are non-orthogonal elements. The higher the aspect ratio, the more sensitive the non-orthogonality calculation is to deviations in cell centroids. When doing a normal extrusion or T-Rex extrusion where smoothing is used in the marching direction, cell centroids can shift slightly, which for very high aspect ratio elements can cause non-orthogonality to occur. To test this, we did a simple translational extrusion using 1e-7 spacing. Non-ortho was 0 degrees. When we did a normal extrusion off the same surface mesh with the default splay values on the boundaries, non-ortho was slightly positive. Increasing the splay increased the non-ortho value even more. Travis __________________ Travis Carrigan Manager, Business Development Pointwise, Inc.

 August 5, 2019, 22:13 #9 New Member   Patryk Join Date: May 2019 Posts: 5 Rep Power: 6 Travis, Thank you a lot for the confirmation and detailed answer - very much appreciated. I will see what I can do to get around this issue. Patryk

July 6, 2022, 11:57
#11
Member

Sakun
Join Date: Nov 2019
Location: United Kingdom
Posts: 93
Rep Power: 6
Quote:
 Originally Posted by patys3 Travis, Thank you a lot for the confirmation and detailed answer - very much appreciated. I will see what I can do to get around this issue. Patryk
Hi,

Did you find a solution for this ?
i am using openFOAM as well but i have to make the mesh using ansys ICEM.
i have the similar issue like you as well.

much appreciate if you could tell how you resolved your issue

 Tags boundary layer mesh, non orthogonal, t-rex

 Thread Tools Search this Thread Search this Thread: Advanced Search Display Modes Linear Mode

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are Off Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post Saima CFX 46 September 11, 2021 08:38 Arman_N OpenFOAM Meshing & Mesh Conversion 1 May 20, 2019 18:16 [snappyHexMesh] No layers in a small gap bobburnquist OpenFOAM Meshing & Mesh Conversion 6 August 26, 2015 10:38 pizzaspinate OpenFOAM Meshing & Mesh Conversion 1 February 25, 2015 08:05 philipp1 OpenFOAM Running, Solving & CFD 2 December 12, 2014 11:58

All times are GMT -4. The time now is 20:22.

 Contact Us - CFD Online - Privacy Statement - Top