I agree about the hard limit. There is a limit to how much useful reordering we are ever going to do on the trace. Shall we set a default value for lazy_max_trace_length? Is 100 a good number? On Wed, 29 Apr 2015 at 10:00 Mitchell, Lawrence < lawrence.mitchell@imperial.ac.uk> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 29/04/15 08:59, Hiroe Yamazaki wrote:
Dear all,
I am experiencing a memory leak in our vertical slice model and wonder if there is any possibility of leaking memory associated with .assign(). Here I have a stand-alone code with the same function spaces and variable settings we use in the slice model:
https://bitbucket.org/hyamazak/test_files/src/f455e7e68722c9264845a8426ba91c...
What I do here is just doing
new.vars += Deltavars old.vars.assign(new.vars)
over and over again, and I see a constant increase of the memory usage both on my Linux and Macbook. I believe new.vars += Deltavars is not the source of leaking and wonder if there is any problem with doing old.vars.assign(new.vars).
Do let me know if you have any ideas,
OK, I observe the same memory leak. Here's what's going on:
PyOP2 is running in lazy evaluation mode, which means that no computation actually occurs until you ask to look at the resulting data (perhaps by writing it to a file, or dropping into a solve). Instead, we store an "execution trace" which remembers the sequence of computations you want to do. By default this execution trace is unbounded in length, so, since you never look at the answer in the above code, we end up creating a trace of length 100000. This is the cause of the memory leak.
Arguably we should have a limit on the trace length. Can you try setting the following parameter to see if your leak goes away?
parameters["pyop2_options"]["lazy_max_trace_length"] = 100
Cheers,
Lawrence
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQEcBAEBAgAGBQJVQJ2DAAoJECOc1kQ8PEYvr8gIALFwcyFV3XIcK+S3uzKDYkZ+ aGR5EprrM1dvn2U4nS9eGTm52a9fxSYaZq3H++JfwdfZ0J/XWCFxfHkwAoCxmWRC 23m+sohS5om8AjhmW4hU8S2LK6RQknDiKxt14IUE5nZXcf5aIvFF6/l3/pclptvg OBorwxDk6LqHS17/4UOhIMjkcRLEppZ3TuH/NLqo7vftgnclf77ONjWfFP8y4DIh 6AMPmcbx1WXLUZ+UIB7llMdaNgsH98Ei7v+hlvQnrdMxFAm4AbplAoVW6PGeTJ2z h29W6LqVddrWaE7QMp2N+r732yY/3D7Pmjk0Iw5mO2uyYkCFrBVUUxUI+e6tqs4= =STEw -----END PGP SIGNATURE-----
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29/04/15 10:11, David Ham wrote:
I agree about the hard limit. There is a limit to how much useful reordering we are ever going to do on the trace. Shall we set a default value for lazy_max_trace_length? Is 100 a good number?
I think 100 ought to be enough. Lawrence -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVQLK5AAoJECOc1kQ8PEYvDYUH/0ZWKielLNHVcaCDmSjv11l/ f/P/bv5JGakGrcgQlIjyBYFYuCmJrSLFAKPJsvfzPXzxlsGYd0gZJV3zu+dQat70 2HptjvmKGtiabf3flWRjKRDgawtEWI2dYpQsLHRttluk4wgKSEWn70TcRvjwWH+A owJj6NRy7yK/ywumLgyVwbyevmSTNHAZFooL4jAweAbugVfF0tKGAQMr5uHaE9X3 cXDXymcC8E+JxNEKRlYNpZxMQt6tmzcvLQX9EYWUTaYeQCLsWz4Dx85wEwXDQCbS MvwMFT6vhfufB3dRi9595+6bwex+SF6ThZCz/KaoQCXNm50JbZuD4DbzqojzG4Q= =M2d3 -----END PGP SIGNATURE-----
participants (2)
- 
                
                David Ham
- 
                
                Lawrence Mitchell