[MichiB]

Hi guys,

when I run test cases containing AMI interfaces with

valgrind --tool=memcheck --leak-check -v simpleFoam

it seems that there is a memory leak when the AMI interpolation is carried out.

Tips and/or solution are highly appreciated

Michi

==14632== 1,616 (16 direct, 1,600 indirect) bytes in 1 blocks are definitely lost in loss record 9 of 9
==14632==    at 0x4A0766E: operator new(unsigned long) (vg_replace_malloc.c:220)
==14632==    by 0x6C96E85: _ZN4Foam16AMIInterpolationINS_14PrimitivePatchINS_4faceENS_7SubListERKNS_5FieldINS_6VectorIdEEEES6_EESA_E14calcAddressingERKSA_SD_ii.clone.439 (in /graz/home/openfoam/work/versions/CoupledFoam-2.2.x/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/lib/libmeshTools.so)
==14632==    by 0x6CAE0FE: Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::update(Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&) (in /graz/home/openfoam/work/versions/CoupledFoam-2.2.x/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/lib/libmeshTools.so)
==14632==    by 0x6CB033F: Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::AMIInterpolation(Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::autoPtr<Foam::searchableSurface> const&, Foam::faceAreaIntersect::triangulationMode const&, bool) (in /graz/home/openfoam/work/versions/CoupledFoam-2.2.x/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/lib/libmeshTools.so)
==14632==    by 0x6C99712: Foam::cyclicAMIPolyPatch::resetAMI() const (in /graz/home/openfoam/work/versions/CoupledFoam-2.2.x/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/lib/libmeshTools.so)
==14632==    by 0x6C99B9C: Foam::cyclicAMIPolyPatch::AMI() const (in /graz/home/openfoam/work/versions/CoupledFoam-2.2.x/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/lib/libmeshTools.so)
==14632==    by 0x5BD0027: Foam::cyclicAMIFvPatchField<double>::patchNeighbourField() const (in /graz/home/openfoam/work/versions/CoupledFoam-2.2.x/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/lib/libfiniteVolume.so)
==14632==    by 0x5BB6838: Foam::coupledFvPatchField<double>::evaluate(Foam::UPstream::commsTypes) (in /graz/home/openfoam/work/versions/CoupledFoam-2.2.x/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/lib/libfiniteVolume.so)
==14632==    by 0x5BCB049: Foam::cyclicAMIFvPatchField<double>::cyclicAMIFvPatchField(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) (in /graz/home/openfoam/work/versions/CoupledFoam-2.2.x/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/lib/libfiniteVolume.so)
==14632==    by 0x5BCB506: Foam::fvPatchField<double>::adddictionaryConstructorToTable<Foam::cyclicAMIFvPatchField<double> >::New(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) (in /graz/home/openfoam/work/versions/CoupledFoam-2.2.x/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/lib/libfiniteVolume.so)
==14632==    by 0x4445A4: Foam::fvPatchField<double>::New(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) (in /graz/home/openfoam/work/versions/CoupledFoam-2.2.x/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/bin/simpleFoam)
==14632==    by 0x444AE0: Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricBoundaryField::readField(Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) (in /graz/home/openfoam/work/versions/CoupledFoam-2.2.x/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/bin/simpleFoam)

[wyldckat]

Greetings Michael,

A few questions:

1. Have you modified anything in the source code of OpenFOAM 2.2.x?
2. Which commit of 2.2.x are you using? To see this, you can run:
   

   foam
   git log -1

3. Which case are you running, in order to reproduce this occurrence?

Best regards,
Bruno

[MichiB]

Muito obrigado Bruno for your reply.
It seems that the AMI interfaces that I was using had indeed been changed.
However I also found this error using simlpeFoam with the latest OpenFOAM-2.2.something version with the cycilcPipe test case when the allowSystemOperations tag was set to zero, which was strange.

[wyldckat]

Hi Michael,

Perhaps the error is only similar, but not identical. Because the tutorial "incompressible/simpleFoam/pipeCyclic" uses in the field "U" the boundary condition "codedFixedValue", which needs "allowSystemOperations" to be set to 1, so that it can build the necessary code on time for the solver to use it.

Best regards,
Bruno

[MichiB]

Hi Bruno,
Then it was probably an error on my/our side, that we haven't been cautious enough when adapting the AMIs. Anyway, I will do some more tests to see if the AMIs in the main/src are ok. Otherwise I will let you know...
Valeu! - Michi

[louisgag]

Hello everyone,

I suspect I also have a memory leak, possibly due to the modifications I have made to the AMI interface but have no idea how to identify and/or solve it.

My suspicion comes from the fact that I start my simulation with a certain amount of RAM allocated and that it keeps increasing. After 10h and about 50 time steps it uses the double, and after another 10 hours it will use four times the initial amount of RAM.

I tried running on 2.4.x and also tried running on a different machine but the same problem keeps arising. My solution for now is to relaunch the simulation every X hours, but isn't there a better way to solve this?

I've tried the Valgrind trick pointed out in this thread but I'm not sure it identified any leak. Here is the truncated output from the Valgrind run, which is extremely slow,

$ valgrind --tool=memcheck --leak-check=yes -v pimpleDyMFoam 
==10808== Memcheck, a memory error detector
==10808== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==10808== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==10808== Command: pimpleDyMFoam
==10808== 
--10808-- Valgrind options:
--10808--    --tool=memcheck
--10808--    --leak-check=yes
--10808--    -v
--10808-- Contents of /proc/version:
--10808--   Linux version 3.13.0-54-generic (buildd@allspice) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #91-Ubuntu SMP Tue May 26 19:15:08 UTC 2015
--10808-- Arch and hwcaps: AMD64, amd64-cx16-rdtscp-sse3-avx
--10808-- Page sizes: currently 4096, max supported 4096
--10808-- Valgrind library directory: /usr/lib/valgrind
--10808-- Reading syms from /home/louis/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64Gcc47DPOpt/bin/pimpleDyMFoam
--10808-- Reading syms from /lib/x86_64-linux-gnu/ld-2.19.so
--10808--   Considering /lib/x86_64-linux-gnu/ld-2.19.so ..
--10808--   .. CRC mismatch (computed 4cbae35e wanted 8d683c31)
--10808--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.19.so ..
--10808--   .. CRC is valid
--10808-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux
--10808--   Considering /usr/lib/valgrind/memcheck-amd64-linux ..
--10808--   .. CRC mismatch (computed 37cdde19 wanted adc367dd)
--10808--    object doesn't have a symbol table
--10808--    object doesn't have a dynamic symbol table
--10808-- Scheduler: using generic scheduler lock implementation.
--10808-- Reading suppressions file: /usr/lib/valgrind/default.supp
==10808== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-10808-by-louis-on-???
==10808== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-10808-by-louis-on-???
==10808== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-10808-by-louis-on-???
==10808== 
 [...]
==10808== 
--10808-- REDIR: 0x4019ca0 (strlen) redirected to 0x38068331 (???)
--10808-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so
--10808--   Considering /usr/lib/valgrind/vgpreload_core-amd64-linux.so ..
--10808--   .. CRC mismatch (computed 329d6860 wanted c0186920)
--10808--    object doesn't have a symbol table
--10808-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so
--10808--   Considering /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so ..
--10808--   .. CRC mismatch (computed 1fb85af8 wanted 2e9e3c16)
--10808--    object doesn't have a symbol table
==10808== WARNING: new redirection conflicts with existing -- ignoring it
--10808--     old: 0x04019ca0 (strlen              ) R-> (0000.0) 0x38068331 ???
--10808--     new: 0x04019ca0 (strlen              ) R-> (2007.0) 0x04c2e1a0 strlen
--10808-- REDIR: 0x4019a50 (index) redirected to 0x4c2dd50 (index)
--10808-- REDIR: 0x4019c70 (strcmp) redirected to 0x4c2f2f0 (strcmp)
--10808-- REDIR: 0x401a9c0 (mempcpy) redirected to 0x4c31da0 (mempcpy)
 [...]
--10808-- Reading syms from /lib/x86_64-linux-gnu/libdl-2.19.so
--10808--   Considering /lib/x86_64-linux-gnu/libdl-2.19.so ..
--10808--   .. CRC mismatch (computed c1315e8c wanted 37097b60)
--10808--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libdl-2.19.so ..
--10808--   .. CRC is valid
--10808-- Reading syms from /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
--10808--   Considering /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19 ..
--10808--   .. CRC mismatch (computed a220b90a wanted 886349ba)
--10808--    object doesn't have a symbol table
--10808-- Reading syms from /lib/x86_64-linux-gnu/libm-2.19.so
--10808--   Considering /lib/x86_64-linux-gnu/libm-2.19.so ..
--10808--   .. CRC mismatch (computed a46ef660 wanted 767bfa33)
--10808--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libm-2.19.so ..
--10808--   .. CRC is valid
--10808-- Reading syms from /lib/x86_64-linux-gnu/libgcc_s.so.1
--10808--   Considering /lib/x86_64-linux-gnu/libgcc_s.so.1 ..
--10808--   .. CRC mismatch (computed ea519b66 wanted 0c00ddb3)
--10808--    object doesn't have a symbol table
--10808-- Reading syms from /lib/x86_64-linux-gnu/libc-2.19.so
--10808--   Considering /lib/x86_64-linux-gnu/libc-2.19.so ..
--10808--   .. CRC mismatch (computed dc620abc wanted 148cbd6e)
--10808--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so ..
--10808--   .. CRC is valid
 [...]
--10808-- Reading syms from /lib/x86_64-linux-gnu/libutil-2.19.so
--10808--   Considering /lib/x86_64-linux-gnu/libutil-2.19.so ..
--10808--   .. CRC mismatch (computed e1165780 wanted c579be89)
--10808--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libutil-2.19.so ..
--10808--   .. CRC is valid
--10808-- Reading syms from /lib/x86_64-linux-gnu/libpthread-2.19.so
--10808--   Considering /lib/x86_64-linux-gnu/libpthread-2.19.so ..
--10808--   .. CRC mismatch (computed d568bf33 wanted fb00d679)
--10808--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libpthread-2.19.so ..
--10808--   .. CRC is valid
 [...]
--10808-- REDIR: 0x9cebd60 (strcasecmp) redirected to 0x4a25720 (_vgnU_ifunc_wrapper)
--10808-- REDIR: 0x9cee050 (strncasecmp) redirected to 0x4a25720 (_vgnU_ifunc_wrapper)
--10808-- REDIR: 0x9ceb530 (memcpy@GLIBC_2.2.5) redirected to 0x4a25720 (_vgnU_ifunc_wrapper)
--10808-- REDIR: 0x9ce97c0 (rindex) redirected to 0x4c2da30 (rindex)
--10808-- REDIR: 0x9ce7ac0 (strlen) redirected to 0x4c2e0e0 (strlen)
--10808-- REDIR: 0x9ceafa0 (__GI_memcmp) redirected to 0x4c30b80 (__GI_memcmp)
--10808-- REDIR: 0x9ce6070 (strcmp) redirected to 0x4a25720 (_vgnU_ifunc_wrapper)
--10808-- REDIR: 0x9d9f200 (__strcmp_ssse3) redirected to 0x4c2f1b0 (strcmp)
--10808-- REDIR: 0x949df10 (operator new(unsigned long)) redirected to 0x4c2b070 (operator new(unsigned long))
--10808-- REDIR: 0x9cf0730 (memcpy@@GLIBC_2.14) redirected to 0x4a25720 (_vgnU_ifunc_wrapper)
--10808-- REDIR: 0x9cf6fd0 (__memcpy_sse2_unaligned) redirected to 0x4c2f6b0 (memcpy@@GLIBC_2.14)
--10808-- REDIR: 0x9ce7f30 (__GI_strncmp) redirected to 0x4c2e930 (__GI_strncmp)
--10808-- REDIR: 0x949c260 (operator delete(void*)) redirected to 0x4c2c250 (operator delete(void*))
--10808-- REDIR: 0x949e020 (operator new[](unsigned long)) redirected to 0x4c2b790 (operator new[](unsigned long))
--10808-- REDIR: 0x9ce1750 (malloc) redirected to 0x4c2ab10 (malloc)
--10808-- REDIR: 0x9cea410 (__GI_strstr) redirected to 0x4c32030 (__strstr_sse2)
--10808-- REDIR: 0x9ceaf60 (bcmp) redirected to 0x4a25720 (_vgnU_ifunc_wrapper)
--10808-- REDIR: 0x9dbf060 (__memcmp_sse4_1) redirected to 0x4c30c00 (__memcmp_sse4_1)
--10808-- REDIR: 0x949c290 (operator delete[](void*)) redirected to 0x4c2c7d0 (operator delete[](void*))
--10808-- REDIR: 0x9cf0780 (__GI_memcpy) redirected to 0x4c2fc90 (__GI_memcpy)
--10808-- REDIR: 0x9ceb5c0 (memset) redirected to 0x4c31350 (memset)
--10808-- REDIR: 0x9ceb3a0 (__GI_memmove) redirected to 0x4c31660 (__GI_memmove)
--10808-- REDIR: 0x9ce1df0 (free) redirected to 0x4c2bd80 (free)
--10808-- REDIR: 0x9ce2220 (calloc) redirected to 0x4c2cbf0 (calloc)
--10808-- REDIR: 0x9ceac10 (memchr) redirected to 0x4c2f390 (memchr)
--10808-- REDIR: 0x9cf2ac0 (strchrnul) redirected to 0x4c319b0 (strchrnul)
--10808-- REDIR: 0xffffffffff600400 (???) redirected to 0x3806831d (???)
--10808-- REDIR: 0x9ce7540 (__GI_strcpy) redirected to 0x4c2e2a0 (__GI_strcpy)
--10808-- REDIR: 0x9ce60b0 (__GI_strcmp) redirected to 0x4c2f200 (__GI_strcmp)
/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.3.x                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 2.3.x-e0b2369cc0aa
Exec   : pimpleDyMFoam
Date   : Jun 12 2015
Time   : 14:36:25
Host   : "b12"
PID    : 10808
--10808-- REDIR: 0x9d9d850 (__strncasecmp_avx) redirected to 0x4c2eb60 (strncasecmp)
--10808-- REDIR: 0x9cebbf0 (__GI_stpcpy) redirected to 0x4c30da0 (__GI_stpcpy)
--10808-- Reading syms from /lib/x86_64-linux-gnu/libnss_compat-2.19.so
--10808--   Considering /lib/x86_64-linux-gnu/libnss_compat-2.19.so ..
--10808--   .. CRC mismatch (computed f379a8ef wanted 04dce491)
--10808--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libnss_compat-2.19.so ..
--10808--   .. CRC is valid
--10808-- Reading syms from /lib/x86_64-linux-gnu/libnsl-2.19.so
--10808--   Considering /lib/x86_64-linux-gnu/libnsl-2.19.so ..
--10808--   .. CRC mismatch (computed ea6302f9 wanted daf19eb9)
--10808--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libnsl-2.19.so ..
--10808--   .. CRC is valid
--10808-- Reading syms from /lib/x86_64-linux-gnu/libnss_nis-2.19.so
--10808--   Considering /lib/x86_64-linux-gnu/libnss_nis-2.19.so ..
--10808--   .. CRC mismatch (computed 8cddb751 wanted d4c1aeab)
--10808--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libnss_nis-2.19.so ..
--10808--   .. CRC is valid
--10808-- Reading syms from /lib/x86_64-linux-gnu/libnss_files-2.19.so
--10808--   Considering /lib/x86_64-linux-gnu/libnss_files-2.19.so ..
--10808--   .. CRC mismatch (computed 76d67c28 wanted 59ea999f)
--10808--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libnss_files-2.19.so ..
--10808--   .. CRC is valid
--10808-- REDIR: 0x9ce5e50 (__GI_strchr) redirected to 0x4c2db90 (__GI_strchr)
--10808-- REDIR: 0x9c9ae60 (setenv) redirected to 0x4c32660 (setenv)
--10808-- REDIR: 0x9ce1ef0 (realloc) redirected to 0x4c2ce10 (realloc)
Case   : /media/louis/scrivania/dopoCROP/IAT21/runHD/IAT21L1.exp
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

--10808-- Reading syms from /home/louis/OpenFOAM/louis-2.3.x/platforms/linux64Gcc47DPOpt/lib/libmyFiniteVolume.so
--10808-- Reading syms from /home/louis/OpenFOAM/louis-2.3.x/platforms/linux64Gcc47DPOpt/lib/libmyDynamicFvMesh.so
Create mesh for time = 0.00985466

Selecting dynamicFvMesh multiSolidBodyMotionFvMesh
==10808== Warning: set address range perms: large range [0x6840e040, 0x78551df0) (undefined)
==10808== Warning: set address range perms: large range [0x78552040, 0x88695df0) (undefined)
Selecting solid-body motion function rotatingMotion
Applying solid body motion rotatingMotion
[...]
AMI: Creating addressing and weights between 192228 source faces and 192228 target faces
AMI: Patch source sum(weights) min/max/average = 0.67959223054089, 1.720268139763834, 1.000133389845764
[...]
regIOobject::readIfModified() : 
    Re-reading object controlDict from file "/media/louis/scrivania/dopoCROP/IAT21/runHD/IAT21L1.exp/system/controlDict"
--10808-- Reading syms from /home/louis/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64Gcc47DPOpt/lib/libforces.so
--10808-- Reading syms from /home/louis/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64Gcc47DPOpt/lib/libcompressibleRASModels.so
--10808-- Reading syms from /home/louis/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64Gcc47DPOpt/lib/libcompressibleLESModels.so

Courant Number mean: 0.001064612865787396 max: 3.720317047926161
Time = 0.00987588

solidBodyMotionFunctions::rotatingMotion::transformation(): Time = 0.009875880199999999 transformation: ((0.4080177947301697 -0.2457221460379659 0) (0.5159021665484019 (0 0 0.856647508926901)))
solidBodyMotionFunctions::rotatingMotion::transformation(): Time = 0.009875880199999999 transformation: ((-0.4839200199684039 0.1867644114284415 0) (-0.3600559010145351 (0 0 -0.9329307306250616)))
==10808== Warning: set address range perms: large range [0x6840e028, 0x78551e08) (noaccess)
==10808== Warning: set address range perms: large range [0x78552028, 0x88695e08) (noaccess)
==10808== Warning: set address range perms: large range [0x6840e040, 0x78551df0) (undefined)
==10808== Warning: set address range perms: large range [0x78552040, 0x88695df0) (undefined)
AMI: Creating addressing and weights between 192228 source faces and 192228 target faces
AMI: Patch source sum(weights) min/max/average = 0.5472916394147431, 1.73598121639903, 1.000134253950276
AMI: Patch target sum(weights) min/max/average = 0.4840384752296327, 1.450420042577795, 1.000129206770696
AMI: 
[...]
PIMPLE: iteration 1
==10808== Warning: set address range perms: large range [0x174f59040, 0x19d89cae8) (undefined)
==10808== Warning: set address range perms: large range [0x174f59028, 0x19d89cb00) (noaccess)
==10808== Warning: set address range perms: large range [0x19963f040, 0x1c1f82ae8) (undefined)
==10808== Warning: set address range perms: large range [0x19963f028, 0x1c1f82b00) (noaccess)
smoothSolver:  Solving for Ux, Initial residual = 6.607259889222142e-05, Final residual = 6.529966116017577e-08, No Iterations 1
 [...]
PIMPLE: iteration 2
==10808== Warning: set address range perms: large range [0x1e8ec9040, 0x21180cae8) (undefined)
==10808== Warning: set address range perms: large range [0x1e8ec9028, 0x21180cb00) (noaccess)
==10808== Warning: set address range perms: large range [0x1f6735040, 0x21f078ae8) (undefined)
==10808== Warning: set address range perms: large range [0x1f6735028, 0x21f078b00) (noaccess)
smoothSolver:  Solving for Ux, Initial residual = 1.500236638982456e-07, Final residual = 1.500236638982456e-07, No Iterations 0
smoothSolver:  Solving for Uy, Initial residual = 3.138030140219999e-07, Final residual = 3.138030140219999e-07, No Iterations 0
 [...]
ExecutionTime = 5775.24 s  ClockTime = 5795 s

End

==10808== Warning: set address range perms: large range [0x6840e028, 0x78551e08) (noaccess)
==10808== Warning: set address range perms: large range [0x78552028, 0x88695e08) (noaccess)
--10808-- Discarding syms at 0x37d28630-0x37d65069 in /home/louis/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64Gcc47DPOpt/lib/libforces.so due to munmap()
--10808-- Discarding syms at 0x116ec3060-0x116fd3a9e in /home/louis/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64Gcc47DPOpt/lib/libcompressibleRASModels.so due to munmap()
--10808-- Discarding syms at 0x1172ab080-0x11734f241 in /home/louis/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64Gcc47DPOpt/lib/libcompressibleLESModels.so due to munmap()
--10808-- Discarding syms at 0x10209170-0x1020c0e2 in /home/louis/OpenFOAM/louis-2.3.x/platforms/linux64Gcc47DPOpt/lib/libmyDynamicFvMesh.so due to munmap()
--10808-- Discarding syms at 0xfff20d0-0xfffeb5e in /home/louis/OpenFOAM/louis-2.3.x/platforms/linux64Gcc47DPOpt/lib/libmyFiniteVolume.so due to munmap()
--10808-- Discarding syms at 0xf3aa3b0-0xf3b02fe in /lib/x86_64-linux-gnu/libnss_compat-2.19.so due to munmap()
--10808-- Discarding syms at 0xf7cf1a0-0xf7d56da in /lib/x86_64-linux-gnu/libnss_nis-2.19.so due to munmap()
--10808-- Discarding syms at 0xf5b7160-0xf5c3ea3 in /lib/x86_64-linux-gnu/libnsl-2.19.so due to munmap()
--10808-- Discarding syms at 0xf9db2a0-0xf9e1f63 in /lib/x86_64-linux-gnu/libnss_files-2.19.so due to munmap()
==10808== 
==10808== HEAP SUMMARY:
==10808==     in use at exit: 32 bytes in 1 blocks
==10808==   total heap usage: 668,257,353 allocs, 668,257,352 frees, 136,121,771,321 bytes allocated
==10808== 
==10808== Searching for pointers to 1 not-freed blocks
==10808== Checked 1,057,504 bytes
==10808== 
==10808== LEAK SUMMARY:
==10808==    definitely lost: 0 bytes in 0 blocks
==10808==    indirectly lost: 0 bytes in 0 blocks
==10808==      possibly lost: 0 bytes in 0 blocks
==10808==    still reachable: 32 bytes in 1 blocks
==10808==         suppressed: 0 bytes in 0 blocks
==10808== Reachable blocks (those to which a pointer was found) are not shown.
==10808== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==10808== 
==10808== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==10808== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Regards,


-Louis

[wyldckat]

Originally Posted by louisgag

I suspect I also have a memory leak, possibly due to the modifications I have made to the AMI interface but have no idea how to identify and/or solve it.

Quick possibilities:

1. DIY: Isolate and conquer, i.e. comment out most code and then add back in parts, where possible.
2. If you can provide at least an example of the changes you've made, it will be easier to try and help you out.

[louisgag]

Hi Bruno,

Thank you for the tips. Today the leak doesn't seem to show up. I'm suspecting it may have been some system-side issue, but can't confirm yet.

The modifications I've made consist of code I've previously posted on the forum, they are fairly small changes and will work also in 2.4.x.

1. my embed AMI interface: http://www.cfd-online.com/Forums/ope...tml#post476869
2. my moving wall slip condition: http://www.cfd-online.com/Forums/ope...tml#post509989

Thanks again,


-Louis

[louisgag]

Hello again Bruno,

I thought the problem had disappeared but it isn't so. I suspect it may be linked to the quality of my mesh !

In any case, to give you more details about the modifications I've made to the code,

1. my embed AMI interface: http://www.cfd-online.com/Forums/ope...tml#post476869
is made from OpenFOAM-2.4.x/src/dynamicFvMesh/solidBodyMotionFvMesh/solidBodyMotionFunctions/oscillatingRotatingMotion/oscillatingRotatingMotion.C
which in essence has only one influent modification: I change the angle and origin of the rotation applied.

vector eulerAngles = amplitude_ * sign(omega_) * ( sin(fabs(omega_*t) + initialOffset_*pi ) - sin( initialOffset_*pi ) );

and

vector calcOrigin_ = outterOrigin_ + outterRadius_ * vector (sign(outterOmega_)*cos(fabs(outterOmega_)*t + outterInitialOffset_*pi ), sin(fabs(outterOmega_*t) + outterInitialOffset_*pi), 0);

which I then apply to the original code as

quaternion R(eulerAngles.x(), eulerAngles.y(), eulerAngles.z());
     septernion TR(septernion(calcOrigin_)*R*septernion(-calcOrigin_));

2. my moving wall slip condition: http://www.cfd-online.com/Forums/ope...tml#post509989
is made from OpenFOAM-2.4.x/src/finiteVolume/fields/fvPatchFields/derived/movingWallVelocity/movingWallVelocityFvPatchVectorField.C
where once again the modifications are limited to adding a normal vector

const vectorField nHat(this->patch().nf());

and then modifying the operator

vectorField::operator=(nHat*(nHat &  (Up + n*(Un - (n & Up))) ) + transform(I - sqr(nHat), this->patchInternalField()) );

and also include an extra necessary header file: #include "symmTransformField.H"

I have launched a test case, identical to one with the memory leaks, but with my boundary condition replaced by an official OF one. I'll update this thread once I do or don't observe the memory leak for this test.

Regards,


-Louis

[louisgag]

Hello again Bruno,
after my test of today I can confirm that my boundary condition is not the culprit because the memory leak also occurs when I disable it.
It may be my AMI code, but once again I suspect the coarse mesh I use has a big influence, could that make sense ?
-Louis

[wyldckat]

Hi Louis,

I've taken a look at some of the source code for the two threads you've indicated and I couldn't find anything specific that would imply a memory leak.

My guess is that it's possible that you might have broken something in your OpenFOAM installation? For example, it would be more than enough that you were using a template class from OpenFOAM in your code, which you modified in the OpenFOAM source code, but then you only built with your own libraries.
For example, if you change anything in the class "$FOAM_SRC/OpenFOAM/primitives/Vector" and then only build your own libraries, you are taking a severe risk of having a disconnect in object size between the code that was built into OpenFOAM versus the code you have built into your library. This is because templated code many times isn't an explicit object and is instead built on-a-need-basis.

My suggestions it that you do some in-depth isolate-and-conquer strategy:

1. Create a new OpenFOAM installation in your machine. You can find details instructions on how to keep OpenFOAM versions isolated from each other, on this section: http://openfoamwiki.net/index.php/In...nFOAM_versions
2. Create a simple case that is similar to the one you are working on, but make sure that simple case is using only existing features from OpenFOAM itself. Double-check if this case runs without a memory leak.
3. Now try building your code as independent libraries. Make sure your own classes do not have identical names to the ones that OpenFOAM has got, otherwise you risk duplicate object names and memory problems.
4. Now clone the simple case from step #2 and adapt it to use one or two features from your libraries. Check if it has a memory leak or not.

Sharing the cases you create for #2 and #4 would make it easier to have more people looking into this problem with you.


As for suspecting the coarser mesh: that doesn't make much sense to me... the more cells/faces there are, the larger should be the memory leaks!?


But this reminds me of something: does your mesh fail any checks that are done by checkMesh? You can do a complete check with this command:

checkMesh -allGeometry -allTopology -constant

The other possibility is that the leak begins when the dynamic steps are put into practice and perhaps unwanted mesh distortion is occurring?


The other possibility is if you are using function objects? There is a recent report here: http://www.openfoam.org/mantisbt/view.php?id=1777


The other thing that comes to mind... have you created any special files at any of the folders given by this command:

foamEtcFile -list

Or have you made any modifications to the main file "OpenFOAM/etc/controlDict"?

Best regards,
Bruno

[louisgag]

Hi Bruno,

Thank you for having given a look at the code and your extensive reply.

My guess is that it's possible that you might have broken something in your OpenFOAM installation? [...] This is because templated code many times isn't an explicit object and is instead built on-a-need-basis.

I am using the original OpenFOAM source code with the only modifications being the additional libraries I showed you and which are built separately from the main code.

My suggestions it that you do some in-depth isolate-and-conquer strategy:

1. Create [...]
2. [...]
3. [...]
4. [...]Check if it has a memory leak or not.

Yes, I've tested part of this by disabling my boundary condition. The memory leak was still present. I will attempt to run with a simplified case and the OF standard AMI to see what happens.

Sharing the cases you create for #2 and #4 would make it easier to have more people looking into this problem with you.

Unfortunately, it is difficult for me to share this test case because I am working with confidential data. The errors also seem to be linked to the specifics of the mesh, so I may not see the memory leak on a case where I would have changed the geometries.

But this reminds me of something: does your mesh fail any checks that are done by checkMesh? You can do a complete check with this command:

Yes, the mesh does fail some tests.

Checking geometry...
   [...]
    Face pyramids OK.
 ***Max skewness = 11.32348044206789, 141 highly skew faces detected which may impair the quality of the results
  <<Writing 141 skew faces to set skewFaces
    Coupled point location match (average 0) OK.
 ***Error in face tets: 2185 faces with low quality or negative volume decomposition tets.
  <<Writing 2024 faces with low quality or negative volume decomposition tets to set lowQualityTetFaces
   *Edges too small, min/max edge length = 1.573273801930381e-06 0.5918981366529854, number too small: 38
  <<Writing 38 points on short edges to set shortEdges
  <<Writing 1536174 near (closer than 1.028122838179027e-05 apart) points to set nearPoints
   *There are 41598 faces with concave angles between consecutive edges. Max concave angle = 79.9891645875073 degrees.
  <<Writing 41598 faces with concave angles to set concaveFaces
    Face flatness (1 = flat, 0 = butterfly) : min = 0.3057324420238945  average = 0.9997418578038894
   *There are 172 faces with ratio between projected and actual area < 0.8
    Minimum ratio (minimum flatness, maximum warpage) = 0.3057324420238945
  <<Writing 172 warped faces to set warpedFaces
    Cell determinant (wellposedness) : minimum: 1.857217107564813e-05 average: 13.25278608578823
 ***Cells with small determinant (< 0.001) found, number of cells: 30
  <<Writing 30 under-determined cells to set underdeterminedCells
 ***Concave cells (using face planes) found, number of cells: 487361
  <<Writing 487361 concave cells to set concaveCells
    Face interpolation weight : minimum: 0.0748980829742053 average: 0.4499806164920315
    Face interpolation weight check OK.
    Face volume ratio : minimum: 0.01459454357799709 average: 0.7348028620356964
    Face volume ratio check OK.

Failed 4 mesh checks.

The other possibility is that the leak begins when the dynamic steps are put into practice and perhaps unwanted mesh distortion is occurring?

I've had such a problem in the past but it doesn't seem to be the case now. Only the number of nearPoints, the boundary openness, Max cell openness, and
Max aspect ratio slightly change over time. They however don't reach error values.

The other possibility is if you are using function objects? There is a recent report here: http://www.openfoam.org/mantisbt/view.php?id=1777

That's very interesting. I'm starting a case with function objects disabled (forces and forceCoeffs). This brings me to another question: would you know how I can run the forces and forceCoeffs functions after the case instead of along with the case ?

The other thing that comes to mind... have you created any special files at any of the folders given by this command...

No, nothing other than modifying the bashrc file to point to the proper compilers.

Or have you made any modifications to the main file "OpenFOAM/etc/controlDict"?

Still no.

I will post again when I have looked into the details you pointed out and for which I was not able to process a detailed inspection.

Thank you very much Bruno,


-Louis

[louisgag]

Originally Posted by louisgag

That's very interesting. I'm starting a case with function objects disabled (forces and forceCoeffs). This brings me to another question: would you know how I can run the forces and forceCoeffs functions after the case instead of along with the case ?

Short update: disabling the function objects does not remove the memory leak. It now seems that disabling some of my AMI interface does! I'll investigate.
-Louis

[louisgag]

Originally Posted by louisgag

It now seems that disabling some of my AMI interface does!
-Louis

No, this was also a false hope.

I'm looking into the case which doesn't seem to have the leaks to understand which change may trigger those leaks.

-Louis

[hk318i]

Originally Posted by louisgag

Short update: disabling the function objects does not remove the memory leak. It now seems that disabling some of my AMI interface does! I'll investigate.
-Louis

Unfortunately, I have no clue about your problem but about the function objects as a post-processing you can run execFlowFunctionObjects. I hope you could fix this problem soon.

Good Luck,
Hassan