View Issue Details

IDProjectCategoryView StatusLast Update
0001509OpenFOAM[All Projects] Bugpublic2015-02-25 19:32
ReporterfeymarkAssigned Tohenry 
Status resolvedResolutionfixed 
PlatformLinuxOSArch LinuxOS Version(please specify)
Product Version 
Fixed in Version 
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 =
- - ((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.



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.


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.


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.


2015-02-05 19:08

manager   ~0003700

Resolved by commit 6fa7ca79e794debe18732b7adbf4d9e1834372e8


2015-02-25 15:37


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.


2015-02-25 15:44

manager   ~0003909

Does ROOTVSMALL solve this problem for your cases?


2015-02-25 18:16

manager   ~0003911

commit f33ec09da841a0f9e833612458d1fd4d8237a512

    primitiveMeshTools: VSMALL -> ROOTVSMALL


2015-02-25 19:32


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