View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001509 | OpenFOAM | Bug | public | 2015-02-05 13:24 | 2015-02-25 19:32 |
| Reporter | feymark | Assigned To | henry | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Linux | OS | Arch Linux | OS Version | (please specify) |
| Summary | 0001509: Check mesh ***Max skewness warning | ||||
| Description | When 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 | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
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. |
|
|
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. |
|
|
Resolved by commit 6fa7ca79e794debe18732b7adbf4d9e1834372e8 |
|
|
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. |
|
|
Does ROOTVSMALL solve this problem for your cases? |
|
|
commit f33ec09da841a0f9e833612458d1fd4d8237a512 primitiveMeshTools: VSMALL -> ROOTVSMALL |
|
|
Testcase just finished - fix is ok. |
| 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 |
|
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 |
|
Note Added: 0003912 |
