|Anonymous | Login | Signup for a new account||2014-04-19 05:20 BST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000116||OpenFOAM||[All Projects] Bug||public||2010-12-23 13:45||2011-01-04 11:24|
|Status||closed||Resolution||no change required|
|Target Version||Fixed in Version|
|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.|
|Attached Files||log.snappyHexMesh_head [^] (75,588 bytes) 2010-12-23 13:45|
This is a known problem. It has problems in single precision intersecting close to an edge or point or walking along a face.
- 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.
edited on: 2010-12-23 14:49
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!
|2010-12-23 13:45||wyldckat||New Issue|
|2010-12-23 13:45||wyldckat||File Added: log.snappyHexMesh_head|
|2010-12-23 14:33||mattijs||Note Added: 0000198|
|2010-12-23 14:49||wyldckat||Note Added: 0000199|
|2010-12-23 14:49||wyldckat||Note Edited: 0000199||View Revisions|
|2011-01-04 11:24||andy||Status||new => closed|
|2011-01-04 11:24||andy||Assigned To||=> mattijs|
|2011-01-04 11:24||andy||Resolution||open => no change required|