CFD Online Logo CFD Online URL
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Pre-Processing

snappyHexMesh in parallel leads to segmentation fault

Register Blogs Members List Search Today's Posts Mark Forums Read

LinkBack Thread Tools Search this Thread Display Modes
Old   January 14, 2019, 04:29
Default snappyHexMesh in parallel leads to segmentation fault
New Member
Join Date: Sep 2015
Posts: 13
Rep Power: 10
ChrisHa is on a distinguished road
Hi, I'm sorry if my questions are trivial and if my post is missing important information (please tell me what is missing, if so), but I'm a real newbiew when it comes to OpenFOAM, linux and openmpi.

I have a 'simple' case where I want to do the meshing with snappyHexMesh. My starting point is a BBox (from blockMesh) and one object (from STL file) inside. I ran snappyHexMesh without the parallel option and snappyHexMesh terminated fine, without any errors.

Since a few days, I have access to a server with 88 cores, so I thought, I'll give it a go. Now, if I decompose my mesh using decomposePar (simple) and run snappyHexMesh, the proceedure crashes after a few iterations and I get a 'mpirun noticed that process rank 29 with PID 0 on node openfoam-test exited on signal 11 (Segmentation fault).' error. However, if I take the castellatedMesh result from my previous serial run and progress to run the snapping (run decomposePar and snappyHexMesh (snap true only) for the latestTime), everything works fine in parallel.

What does a 'segmentation fault' stand for? How can I get more information on this error? Does it occur because of a too simple decomposing (simple)? If so, is there a guide on how to split your mesh best?

Thanks for any hints and as I said - I'm sorry for any stupid questions & please be kind and help me providing relevant information...
ChrisHa is offline   Reply With Quote

Old   January 14, 2019, 10:04
Default decomposing was reason for error
New Member
Join Date: Sep 2015
Posts: 13
Rep Power: 10
ChrisHa is on a distinguished road
Ok, I created *.vtk files for each processor decomposition (from the blockMesh result) and had a look at them in paraview. Some of them do look a bit weird (i.e. split in to two non-connecting blocks - why?) and after a few guesses of different (simple) decomposition arrangements, I found a working one.

Nevertheless, I'm still interested in what can cause a bad decomposition to fail and what would be a good way to decompose. How do you proceed if you want to manually decompose?
ChrisHa is offline   Reply With Quote


decomposepar, segmentation fault: 11, snappyhexmesh parallel

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On

Similar Threads
Thread Thread Starter Forum Replies Last Post
Parallel UDF Segmentation fault error KevinZ09 Fluent UDF and Scheme Programming 1 January 9, 2017 05:30
Explicitly filtered LES saeedi Main CFD Forum 16 October 14, 2015 11:58
[snappyHexMesh] snappyHexMesh Segmentation Fault avd28 OpenFOAM Meshing & Mesh Conversion 11 May 11, 2015 20:32
Segmentation fault with parallel computing Prad Main CFD Forum 0 December 11, 2008 07:44
Fluent parallel: segmentation fault? hp FLUENT 2 September 6, 2001 14:18

All times are GMT -4. The time now is 16:35.