View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000116 | OpenFOAM | Bug | public | 2010-12-23 13:45 | 2011-01-04 11:24 |
| Reporter | wyldckat | Assigned To | |||
| Priority | low | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | Linux | OS | Ubuntu | OS Version | 10.04 |
| Summary | 0000116: Strange behavior by snappyHexMesh in the "incompressible/simpleWindFoam/turbineSiting" tutorial | ||||
| Description | snappyHexMesh doesn't behave normally when running in 32bit Single Precision with the tutorial "incompressible/simpleWindFoam/turbineSiting". Attached is the first 1000 lines of the output made by snappyHexMesh. After 3 hours of execution, it generated a 50GB log file... and it didn't seem like it was going to end any time soon. The output looks like debug output, but I wasn't able to see where the respective flag was in the case files. Of all the tutorials that use snappyHexMesh, this was the only one with such a strange output in single precision. | ||||
| Steps To Reproduce | Start the OpenFOAM (latest 1.7.x) environment in 32bit Single Precision. Build the "linuxGccSPOpt" architecture. Make a copy of the tutorial "incompressible/simpleWindFoam/turbineSiting". Run "./Allrun" in the copied folder. Check the file "log.snappyHexMesh" moments after snappyHexMesh has started to see if you get a similar output to the one attached. Break the execution of "Allrun", unless you want to waste disk space and electricity. | ||||
| Additional Information | I didn't try the SP 64bit version, nor did I debug snappyHexMesh to verify where and why this happens. | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
This is a known problem. It has problems in single precision intersecting close to an edge or point or walking along a face. Workarounds: - shift/tilt your initial mesh slightly - loosen the triSurfaceMesh intersection tolerance. See the commented out 'tolerance' in the sample snappyHexMeshDict in the snappyHexMesh source directory. - use a 'searchableSurfaceWithGaps' instead of a 'triSurfaceMesh'. It refers to an underlying triSurfaceMesh but just perturbs any test with a given offset. You'll have to experiment a bit to get the settings. |
|
|
So, there is no debug flag to disable this sort of output and simply leading snappyHexMesh to crash or something like that... That's a whole lot of trouble, since I'm just developing a test bench for comparing tutorial results between Linux builds and MinGW builds. I guess this tutorial case will have to simply get blacklisted in SP mode. Nonetheless, many thanks for the reply! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-12-23 13:45 | wyldckat | New Issue | |
| 2010-12-23 13:45 | wyldckat | File Added: log.snappyHexMesh_head | |
| 2010-12-23 14:33 |
|
Note Added: 0000198 | |
| 2010-12-23 14:49 | wyldckat | Note Added: 0000199 | |
| 2010-12-23 14:49 | wyldckat | Note Edited: 0000199 | |
| 2011-01-04 11:24 |
|
Status | new => closed |
| 2011-01-04 11:24 |
|
Assigned To | => user4 |
| 2011-01-04 11:24 |
|
Resolution | open => no change required |
