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

T Rex OpenFOAM non ortho cells

Register Blogs Community New Posts Updated Threads Search

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   October 15, 2017, 05:43
Default T Rex OpenFOAM non ortho cells
  #1
New Member
 
Arne
Join Date: Oct 2013
Posts: 16
Rep Power: 12
Arne87 is on a distinguished road
Dear Pointwise experts and foamers,

I trying to generate a grid for a rather easy geometry in Pointwise. I want to use T Rex for it. The case uploaded here is simplified and could be meshed in a structured approach easily. However, the real case consists out of different other domains which make a structured mesh impossible.

The geometry consists out of a simple convex corner in a 3D environment. The first picture shows the geometry from the front side. This cross section is simply extruded to generate a 3D geometry.

When I mesh the geometry using the 3D T Rex I get high maximum angles (~180). However, by applying the 2D T Rex to the surfaces around the convex corner (pic. 3 and 4) I can solve this issue. I can mesh the geometry with 157 being the widest angle. Nevertheless after exporting the mesh to OpenFOAM checkMesh shows a lot of highly non orthogonal faces. As show in the second picture the bad cells are on top of the convex corner. I already tried to increase the number of cells in the 2D T Rex faces on top and at the sides of the corner. This only increased the number of non orthogonal cells.

If somebody could give me a hint how I can get rid of these bad quality cells I would be very thankful.

I attached some pictures of the geometry the checkMesh ouput. If you need any further information please let me know!

Best

Arne

Code:
/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  4.1                                   |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 4.1-1e03d68d4f4e
Exec   : checkMesh
Date   : Oct 15 2017
Time   : 10:48:10
Host   : "ubuntu-Precision-Tower-7910"
PID    : 9890
Case   : /home/ubuntu/Arne/ship
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMas
ter
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

--> FOAM Warning : 
    From function static Foam::instantList Foam::timeSelector::select0(Foam::Time&, const Foam::argList&)
    in file db/Time/timeSelector.C at line 270
    No time specified or available, selecting 'constant'
Create polyMesh for time = constant

Time = constant

Mesh stats
    points:           33271
    faces:            219378
    internal faces:   205280
    cells:            96607
    faces per cell:   4.39573
    boundary patches: 1
    point zones:      0
    face zones:       0
    cell zones:       0

Overall number of cells of each type:
    hexahedra:     0
    prisms:        38190
    wedges:        0
    pyramids:      40
    tet wedges:    0
    tetrahedra:    58377
    polyhedra:     0

Checking topology...
    Boundary definition OK.
    Cell to face addressing OK.
    Point usage OK.
    Upper triangular ordering OK.
    Face vertices OK.
    Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces...
    Patch               Faces    Points   Surface topology                  
    Unspecified         14098    8515     ok (closed singly connected)      

Checking geometry...
    Overall domain bounding box (0 0 0) (2.2 2.00007 1.00007)
    Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
    Mesh has 3 solution (non-empty) directions (1 1 1)
    Boundary openness (3.38317e-16 5.4217e-16 5.02142e-16) OK.
    Max cell openness = 3.0517e-16 OK.
    Max aspect ratio = 199.976 OK.
    Minimum face area = 3.86179e-07. Maximum face area = 0.011583.  Face area magnitudes OK.
    Min volume = 1.28726e-08. Max volume = 0.000396885.  Total volume = 4.20003.  Cell volumes OK.
    Mesh non-orthogonality Max: 89.1897 average: 17.813
   *Number of severely non-orthogonal (> 70 degrees) faces: 410.
    Non-orthogonality check OK.
  <<Writing 410 non-orthogonal faces to set nonOrthoFaces
    Face pyramids OK.
    Max skewness = 2.52142 OK.
    Coupled point location match (average 0) OK.

Mesh OK.

End
Attached Images
File Type: jpg convexGrid.jpg (147.5 KB, 190 views)
File Type: png badCells.png (18.9 KB, 158 views)
File Type: jpg TrexSurfaceMeshSide.jpg (66.9 KB, 123 views)
File Type: jpg TrexSurfaceMeshTop.jpg (101.2 KB, 87 views)

Last edited by Arne87; October 15, 2017 at 11:02.
Arne87 is offline   Reply With Quote

Old   October 26, 2017, 08:58
Default
  #2
Senior Member
 
Chris Sideroff
Join Date: Mar 2009
Location: Ottawa, ON, CAN
Posts: 434
Rep Power: 22
cnsidero is on a distinguished road
Based on the first 2 images it looks you need to change 2 T-Rex attributes

1) set Max Layers to a larger value. The layers look to be stopping before the cells reach isotropy. Generally, specify a value more than the # layers than you expect.

2) set Full Layers to a non-zero value. Most importantly has the effect of turning on the multiple normals, which is what I see in the 2nd image.

-Chris
cnsidero is offline   Reply With Quote

Old   October 27, 2017, 10:08
Default
  #3
New Member
 
Arne
Join Date: Oct 2013
Posts: 16
Rep Power: 12
Arne87 is on a distinguished road
Hey Chris,

thank you for the answer.

actually increasing the number of full layers fixed the problem. Concerning the second point. Is it always recommended to grow the T-Rex cells until they reach isotropy? With other grid generation software I often see high aspect ratios between the boundary layer cells and the first tets.

Best

arne
Arne87 is offline   Reply With Quote

Old   October 27, 2017, 10:21
Default
  #4
Senior Member
 
Chris Sideroff
Join Date: Mar 2009
Location: Ottawa, ON, CAN
Posts: 434
Rep Power: 22
cnsidero is on a distinguished road
Quote:
Originally Posted by Arne87 View Post
actually increasing the number of full layers fixed the problem.
Great. It's nice when the fixes are simple.

Quote:
Concerning the second point. Is it always recommended to grow the T-Rex cells until they reach isotropy? With other grid generation software I often see high aspect ratios between the boundary layer cells and the first tets.
arne
Yes it is. The reason being is that T-Rex can continue layer growth locally if it stops at some other point(s) due to quality, collision, isotropy, etc. Or said alternately, it does not require full layers everywhere. This is the biggest advantage the T-Rex-type approach has over all other unstructured viscous meshers. You often see large jumps in cell sizes between the boundary layer and first tets in other meshers because they require full layers at every point - often not practical/achievable for complex geometries - and the layer growth stops early where the boundary layer cells still have a high aspect ratio.

So my general rule is to use a value for Max Layers more than the number of layers you anticipate and let T-Rex stop the layers once the cells are isotropic.

-Chris

Last edited by cnsidero; October 27, 2017 at 13:34.
cnsidero is offline   Reply With Quote

Old   November 1, 2017, 05:13
Default
  #5
New Member
 
Arne
Join Date: Oct 2013
Posts: 16
Rep Power: 12
Arne87 is on a distinguished road
Hey Chris,

if I grow my anisotropic cells until I reach isotropy I end up with a lot of non orthogonal cells again. T-Rex is set to stop at a maximum angle of 160. Hence, the resulting cells are fine for the quality metrics of pointwise (>160). However, checkMesh judges them to be highly non orthogonal (84 degree). Is there a way to set up T Rex in way to check the quality of the cells optimized for openFOAM? Atm I have to stop the T Rex cell growth with the max layer option.

Best

Arne
Arne87 is offline   Reply With Quote

Old   November 1, 2017, 13:11
Default
  #6
Senior Member
 
Chris Sideroff
Join Date: Mar 2009
Location: Ottawa, ON, CAN
Posts: 434
Rep Power: 22
cnsidero is on a distinguished road
For most cases, it's difficult/not possible to entirely eliminate all high non-orthogonal faces. When you say "a lot", how many specifically? And how many total faces in the mesh? Remember to look for faces and not cells because non-orthogonality is measured at faces.

Also if you like, attach an image of the region where you feel there are too many poor quality faces.

Finally, even though you will usually get some poor quality faces from a T-Rex mesh this does not mean a) you are prevented from running the mesh b) the solution quality will be bad. My former colleague at Pointwise, Travis Carrigan, presented a paper at an SAE conference where they discussed OpenFOAM solutions using T-Rex meshes on the DrivAer automotive geometry. The were able to produce very favorable results using T-Rex meshes and there were most like some highly non-orthogonal faces. There are some particular schemes you can use to help deal with them. The main one is to use:

Code:
Gauss linear limited 0.5;
for the laplacianSchemes (or even a value of 0.33 depending on the number of poor quality faces) and

Code:
limited 0.5;
for the snGradSchemes (of even 0.33). You may also need to use slightly lower relaxation factors for p and U in the fvSolution.

-Chris
cnsidero is offline   Reply With Quote

Old   November 2, 2017, 09:09
Default
  #7
Senior Member
 
David Garlisch
Join Date: Jan 2013
Location: Fidelity Pointwise, Cadence Design Systems (Fort Worth, Texas Office)
Posts: 307
Rep Power: 14
dgarlisch is on a distinguished road
In case you were not aware...

Pointwise V18.0R4 includes a new (OpenFOAM) Cell Non-Orthogonality... examine function.

Due to some technical limitations*, the metric averages are not exactly the same as calculated by OpenFOAM checkmesh. However, the values are similar and will give you an opportunity to fix problem areas.


* The averages are off because Pointwise is reporting the values per cell (which is the maximum of each cell's face value) instead of per cell face. At this time, Pointwise cannot calculate metric values at the face level.
dgarlisch is offline   Reply With Quote

Old   November 9, 2017, 11:45
Default
  #8
New Member
 
Arne
Join Date: Oct 2013
Posts: 16
Rep Power: 12
Arne87 is on a distinguished road
Hey Chris and dgarlisch,

thanks for the feedback and sorry for the slow response I had a lot to do recently.

I updated our version of pointwise to the latest release and the possibility to see the non orthogonal cells already in pointwise increases the speed of my work flow a lot. Even if its not the exact openFOAM criteria it gives a much better prediction of the checkMesh output then the max included angle does. However, it would be even better if I could stop the T-Rex growth based on the non orthogonality criteria.

Concerning the geometry. I spoke with some colleagues and we decided that we can show some close ups of the critical geometry.

The first pic (geom.png) shows the geometry. We are looking from the inside onto the domain. T Rex grows cells away from the spectator. In the middle you see a convex edge which is in close vicinity of other corners.
The second picture (meshoverview.png) shows the mesh around the convex edge. The two close ups show the view onto the edge and its surrounding grid form the top and the side. Especially in the second close up the problematic area between the edge and the next corner becomes visible. In the concave corners cells with high orthogonality are created. This is also visible in the output generated by OpenFOAM.

CheckMesh reports like this ~1000 cells with a max non orthognality angle of 85 degree. This in my experience is way to high to run a good simulation. The only way known to me to improve this is to grow less T-Rex layers. In this case the mesh quality improves.

I am looking forward to hear your recommendations.

Best

Arne
Attached Images
File Type: jpg closeUpMesh.jpg (36.8 KB, 74 views)
File Type: jpg closeUpMesh2.jpg (25.2 KB, 76 views)
File Type: jpg geom.jpg (14.9 KB, 54 views)
File Type: jpg meshoverview.jpg (31.2 KB, 51 views)
Arne87 is offline   Reply With Quote

Old   November 9, 2017, 17:30
Default
  #9
Senior Member
 
David Garlisch
Join Date: Jan 2013
Location: Fidelity Pointwise, Cadence Design Systems (Fort Worth, Texas Office)
Posts: 307
Rep Power: 14
dgarlisch is on a distinguished road
I won't be any help with improving T-Rex cell quality.

However, I suggest you call Pointwise or email at support@pointwise.com and log a feature request for:

Stop the T-Rex growth based on cell non-orthogonality criteria

Be sure to include your customer ID in your request.
dgarlisch is offline   Reply With Quote

Old   August 27, 2018, 10:51
Default Did you fix this issue?
  #10
Member
 
sibo
Join Date: Oct 2016
Location: Chicago
Posts: 55
Rep Power: 9
sibo is on a distinguished road
Hi Arne,

I'm wondering did you fix this issue?
I am also facing the high non-orthogonal cells problem. My geometry has some sharp angles and the surface mesh quality is very good. However, the volume mesh generated by T-Rex always give me an extremely high number of non-orthogonal cells. Somehow, by trying the approaches in this post helped a little bit. But OpenFOAM's checkMesh will still complain about this.

I also emailed to Pointwise support team, it seems to me that they couldn't fix this problem. With their help, I got a very nice surface mesh and some suggestions about the parameters' value in TRex. However, it didn't solve this problem.

Hope to hear back from you!
Thanks!
Sibo

Quote:
Originally Posted by Arne87 View Post
Hey Chris and dgarlisch,

thanks for the feedback and sorry for the slow response I had a lot to do recently.

I updated our version of pointwise to the latest release and the possibility to see the non orthogonal cells already in pointwise increases the speed of my work flow a lot. Even if its not the exact openFOAM criteria it gives a much better prediction of the checkMesh output then the max included angle does. However, it would be even better if I could stop the T-Rex growth based on the non orthogonality criteria.

Concerning the geometry. I spoke with some colleagues and we decided that we can show some close ups of the critical geometry.

The first pic (geom.png) shows the geometry. We are looking from the inside onto the domain. T Rex grows cells away from the spectator. In the middle you see a convex edge which is in close vicinity of other corners.
The second picture (meshoverview.png) shows the mesh around the convex edge. The two close ups show the view onto the edge and its surrounding grid form the top and the side. Especially in the second close up the problematic area between the edge and the next corner becomes visible. In the concave corners cells with high orthogonality are created. This is also visible in the output generated by OpenFOAM.

CheckMesh reports like this ~1000 cells with a max non orthognality angle of 85 degree. This in my experience is way to high to run a good simulation. The only way known to me to improve this is to grow less T-Rex layers. In this case the mesh quality improves.

I am looking forward to hear your recommendations.

Best

Arne
sibo is offline   Reply With Quote

Old   August 27, 2018, 11:40
Default
  #11
New Member
 
Arne
Join Date: Oct 2013
Posts: 16
Rep Power: 12
Arne87 is on a distinguished road
Hey Sibo,


it seems like T-Rex has problems with concave corners if they have angles which are clearly smaller then 90 degrees. In that case it is probably the best to slightly alter the geometry.



If your concave corner angle is around 90 degrees you should be able to reach max non-ortho angles around 70 - 75 degrees by applying uniform isotropic surface meshes in the region and playing with the "collision buffer" value. These values should be acceptable for OpenFOAM if you reduce the limiting in the fvSchemes to 0.66 (0.33 if there some ~75 cells).



Hope this helps a bit,


Arne
Arne87 is offline   Reply With Quote

Old   August 27, 2018, 15:21
Default
  #12
Member
 
sibo
Join Date: Oct 2016
Location: Chicago
Posts: 55
Rep Power: 9
sibo is on a distinguished road
Thanks, Arne. I will try to modify my geometry to increase the concave angle and see what happens.

Thanks!
sibo is offline   Reply With Quote

Old   August 28, 2018, 02:41
Default
  #13
New Member
 
Arne
Join Date: Oct 2013
Posts: 16
Rep Power: 12
Arne87 is on a distinguished road
If the boundary layer in this corner is not of major importance for the computation, you could also remove the T-Rex cells in this region.
Arne87 is offline   Reply With Quote

Reply

Tags
openfoam, pointwise, trex, unstructured grid


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 for internal Flow vishwa OpenFOAM Meshing & Mesh Conversion 24 June 27, 2016 08:54
[ICEM] error analysis despaired student ANSYS Meshing & Geometry 7 June 27, 2012 11:57
killed "snappyHexMesh" parkh32 OpenFOAM Pre-Processing 2 April 8, 2012 17:12
[snappyHexMesh] external flow with snappyHexMesh chelvistero OpenFOAM Meshing & Mesh Conversion 11 January 15, 2010 19:43
physical boundary error!! kris Siemens 2 August 3, 2005 00:32


All times are GMT -4. The time now is 02:41.