[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Memory leak in espresso

From: Jean-Noël Grad
Subject: Re: Memory leak in espresso
Date: Thu, 20 Feb 2020 21:12:51 +0100
User-agent: 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:

Best regards,

On 2/20/20 12:06 PM, David Power wrote:
Hi Jean,

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 <mailto:address@hidden>> wrote:


    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
    removed (

    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
    wrapper to
    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,
    but the
     > 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
    become free
     > again. I've attached the script I used to capture the amount of
     > available memory on my machine and a sample output showing the
     > decreasing.
     > 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
    to try
     > and reproduce the issue. Please let me know if there is anything
     > you need from me.
     > Thanks,
     > David

reply via email to

[Prev in Thread] Current Thread [Next in Thread]