CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Mesh Generation & Pre-Processing Software > Pointwise & Gridgen

Non orthogonal cells in T-Rex boundary layer mesh

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   July 30, 2019, 07:53
Default Non orthogonal cells in T-Rex boundary layer mesh
  #1
New Member
 
Patryk
Join Date: May 2019
Posts: 5
Rep Power: 3
patys3 is on a distinguished road
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
File Type: jpg 1.jpg (156.7 KB, 61 views)
File Type: jpg 2.jpg (154.6 KB, 48 views)
File Type: jpg 3.jpg (164.9 KB, 43 views)
File Type: jpg 4.jpg (110.5 KB, 41 views)
File Type: jpg 5.jpg (98.8 KB, 29 views)
patys3 is offline   Reply With Quote

Old   July 30, 2019, 10:58
Default
  #2
Senior Member
 
Travis Carrigan
Join Date: Jul 2010
Location: Arlington, TX
Posts: 162
Rep Power: 12
tcarrigan is on a distinguished road
Hello Patryk,

What version of Pointwise are you running?

Travis
__________________
Travis Carrigan
Manager, Business Development
Pointwise, Inc.
tcarrigan is offline   Reply With Quote

Old   July 31, 2019, 04:31
Default
  #3
New Member
 
Patryk
Join Date: May 2019
Posts: 5
Rep Power: 3
patys3 is on a distinguished road
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
patys3 is offline   Reply With Quote

Old   August 1, 2019, 09:22
Default
  #4
Senior Member
 
Travis Carrigan
Join Date: Jul 2010
Location: Arlington, TX
Posts: 162
Rep Power: 12
tcarrigan is on a distinguished road
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.
tcarrigan is offline   Reply With Quote

Old   August 1, 2019, 10:55
Default
  #5
New Member
 
Patryk
Join Date: May 2019
Posts: 5
Rep Power: 3
patys3 is on a distinguished road
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
patys3 is offline   Reply With Quote

Old   August 1, 2019, 11:15
Default
  #6
Senior Member
 
Travis Carrigan
Join Date: Jul 2010
Location: Arlington, TX
Posts: 162
Rep Power: 12
tcarrigan is on a distinguished road
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.
tcarrigan is offline   Reply With Quote

Old   August 2, 2019, 08:54
Default
  #7
New Member
 
Patryk
Join Date: May 2019
Posts: 5
Rep Power: 3
patys3 is on a distinguished road
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
File Type: jpg 6.jpg (110.1 KB, 26 views)

Last edited by patys3; August 2, 2019 at 09:55.
patys3 is offline   Reply With Quote

Old   August 5, 2019, 17:13
Default
  #8
Senior Member
 
Travis Carrigan
Join Date: Jul 2010
Location: Arlington, TX
Posts: 162
Rep Power: 12
tcarrigan is on a distinguished road
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.
tcarrigan is offline   Reply With Quote

Old   August 5, 2019, 21:13
Default
  #9
New Member
 
Patryk
Join Date: May 2019
Posts: 5
Rep Power: 3
patys3 is on a distinguished road
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
patys3 is offline   Reply With Quote

Old   June 1, 2020, 17:25
Default
  #10
New Member
 
Laurens Schalk
Join Date: May 2020
Posts: 3
Rep Power: 2
Laurens_NLD is on a distinguished road
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
Laurens_NLD is offline   Reply With Quote

Reply

Tags
boundary layer mesh, non orthogonal, t-rex

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

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 Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
[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
sliding mesh problem in CFX Saima CFX 45 September 22, 2015 10:53
[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


All times are GMT -4. The time now is 01:38.