[snowygrouch]

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 ?

[wyldckat]

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,
Bruno

[snowygrouch]

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 !

BAD CODE
mpirun -np -4 snappyHexMesh -overwrite -parallel

GOOD CODE
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 0.org 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 0.org 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 !>