View Issue Details

IDProjectCategoryView StatusLast Update
0001509OpenFOAMBugpublic2015-02-25 19:32
Reporterfeymark Assigned Tohenry  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSArch LinuxOS Version(please specify)
Summary0001509: Check mesh ***Max skewness warning
DescriptionWhen I scale down one of my meshes the Max skewness changes. The problem could be solved by using VSMALL instead of SMALL in primitiveMeshTools.C. See below.

--- a/src/OpenFOAM/meshes/primitiveMesh/primitiveMeshCheck/primitiveMeshTools.C
+++ b/src/OpenFOAM/meshes/primitiveMesh/primitiveMeshCheck/primitiveMeshTools.C
@@ -47,7 +47,7 @@ Foam::scalar Foam::primitiveMeshTools::faceSkewness
     // Skewness vector
     vector sv =
         Cpf
- - ((fAreas[faceI] & Cpf)/((fAreas[faceI] & d) + SMALL))*d;
+ - ((fAreas[faceI] & Cpf)/((fAreas[faceI] & d) + VSMALL))*d;
     vector svHat = sv/(mag(sv) + VSMALL);
 
     // Normalisation distance calculated as the approximate distance
TagsNo tags attached.

Activities

henry

2015-02-05 13:28

manager   ~0003695

VSMALL is often too small for this kind of stabilization and leads to floating-point overflow exceptions. Have you tested this change on a range of cases with floating-point exception handling on? Also is it OK is single precision? We need to be very sure that this kind of change does not break OpenFOAM before commiting it.

feymark

2015-02-05 13:39

reporter   ~0003696

I have tried it on a number of cases with floating-point exception handling on. The thing is that in boundaryFaceSkewness VSMALL is used for the exact same type of computation. I would be surprised if the change from SMALL to VSMALL in faceSkewness would cause any problem.

henry

2015-02-05 14:06

manager   ~0003697

That is a fair point, I will make the change in OpenFOAM-dev and include it in my tests. If all is well I will also make the change to OpenFOAM-2.3.x.

henry

2015-02-05 19:08

manager   ~0003700

Resolved by commit 6fa7ca79e794debe18732b7adbf4d9e1834372e8

user4

2015-02-25 15:37

  ~0003908

We're seeing some sigfpe with VSMALL from snappyHexMesh and collapseFaces both of which create illegal meshes which then get checked and undone. ROOTVSMALL (1e-150) might be better compromise.

henry

2015-02-25 15:44

manager   ~0003909

Does ROOTVSMALL solve this problem for your cases?

henry

2015-02-25 18:16

manager   ~0003911

commit f33ec09da841a0f9e833612458d1fd4d8237a512

    primitiveMeshTools: VSMALL -> ROOTVSMALL

user4

2015-02-25 19:32

  ~0003912

Testcase just finished - fix is ok.

Issue History

Date Modified Username Field Change
2015-02-05 13:24 feymark New Issue
2015-02-05 13:28 henry Note Added: 0003695
2015-02-05 13:39 feymark Note Added: 0003696
2015-02-05 14:06 henry Note Added: 0003697
2015-02-05 19:08 henry Note Added: 0003700
2015-02-05 19:08 henry Status new => resolved
2015-02-05 19:08 henry Resolution open => fixed
2015-02-05 19:08 henry Assigned To => henry
2015-02-25 15:37 user4 Note Added: 0003908
2015-02-25 15:44 henry Note Added: 0003909
2015-02-25 18:16 henry Note Added: 0003911
2015-02-25 19:32 user4 Note Added: 0003912