For your info, there is a big
 

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.

Hrv

I have tested interFoam on se
 

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.

valgrind will now show you th
 

valgrind will now show you the problem: have a look at the change you put into:

~/OpenFOAM/OpenFOAM-1.0/src/OpenFOAM/interpolations/surfaceInterpolation/schemes/Phi/PhiScheme.C

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.

Enjoy,

Hrv

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

I ran the tutorial case for t
 

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.

It appears that the problem i
 

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.

I ran a simple case with Phi d
 

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/libOpenFOAM.so)

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

template
inline void tmp::operator=(const tmp& t)
{
clear();

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

if (ptr_)
{
ptr_->operator++();
}
else
{
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.

Hi, I already left a messag
 

Hi,

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...)

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.

Cheers