CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)
-   -   Inconsistent Grading Caused by Simple Translation (https://www.cfd-online.com/Forums/openfoam-solving/121328-inconsistent-grading-caused-simple-translation.html)

wildfire230 July 25, 2013 21:21
Inconsistent Grading Caused by Simple Translation
 
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
(
);

// ************************************************************************* //

kyushusamurai August 2, 2013 22:38
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?

wildfire230 August 3, 2013 13: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.

kyushusamurai August 5, 2013 05:00
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.

wyldckat August 25, 2013 07:04
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

wildfire230 August 25, 2013 11:08
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.


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