[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Memory leak in espresso
Re: Memory leak in espresso
Thu, 20 Feb 2020 21:12:51 +0100
Mozilla/5.0 (X11; Linux i686; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
I ran a polymer simulation with a hat potential and tabulated bonds to
reproduce your system, and was able to measure a memory leak when the
OpenGL visualizer was active. This is reproducible with other types of
simulation. The leak rate is 12 megabyte/minute, which is substantial.
Depending on the polymer parameters, I measured between 10 MB/min to 14
MB/min, which is of the same order of magnitude as the 8 MB/min you
measured on your machine.
Thanks for reporting this issue. I've opened a ticket on GitHub:
On 2/20/20 12:06 PM, David Power wrote:
Sorry for the late reply. I figured out that I was only seeing the
memory leak on my machine when the visualizer
was enabled. I turned visualization off and the leak went away.
On Sun, 16 Feb 2020 at 16:35, Jean-Noël Grad <address@hidden
system.set_random_state_PRNG() sets and warms up the global Mersenne
Twister random number generator. It is used to make espresso
deterministic. Since espresso 4.0, a lot of effort went into replacing
the global Mersenne Twister generator by local Philox generators. In
espresso 4.1, very few features still use the global Mersenne Twister,
for example the NPT thermostat and diamond polymer. In the upcoming
espresso 4.2.0 release, the global Mersenne Twister has been completely
Thanks for the files you attached. Unfortunately, the espresso script
seems to be missing a custom Python module called Molecule. I was not
able to run your example. Could you please generate a minimal working
example (MWE), where non-relevant parts of the script are removed? For
instance, the numpy data analysis in the main_thread() function is
unlikely to be part of the problem, and the exclusion-list logic has no
associated data field in file 1n5u.struct. The Molecule package also
seems unnecessary in that MWE, since it is only a convenience
read 3D coordinates from a file and set up espresso bonded interaction
objects. In general, the shorter the MWE, the quicker it is for us to
figure out which part of the C++ code needs to be investigated.
With best regards,
On 1/16/20 2:58 PM, David Power wrote:
> I'm on the latest 4.1 branch from git. Espresso runs along fine,
> amount of available ram that's free on my system slowly starts to
> decrease. When it gets to 0 espresso crashes and all the ram
> again. I've attached the script I used to capture the amount of
> available memory on my machine and a sample output showing the
> This is an issue as some of my simulations take quite a while to
> generate the data I need.
> I've attached my python script and associated data files if want
> and reproduce the issue. Please let me know if there is anything
> you need from me.