CFD Online Logo CFD Online URL
Home > Forums > OpenFOAM Native Meshers: snappyHexMesh and Others

Snappyhexmesh parallel using all RAM

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

Like Tree2Likes
  • 2 Post By snowygrouch

LinkBack Thread Tools Display Modes
Old   May 26, 2014, 17:52
Default Snappyhexmesh parallel using all RAM
New Member
Calum Douglas
Join Date: Apr 2013
Location: Coventry, UK
Posts: 17
Rep Power: 5
snowygrouch is on a distinguished road
I just reinstalled OpenFOAM 2.3 on a fresh install of Ubuntu 12.04

Everything works UNTIL, I run a case with snappy making the mesh in parallel. Then on an identical case to that which I have run before, the memory usage just goes up by about 1Gb a SECOND - until all 32GB are used and it starts using swap.

This is crazy as its a 1.2 million cell mesh - which on my Laptop (same OS, same OF) uses about 3Gb or something to mesh. I copied the case directory over - its identical.

Im guessing something in MPI is off...(installed is openMPI ver 1.4.3)...?

Other than re-installing everything anyone got an idea whats happening ?
snowygrouch is offline   Reply With Quote

Old   May 26, 2014, 18:09
Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 9,748
Blog Entries: 39
Rep Power: 103
wyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of light
Greetings Calum,

There are a few hypothesis:
  1. You might have not used the "-parallel" option for launching snappy in parallel, which would multiply the 2-3GB needed by the number of cores used.
  2. A full update of Ubuntu (not a distribution upgrade) and a reboot might be missing.
  3. There might be a caching problem, where the files are being re-read several times over and are occupying the memory. If this were the case, you'll need to confirm if it's really snappyHexMesh which is occupying all of that RAM or if it's the cache size that isn't decreasing.
  4. There might be a memory leak in the decomposition method being used.
  5. If it were an Open-MPI problem, it might be related to a specific network interface that might be installed in the problem machine.
Knowing more about each installation might help more, such as:
  1. Do both machines have Ubuntu 12.04 64-bit installed? Or does one of them have a 32-bit installation?
  2. Which installation instructions for OpenFOAM did you follow?
  3. Was there any customized installation you've done differently?
  4. Which desktop manager are you using? Unity, Gnome, or any other... and if it's configured to 2D or 3D mode, such as using Compiz for those neat fluid interfaces that eat up GPU resources...
Best regards,
wyldckat is offline   Reply With Quote

Old   May 29, 2014, 16:57
Default Solved !!!!
New Member
Calum Douglas
Join Date: Apr 2013
Location: Coventry, UK
Posts: 17
Rep Power: 5
snowygrouch is on a distinguished road
The solution is - dont be a moron.

when I was doing the parallel meshing I accidentally added a "-" before the number of cores to use....

I was lazy and to repeat the command was just cycling back through the terminal entries - without realising it was wrong.

On my laptop of course I typed it correctly the first time and so by repeating the "last command" it always worked !

mpirun -np -4 snappyHexMesh -overwrite -parallel

mpirun -np 4 snappyHexMesh -overwrite -parallel

Here is my confirmed working procedure for SHM in parallel
Procedure for Meshing and Running in Parallel with SnappyHexMesh

1 Rename 0 folder This prevents SHMesh interfering with it
2 <blockMesh> Creates background mesh for SHMesh
3 <surfaceFeatureExtract> So the mesher knows where to snap to
4 <decomposePar> Divides mesh into one section per CPU core
5 <mpirun –np 8 snappyHexMesh –overwrite –parallel> Runs in parallel
6 <reconstructParMesh –constant> Puts the mesh back together again
7 delete all processor folders Clear old mesh data
8 delete folder 0 This was a dummy folder for SHMesh
9 rename folder to 0 Reactivate the folder for the solver to use

10 edit the constant/polymesh/boundary file and remove all the references to patches created by blockMesh in Step2. Leave only the patches desired for the simulation to run. Edit the number at the top of the text file which shows how many patches are to be setup.

11 <decomposePar> Puts the solution setup into a folder per CPU core
12 <mpirun –n 8 renumberMesh –overwrite –parallel> Optimises mesh
13 <mpirun –np 8 pisoFoam –parallel> Run the solver in parallel
14 <reconstructPar> Puts the CPU results back together into one
15 <paraFoam> Launches ParaVIEW to see the results

<type text inside the arrows into the command line but don’t type the arrows !>
sweet_satan and kanes like this.
snowygrouch is offline   Reply With Quote


Thread Tools
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 On
Pingbacks are On
Refbacks are On

Similar Threads
Thread Thread Starter Forum Replies Last Post
SnappyHexMesh in Parallel problem swifty OpenFOAM Native Meshers: snappyHexMesh and Others 10 November 6, 2015 05:40
simpleFoam parallel AndrewMortimer OpenFOAM Running, Solving & CFD 12 August 7, 2015 18:45
snappyHexMesh in parallel shailesh.nitk OpenFOAM Native Meshers: snappyHexMesh and Others 18 January 6, 2014 07:13
SnappyHexMesh OF-1.6-ext crashes on a parallel run norman1981 OpenFOAM Bugs 5 December 7, 2011 13:48
Parallel mesh generation using snappyHexMesh aki_yafuji OpenFOAM Mesh Utilities 0 December 25, 2010 04:49

All times are GMT -4. The time now is 13:27.