CFD Online Logo CFD Online URL
Home > Forums > OpenFOAM Running, Solving & CFD

Memory leak

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

LinkBack Thread Tools Display Modes
Old   January 2, 2005, 13:32
Default For your info, there is a big
Hrvoje Jasak (Hjasak)
Posts: n/a
For your info, there is a big memory leak when running interFoam with some combinations of differencing schemes, amounting approximately to 1 field per time-step. It took me ages to find it and there will hopefully be a bug fix in the next release. In the meantime, please beware.

This refers to the foam release dated 19/Dec/2004 and will be present on all platforms.

  Reply With Quote

Old   January 10, 2005, 09:09
Default I have tested interFoam on se
Henry Weller (Henry)
Posts: n/a
I have tested interFoam on several cases using valgrind have not been able to reproduce this problem. As far as I am aware none of the FOAM applications suffer from memory leaks. If any of you find memory leak problem running any of the standard FOAM application please send a full report to the new bugs list on this site and we will investigate promptly.
  Reply With Quote

Old   January 10, 2005, 09:25
Default valgrind will now show you th
Hrvoje Jasak (Hjasak)
Posts: n/a
valgrind will now show you the problem: have a look at the change you put into:


regarding the flux handling and the appropriate change you introduced into tmpI.H operator=, line 257 for me. Assigning a "real" tmp object to the tmp created from a reference means there will be no tmp handling in the destructor (look at line 87, isTmp_ is equal to true!!!).

As a result, the flux temporary does not get deleted, the memory usage gets increased in every iteration until the code blows up and Hrv wastes two days and gets very very very upset.

I will send you an update as soon as I can (fixed and tested over here), but I'm still not sure how you didn't notice the memory increase.



(if there's something unclear about the answer or you need more detail, please let me know)
  Reply With Quote

Old   January 10, 2005, 09:28
Default I ran the tutorial case for t
Henry Weller (Henry)
Posts: n/a
I ran the tutorial case for thousands of time-steps checking the memory usage which did not increase. As I say I cannot reproduce your problem.
  Reply With Quote

Old   January 10, 2005, 11:17
Default It appears that the problem i
Henry Weller (Henry)
Posts: n/a
It appears that the problem is not in interFoam but in the Phi differencing scheme as you suggest which I don't generally use for interface tracking, or anything else for that matter because it's not properly tested and exhibits some peculiar behaviour. I suggest you use Gamma2V 1.0 for the moment.

I was not happy with the change I made to tmp to enable this kind of pre-allocation and resetting. I will have a go at fixing this problem in my code but if I am not able to make it completely reliable I will remove the = operator.
  Reply With Quote

Old   January 10, 2005, 12:08
Default I ran a simple case with Phi d
Henry Weller (Henry)
Posts: n/a
I ran a simple case with Phi differencing using valgrind to search for leaks:

valgrind --tool=memcheck --leak-check=yes

and it does pin-point the problem to the place you suggest:

==23806== by 0x1C16DBFC: Foam::PhiScheme::weights(Foam::GeometricField, Foam::fvPatchField,
Foam::volMesh> const&) const (in /home/dm2/henry/OpenFOAM/OpenFOAM-1.0.2/lib/linuxOpt/

I think the fix is simply to change the type of the tmp to being isTmp_ in the assignment operator in tmpI.H:

inline void tmp::operator=(const tmp& t)

if (t.isTmp_)
isTmp_ = true;
ptr_ = t.ptr_;

if (ptr_)
FatalErrorIn("tmp::operator=(const tmp& t)")
::operator=(const tmp& t)")
<< "attempted to assign to a const reference to constant object"
<< abort(FatalError);

This operator is only currently used in the Phi differencing scheme and does not affect any other aspect of OpenFOAM so if you are not using this scheme I would not include this fix as it will cause nearly the whole of OpenFOAM to recompile.

The fix will be in OpenFOAM-1.0.2 which will be release shortly.
  Reply With Quote

Old   May 12, 2006, 03:41
Default Hi, I already left a messag
Mélanie Piellard
Join Date: Mar 2009
Posts: 86
Rep Power: 8
melanie is on a distinguished road

I already left a message on the board (Memory consumption in oodles), but no one had an idea what it could be; then I found this thread.

My problem is quite close to the one you mentioned above, but it happens with the solver oodles and OF 1.2. The memory is increasing a lot during the run (I cannot measure it per time step, but it already made the job blow because the system went out of memory two times - both times, the memory had increased to more than 3 times the normal size). I experienced the case both on parallel and serial runs.

Is it possible that a special combination of schemes is responsile for it ? What would you suggest to me ? (I already tried the valgrind tool, but it can only handle 32-bit executables...)
melanie is offline   Reply With Quote

Old   July 8, 2010, 04:39
Senior Member
Claus Meister
Join Date: Aug 2009
Location: Wiesbaden, Germany
Posts: 241
Rep Power: 9
idrama is on a distinguished road
Unfortunately, I have just spotted you discussion. As far as I know, the problem in question arises under the application of every differencing scheme. I used upwind, QUICK, almost every TVD scheme and NVD schemes, but the problem persist. I would suggest there is a pointer problem; a matrix is not being destructed correctly.

idrama 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
Not enough memory... DAK565656 CFX 1 September 17, 2005 13:36
Memory is too low Aireen FLUENT 3 September 7, 2005 10:25
CFX and Memory student CFX 6 July 12, 2005 20:31
Available memory is less than 2GB in CFX 5.7.1 Korsh Mik CFX 3 June 5, 2005 19:34
piston/cylinder leak Elsayed M Main CFD Forum 1 September 1, 2004 11:21

All times are GMT -4. The time now is 01:22.