|
[Sponsors] |
![]() |
![]() |
#1 |
New Member
Arne
Join Date: Oct 2013
Posts: 16
Rep Power: 12 ![]() |
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 Last edited by Arne87; October 15, 2017 at 11:02. |
|
![]() |
![]() |
![]() |
![]() |
#2 |
Senior Member
Chris Sideroff
Join Date: Mar 2009
Location: Ottawa, ON, CAN
Posts: 434
Rep Power: 22 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#3 |
New Member
Arne
Join Date: Oct 2013
Posts: 16
Rep Power: 12 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#4 | |
Senior Member
Chris Sideroff
Join Date: Mar 2009
Location: Ottawa, ON, CAN
Posts: 434
Rep Power: 22 ![]() |
Great. It's nice when the fixes are simple.
Quote:
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. |
||
![]() |
![]() |
![]() |
![]() |
#5 |
New Member
Arne
Join Date: Oct 2013
Posts: 16
Rep Power: 12 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#6 |
Senior Member
Chris Sideroff
Join Date: Mar 2009
Location: Ottawa, ON, CAN
Posts: 434
Rep Power: 22 ![]() |
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; Code:
limited 0.5; -Chris |
|
![]() |
![]() |
![]() |
![]() |
#7 |
Senior Member
David Garlisch
Join Date: Jan 2013
Location: Fidelity Pointwise, Cadence Design Systems (Fort Worth, Texas Office)
Posts: 307
Rep Power: 14 ![]() |
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. |
|
![]() |
![]() |
![]() |
![]() |
#8 |
New Member
Arne
Join Date: Oct 2013
Posts: 16
Rep Power: 12 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#9 |
Senior Member
David Garlisch
Join Date: Jan 2013
Location: Fidelity Pointwise, Cadence Design Systems (Fort Worth, Texas Office)
Posts: 307
Rep Power: 14 ![]() |
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. |
|
![]() |
![]() |
![]() |
![]() |
#10 | |
Member
sibo
Join Date: Oct 2016
Location: Chicago
Posts: 55
Rep Power: 9 ![]() |
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:
|
||
![]() |
![]() |
![]() |
![]() |
#11 |
New Member
Arne
Join Date: Oct 2013
Posts: 16
Rep Power: 12 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#12 |
Member
sibo
Join Date: Oct 2016
Location: Chicago
Posts: 55
Rep Power: 9 ![]() |
Thanks, Arne. I will try to modify my geometry to increase the concave angle and see what happens.
Thanks! |
|
![]() |
![]() |
![]() |
![]() |
#13 |
New Member
Arne
Join Date: Oct 2013
Posts: 16
Rep Power: 12 ![]() |
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.
|
|
![]() |
![]() |
![]() |
Tags |
openfoam, pointwise, trex, unstructured grid |
|
|
![]() |
||||
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 |