CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Running, Solving & CFD

Inconsistent Grading Caused by Simple Translation

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

Like Tree2Likes
  • 2 Post By wyldckat

Reply
 
LinkBack Thread Tools Display Modes
Old   July 25, 2013, 21:21
Default Inconsistent Grading Caused by Simple Translation
  #1
New Member
 
Join Date: Jul 2013
Posts: 18
Rep Power: 4
wildfire230 is on a distinguished road
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
However, when I translate every vertex -5 in the z-direction:

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,
blockMesh gives me the error "Inconsistent point locations between block pair 2 and 3, probably due to inconsistent grading." I have not changed the grading in any way, or the block or face definitions. I have simply translated every vertex by -5 in the z-direction. I appreciate any insight into what could be causing this error.

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]
wildfire230 is offline   Reply With Quote

Old   August 2, 2013, 22:38
Default
  #2
New Member
 
okamoto
Join Date: Nov 2012
Posts: 7
Rep Power: 4
kyushusamurai is on a distinguished road
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?
kyushusamurai is offline   Reply With Quote

Old   August 3, 2013, 13:13
Default
  #3
New Member
 
Join Date: Jul 2013
Posts: 18
Rep Power: 4
wildfire230 is on a distinguished road
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.
wildfire230 is offline   Reply With Quote

Old   August 5, 2013, 05:00
Default
  #4
New Member
 
okamoto
Join Date: Nov 2012
Posts: 7
Rep Power: 4
kyushusamurai is on a distinguished road
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.
kyushusamurai is offline   Reply With Quote

Old   August 25, 2013, 07:04
Default
  #5
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,301
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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))
         {
After compiling the library and running blockMesh with both point list combinations, it gave me the information on the situation where things go in the wrong direction. It was when "mergeSqrDist" was defined as "5.37499999213e-29" and at a certain difference of point positions, it gave "magSqrDist" equal to "1.15370907389e-28", instead of a value smaller than the "mergeSqrDist". The value for "magSqrDist" should have been closer to zero, but it wasn't so because of these 4 points:
Code:
           (2.5 0 -19.330127019) // 8
           (3 0 -20.196152423) // 9
           (3.5 0 -21.062177826) // 10
           (3 1 -20.196152423) // 11,
which required too much precision. If you remove the last digit from these 4 Z values, it will be able generate the mesh with success.

For a bit more information on this topic of numerical precision, here's an interesting test:
You'll notice that in double precision it was able to properly represent about 17 of the 19 digits, while in single precision, it only managed to represent 7 of the 19 digits.


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
Ohbuchi and wildfire230 like this.
wyldckat is offline   Reply With Quote

Old   August 25, 2013, 11:08
Default
  #6
New Member
 
Join Date: Jul 2013
Posts: 18
Rep Power: 4
wildfire230 is on a distinguished road
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.
wildfire230 is offline   Reply With Quote

Reply

Thread Tools
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 On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
SIMPLE algorithm in 3D cylindrical coordinates zouchu Main CFD Forum 1 January 20, 2014 18:02
Natural convection in a closed domain STILL NEEDING help! Yr0gErG FLUENT 3 June 12, 2013 02:12
[ICEM] Subdomain meshing and simple Hexahedral Grading Mojtaba.a ANSYS Meshing & Geometry 0 April 22, 2013 13:28
Grading other than simple and edge titio OpenFOAM Native Meshers: blockMesh 0 March 5, 2008 12:50


All times are GMT -4. The time now is 15:18.