|
[Sponsors] |
Inconsistent Grading Caused by Simple Translation |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
July 25, 2013, 21:21 |
Inconsistent Grading Caused by Simple Translation
|
#1 |
Senior Member
Join Date: Jul 2013
Posts: 124
Rep Power: 13 |
I have a simple blockMeshDict which creates four 6-sided blocks. blockMesh runs fine when I define the vertices as follows:
Code:
(5 0 0) // 0 (6 0 0) // 1 (6 0 -10) // 2 (5 0 -10) // 3 (6 1 0) // 4 (6 1 -10) // 5 (7 0 0) // 6 (7 0 -10) // 7 (2.5 0 -14.330127019) // 8 (3 0 -15.196152423) // 9 (3.5 0 -16.062177826) // 10 (3 1 -15.196152423) // 11 Code:
(5 0 -5) // 0 (6 0 -5) // 1 (6 0 -15) // 2 (5 0 -15) // 3 (6 1 -5) // 4 (6 1 -15) // 5 (7 0 -5) // 6 (7 0 -15) // 7 (2.5 0 -19.330127019) // 8 (3 0 -20.196152423) // 9 (3.5 0 -21.062177826) // 10 (3 1 -20.196152423) // 11, For your information, here is the full blockMeshDict: Code:
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 2.2.0 | | \\ / A nd | Web: www.OpenFOAM.com | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.2; format ascii; class dictionary; object blockMeshDict; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // vertices ( (5 0 0) // V0 = 0. (6 0 0) // V1 = 1. (6 0 -10) // V2 = 2. (5 0 -10) // V3 = 3. (6 1 0) // V4 = 4. (6 1 -10) // V5 = 5. (7 0 0) // V6 = 6. (7 0 -10) // V7 = 7. (2.5 0 -14.330127019)//8 (3 0 -15.196152423)//9 (3.5 0 -16.062177826)//10 (3 1 -15.196152423)//11 ); blocks ( hex (2 7 5 2 1 6 4 1) (35 35 35) simpleGrading (1 1 1) hex (2 2 5 3 1 1 4 0) (35 35 35) simpleGrading (1 1 1) hex (9 10 11 9 2 7 5 2) (35 35 35) simpleGrading (1 1 1) hex (9 9 11 8 2 2 5 3) (35 35 35) simpleGrading (1 1 1) ); // Create the quarter circles. edges ( ); patches ( patch inlet ( (11 10 9 9) (9 8 11 9) ) wall walls ( (11 8 3 5) (10 11 5 7) (8 9 2 3) (9 10 7 2) (3 2 1 0) (2 7 6 1) (5 4 6 7) (5 3 0 4) ) patch outlet ( (4 0 1 1) (1 6 4 1) ) ); mergePatchPairs ( ); // ************************************************************************* // Last edited by wyldckat; August 24, 2013 at 19:59. Reason: Added [CODE][/CODE] |
|
August 2, 2013, 22:38 |
|
#2 |
New Member
okamoto
Join Date: Nov 2012
Posts: 7
Rep Power: 13 |
Dear Wildfire230,
Did you solved the problem because I also facing the same problem and still working on it. If you have already solved the problem could you please share the information? |
|
August 3, 2013, 13:13 |
|
#3 |
Senior Member
Join Date: Jul 2013
Posts: 124
Rep Power: 13 |
All I could figure out was that it is some problem with generating blocks with six vertices. I think as you get farther from the origin, somehow errors add up, and the 4 vertices which are supposed to collapse into 2 somehow do not line up perfectly when the points are created. That's all I can think of. My only recommendation is to remake your mesh using blocks with 8 vertices.
|
|
August 5, 2013, 05:00 |
|
#4 |
New Member
okamoto
Join Date: Nov 2012
Posts: 7
Rep Power: 13 |
Dear wilfire230,
Thank you very much for your suggestion. It helps me a lot and I already solved the problem. Your cooperation is highly appreciated. |
|
August 25, 2013, 07:04 |
|
#5 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,980
Blog Entries: 45
Rep Power: 128 |
Greetings to all!
I saw this thread about a week ago and I managed to have a look into this myself. I've found the reason as to why this occurs and another way on how to not need to have to keep the geometry 5.0m closer to the origin (along Z). What I did was look into the file "src/mesh/blockMesh/blockMesh/blockMeshMerge.C", which is the one that emits the error message. Then I did the modifications indicated by this patch: Code:
diff --git a/src/mesh/blockMesh/blockMesh/blockMeshMerge.C b/src/mesh/blockMesh/blockMesh/blockMeshMerge.C index 5d0d7f4..75fcafc 100644 --- a/src/mesh/blockMesh/blockMesh/blockMeshMerge.C +++ b/src/mesh/blockMesh/blockMesh/blockMeshMerge.C @@ -120,6 +120,11 @@ void Foam::blockMesh::calcMergeInfo() boundBox bb(blockCells[blockPlabel].points(blockFaces, blockPoints)); const scalar mergeSqrDist = magSqr(SMALL*bb.span()); + if (verboseOutput) + { + Info<< "Merge SqrDist reference to be used: " << mergeSqrDist << endl; + } + // This is an N^2 algorithm scalar sqrMergeTol = GREAT; @@ -171,7 +176,12 @@ void Foam::blockMesh::calcMergeInfo() else { sqrMergeTol = min(sqrMergeTol, magSqrDist); + if (verboseOutput) + { + Info<< "sqrMergeTol: " << sqrMergeTol << " vs magSqrDist: " << magSqrDist << endl; + } } + } } } @@ -179,6 +189,10 @@ void Foam::blockMesh::calcMergeInfo() sqrMergeTol /= 10.0; + if (verboseOutput) + { + Info<< "Merge tolerance to be used: " << sqrMergeTol << endl; + } if (topology().isInternalFace(blockFaceLabel)) { Code:
(2.5 0 -19.330127019) // 8 (3 0 -20.196152423) // 9 (3.5 0 -21.062177826) // 10 (3 1 -20.196152423) // 11, For a bit more information on this topic of numerical precision, here's an interesting test:
In your case, you had around 11 digits to represent, but the blockMesh code needs to rely on square values, which roughly means that it would require around 22 digits to handle accurately the calculated distances. But since it fortunately it does not require so many digits of precision, if we remove the 11th digit, 17 out of 20 digits is precision enough for still being able to properly generate this mesh, given the algorithm that was used. So, what do we learn from this: use only the precision that you truly need! At least for mesh generation Best regards, Bruno
__________________
|
|
August 25, 2013, 11:08 |
|
#6 |
Senior Member
Join Date: Jul 2013
Posts: 124
Rep Power: 13 |
Thanks! That was a great answer. I guessed it was an issue with precision, but I didn't know how to check for sure, or how to solve the issue.
|
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Natural convection in a closed domain STILL NEEDING help! | Yr0gErG | FLUENT | 4 | December 2, 2019 00:04 |
SIMPLE algorithm in 3D cylindrical coordinates | zouchu | Main CFD Forum | 1 | January 20, 2014 17:02 |
[ICEM] Subdomain meshing and simple Hexahedral Grading | Mojtaba.a | ANSYS Meshing & Geometry | 0 | April 22, 2013 13:28 |
[blockMesh] Grading other than simple and edge | titio | OpenFOAM Meshing & Mesh Conversion | 0 | March 5, 2008 11:50 |