|
[Sponsors] |
Non orthogonal cells in T-Rex boundary layer mesh |
![]() |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
![]() |
![]() |
#1 |
New Member
Patryk
Join Date: May 2019
Posts: 5
Rep Power: 7 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#2 |
Senior Member
Travis Carrigan
Join Date: Jul 2010
Location: Arlington, TX
Posts: 161
Rep Power: 16 ![]() |
Hello Patryk,
What version of Pointwise are you running? Travis |
|
![]() |
![]() |
![]() |
![]() |
#3 |
New Member
Patryk
Join Date: May 2019
Posts: 5
Rep Power: 7 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#4 |
Senior Member
Travis Carrigan
Join Date: Jul 2010
Location: Arlington, TX
Posts: 161
Rep Power: 16 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#5 |
New Member
Patryk
Join Date: May 2019
Posts: 5
Rep Power: 7 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#6 |
Senior Member
Travis Carrigan
Join Date: Jul 2010
Location: Arlington, TX
Posts: 161
Rep Power: 16 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#7 |
New Member
Patryk
Join Date: May 2019
Posts: 5
Rep Power: 7 ![]() |
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 Last edited by patys3; August 2, 2019 at 09:55. |
|
![]() |
![]() |
![]() |
![]() |
#8 |
Senior Member
Travis Carrigan
Join Date: Jul 2010
Location: Arlington, TX
Posts: 161
Rep Power: 16 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#9 |
New Member
Patryk
Join Date: May 2019
Posts: 5
Rep Power: 7 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#10 |
New Member
Laurens Schalk
Join Date: May 2020
Posts: 3
Rep Power: 6 ![]() |
Hi,
i'm having trouble with the generation of my boundary layer on the surface of a birds wing. I'm not sure, but your problem seems quite similar to what i'm having. At the surface of wing some high non-orthogonal cells are formed and I just can't figure out why it happens and how I can solve it. My surface mesh seems just fine if you ask me and the problem never occurred before, until I needed to lower the initial cell height by a factor of 4 compared to what I was using previously (0,00115 vs 0,0003). I can't find any logic behind where the bad cells are located. The warping of the cells isn't high, there are no high aspect ratio or skewed cells. Some high non-orthogonal cells are even placed above almost perfect squares. I tried fixing it by making the surface mesh twice as fine, making a surface mesh with only triangles, I tried playing around with the tolerance settings of the nodes and connectors at the properties section but nothing helped. I do need to decrease the non orthogonality to around 70, because fluent won't run my simulation at the moment. So I wondered if you, or anyone else, has a solution to this problem. Some info which might be usefull: - Somethimes there are very bad non-orthogonal cells at the front and back of the body of the bird. Even if I don't change anything (on purpose at least) and initialise the volume mesh sometimes the bad cells at the body pop up, and somethimes they don't. At almost all the changes I made trying to solve the problem the result was that besides the bad cells at the wing there were also the bad cells at the body of the bird - this last point might have something to do with a warning that popped up since i've been trying to make this new volume mesh with a lower initial cell height: "Warning: dom-11: 499 (this number varies) points are out of tolerance with the quilt boundary" Domain 11 is the face on which the body of the bird is mounted btw. I do not think that this warning is the root of the non-orthogonality problem btw since there are a lot of bad cells at the wing itself, but it might be useful info regarding the previous mentioned info. The first 2 pictures are of the best try this far with only bad cells at the wing. Picture 3 and 4 are pictures of when I made the surface mesh twice as fine, still resulting in ugly cells at the wing, but also at the front and back of the birds body. The last picture is of the surface mesh only consisting of triangles. That did help a bit, but I would much rather make the mesh quad dominant. cell_non_orthogonality.jpg cell_non_orthogonality2.jpg non-orthogonality_also_at_body_1.jpg non-orthogonality_also_at_body_2.jpg non_orthogonality_triangles.jpg If anyone could help me reducing the non-orthogonality in those bad cells would be amazing. With kind regards Laurens |
|
![]() |
![]() |
![]() |
![]() |
#11 | |
Senior Member
Sakun
Join Date: Nov 2019
Location: United Kingdom
Posts: 107
Rep Power: 6 ![]() |
Quote:
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 | Thread Starter | Forum | Replies | Last Post |
sliding mesh problem in CFX | Saima | CFX | 46 | September 11, 2021 07:38 |
[snappyHexMesh] snappyHexMesh does not create any mesh except one for the reference cell | Arman_N | OpenFOAM Meshing & Mesh Conversion | 1 | May 20, 2019 17:16 |
[snappyHexMesh] No layers in a small gap | bobburnquist | OpenFOAM Meshing & Mesh Conversion | 6 | August 26, 2015 09:38 |
[snappyHexMesh] SnappyHexMesh no layers and no decent mesh for complex geometry | pizzaspinate | OpenFOAM Meshing & Mesh Conversion | 1 | February 25, 2015 07:05 |
snappyhexmesh remove blockmesh geometry | philipp1 | OpenFOAM Running, Solving & CFD | 2 | December 12, 2014 10:58 |