Archive from user: Tyler Reddy Erik asked me to open an issue related to my observations below (pasted from my original email). I’ll endeavour to provide additional information as requested. As reproducing the issue requires a rather large file I haven’t included a ‘minimum failing example’ yet, but could probably cook up a non-confidential system / set of files with a bit of effort. For now, I’ll provide the mdrun traceback and the email description sent to Erik. Traceback: 272 Program gmx mdrun, VERSION 5.1.2 273 Source code file: /gromacs-5.1.2/src/gromacs/utility/smalloc.c, line: 227 274 275 Fatal error: 276 Not enough memory. Failed to realloc -8589934592 bytes for nlist->jjnr, nlist->jjnr=9988e010 277 (called from file /gromacs-5.1.2/src/gromacs/mdlib/nbnxn_search.c, line 3392) 278 For more information and tips for troubleshooting, please check the GROMACS 279 website at http://www.gromacs.org/Documentation/Errors 280 ------------------------------------------------------- 281 : Cannot allocate memory ------------------------------------------------------------------------ Email Description of Issue: I’ve observed something interesting about the free energy calculation behaviour in GROMACS when extremely large numbers of particles are coupled (I have a legitimate use for this application). In short, ramping the lambda value from 0 to 1 for N particles causes an increase in the amount of physical memory (RAM) consumed by GROMACS. As you enter the millions of coupled particles (which no normal end user would ever do) the memory footprint appears to exceed 128 GB of RAM, which is the most I have access to. Please see a brief description of my measurements below. I am happy to provide additional details regarding some aspects of the runs if you think you can help me get this running. Unfortunately, coupling separately isn’t really an option for me. Is this basically a no-go in GROMACS for now? That would be good to know! This is basically a scaling up of the Alchembed technique (http://pubs.acs.org/doi/abs/10.1021/ct501111d?src=recsys) for a different purpose. ------------------------------------------------------------------------ The following observations using GROMACS 5.1.2 and lambda-phasing simulations (i.e., alchembed-style) on a node with 128 GB RAM suggest that I am actually hitting a physical memory ceiling: coupling 1584 CG particles (132 POPE residues) = ok coupling 19,054 CG particles (1361 PRPE residues) = ok coupling 40,843 CG particles (3713 DPSM residues) = ok coupling 201,227 CG particles (15479 RUPE residues) = ok coupling 436,887 CG particles (39717 RPSM residues) = ok coupling 1,009,208 CG particles (126151 RHOL residues) = Fatal Error: Not Enough memory coupling full SYSTEM (>3M particles) = Fatal Error: Not Enough memory coupling matching topology / full system with only 3 copies of each residue = ok \[residue names starting with R are position restrained, but forces generated are actually still sufficient to displace them\] I’m not really open to doing the alchemical phasings for each molecule type separately unless it is the only (i.e, last) resort, for various reasons. Full system phasing clearly works at smaller system sizes. Other suggestions to reduce the memory footprint? Does this surprise you? One doesn’t normally do free energy calculations on millions of particles (right?), so it may be that minimizing the memory footprint in that range hasn’t been a priority. ————— *(from redmine: issue id 2014, created on 2016-07-22 by gmxdefault, closed on 2017-01-20)* * Relations: * relates #742 * relates #2010 * relates #1665 * Changesets: * Revision c244483982dfdcf2d721b460ba33c1cce53fccba by Berk Hess on 2016-08-15T18:04:34Z: ``` Reduce FE pair-list memory usage Refs #2014. Change-Id: Ia8bbc55eed7e3590e6944127ab94dd41f475e6a7 ``` * Uploads: * [alchembed_round_1.log](/uploads/6d6574a3571ca7a3ef8eaaa7b4cce134/alchembed_round_1.log) * [run_files_lambda_growth.tar](/uploads/89f01c9c037c2b562df8a90aa54f3cdd/run_files_lambda_growth.tar)