[anne]

Ok,
I will run channelOoles tutorial on my grid
to test if I have the same error.
Once I have the result I will let you know,

Anne

[melanie]

Hello,

I come back with more info. I could not run on OF 1.3 because unfortunately I have problems downloading the files (this should be because of the firewall we have here...).

Anyway, I ran the pitzDaily tutorial as Mattijs suggested, and after more than 4 hours, I did not notice a memory increase. This means for me that something is wrong with my settings and/or my mesh, as Anne suggested for her case. If you have a look at the thread "Memory leaks", you can see that I also posted my error there because Hrvoje had the same problem last year with interFoam, and it seems that it came from an assignement problem in a scheme.


Melanie

[mattijs]

... which was fixed in OF1.3 ...

So when you get the chance to download 1.3 let me know if you can/cannot repeat your problem.

[liu]

I run a oodles case on a mesh of about 1.4M cells. For about 4 steps, it run out of memory.

Then I trid valgrind. It even couldn't start. Here is the out put:

$ valgrind --tool=memcheck oodles . pile
==16908== Memcheck, a memory error detector for x86-linux.
==16908== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==16908== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==16908== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==16908== For more details, rerun with: -v
==16908==
==16908== warning: mmap failed on /home/liu19/research/OpenFOAM/OpenFOAM-1.3/lib/linuxGcc4DPDebug/libfiniteVolume. so
==16908== no symbols or debug info loaded
/*---------------------------------------------------------------------------*\
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 1.3 |
| \ / A nd | Web: http://www.openfoam.org |
| \/ M anipulation | |
\*---------------------------------------------------------------------------*/

Exec : oodles . pile
Date : May 15 2006
Time : 20:14:04
Root : /home/liu19/research/OpenFOAM/liu19-1.3/run/tutorials/oodles
Case : pile
Nprocs : 1
Create time

Create mesh, no clear-out for time = 0


Reading transportProperties

Reading field p

Reading field U

Reading/calculating face flux field phi

==16908== Warning: set address range perms: large range 105426480, a 0, v 1
==16908== Warning: set address range perms: large range 105426480, a 0, v 1
**16908** new/new[] failed and should throw an exception, but Valgrind
cannot throw exceptions and so is aborting instead. Sorry.
==16908== at 0x1B90484E: VALGRIND_PRINTF_BACKTRACE (valgrind.h:229)
==16908== by 0x1B904D63: operator new[](unsigned) (vg_replace_malloc.c:139)
==16908== by 0x80948D4: Foam::List<foam::vector<double> >::List(int) (List.C:59)
==16908== by 0x809494B: Foam::Field<foam::vector<double> >::Field(int) (Field.C:54)
==16908==
==16908== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 46 from 2)
==16908== malloc/free: in use at exit: 554779838 bytes in 4398686 blocks.
==16908== malloc/free: 4438499 allocs, 39812 frees, 856829490 bytes allocated.
==16908== For a detailed leak analysis, rerun with: --leak-check=yes
==16908== For counts of detected errors, rerun with: -v

[mattijs]

Hi Liu,

Do you have a smaller case meshed using blockMesh which has the same problem?

[liu]

Sorry, I don't.
I tried smaller case whose mesh comes from Gambit. It didn't give problem at least in the 1000 or so time steps.

The reason valgrind couldn't start up is maybe it needs more memory to record the behavior of the program.

But it's so strange that without valgrid it quits after several steps.

Mattijs:
Can you send me an example 3D LES test case (other than the tutorial toy problem) that I can run on my computer? I have no idea how fine the grid should be. That's why I ended up with 1.4M cells for a simple flow-past-cylinder case.

What I am trying to get is something like:
http://www.iihr.uiowa.edu/people/res...imation1-4.htm

[mattijs]

You could be running just out of virtual memory for another reason than OF memory leaking. As said on the tutorial case (which is the only one I have to answer your question) I see no leakage at all.

You can try taking over the settings from your big case (turb model, solver settings, bs's) onto that one and see if it behaves differently.

[liu]

Ok. I turned off all other programs and let oodles run on this 1.4M mesh.

Here is the result at the sixth step:

Time = 6e-05

Mean and max Courant Numbers = 0.000306349 0.016599
BICCG: Solving for k, Initial residual = 0.068446, Final residual = 6.60569e-09, No Iterations 1
new cannot satisfy memory request.
This does not necessarily mean you have run out of virtual memory.
It could be due to a stack violation caused by e.g. bad use of pointers or an out of date shared library
Aborted

If I am running out virtual memory, why is it at this step? I monitored the system and the unused memory is still plenty.

I tried smaller case. No memory problem. But it didn't generate turbulence either.

[melanie]

Hello,

(I eventually managed to download and install OF 1.3...) Now I have run OF 1.3 on the same case as previously, and I still have an increase of the memory consumption during the run: after 3 hours, the memory increase is more than 200 Mb.
The job is running on the same machine as before.

Thanks for your help !
mélanie

[mattijs]

Does your setup consist of:

- OpenFOAM 1.3
- an unmodified solver
- a tutorial testcase or another case which uses blockMesh to generate the mesh.

[melanie]

My setup is the unmodified solver oodles of OF 1.3, but I have built the testcase by myself, using an imported mesh (from Fluent). It contains cyclic BC. I use a Crank-Nicholson time scheme, and the spatial schemes are Gauss linear or Gauss limited linear. If you need more details, please let me know.
Thanks !

[mattijs]

Can you set up a blockMeshable case which has the same behaviour?

[melanie]

I tried all my settings on the oodles tutorial, but I was not able to reproduce the error... and I don't have another blockMeshable case !
If you have one to submit, I will try.

[mattijs]

- have you run checkMesh on your case
- did you try the crank-nicholson scheme on the tutorial case
- can I download your case or can you send it to me?

[melanie]

- of course I ran checkMesh when I set up the case, everything OK (I just re-ran it to be sure).
- I had exactly the same settings on the tutorial case as on my case, actually I made a copy of controlDict, turbulenceProperties, transportProperties, fvSolution and fvSchemes and it ran as is
- I can send you my case if you leave me your adress or write me at melanie_piellard@yahoo.fr ... although it is quite big: ~200 Mo for the definition and one time step.

[hjasak]

Hi Melanie,

Unfortunately, my machine is not big enough to run your case under valgrind but I tried two other things.

I have run oodles on a smaller mesh with memory checking switched on and there are no problems to report,

I have left your case running over night on the machine and it runs without obvious problems. The memory jumped form 1.2 to 1.4 GB quite early in the simulation but after that remained stable for a number of hours.

In short, I cannot see any problems with the code. This leaves 2 possibilities:
- there may be a problem with your operating system (I have had quite a lot of trouble with Suse-9.1 a while back)
- there may be a slight inconsistency between the compiled version of OpenFOAM and your operating system setup.

I would therefore recommend you try to patch up the operating system to the latest level of patches and completely recompile OpenFOAM.

Please keep me posted,

Hrv

[melanie]

Hrvoje,

I am surprised that on your machine, the memory only jumps to 1.4 Gb and remains stable... 1.2 Gb is the "normal" consumption for this case, and the resident memory keeps around this value. This is the virtual memory that (should) increase a lot.

I will check my OS, but what is strange is that I already ran oodles on other cases (mainly 2D smaller cases), and I did not have this problem, nor with other solvers (lesInterFoam, coodles, simpleFoam)

melanie

[melanie]

The OS is SuSE Linux 9.3 Professional; are you aware of certain versions/patches that could impact the performance of OF ?

[melanie]

Hi Mattijs,
were you able to reproduce the error ?
melanie

[mattijs]

Not sure. Started at 1.2-1.4 and then went up to 1.5 after a few hours. Hard to tell though since memory consumption (mainly in the AMG solver) varies a lot.

This was on Suse10.1 machine. Also Hrvoje doesn't see this problem on small case.

Does backward differencing instead of Crank Nicholson have the same problem?