[gmx-users] problem with profiling grompp using callgrind

Berk Hess gmx3 at hotmail.com
Tue May 9 09:52:15 CEST 2006




>From: David van der Spoel <spoel at xray.bmc.uu.se>
>Reply-To: Discussion list for GROMACS users <gmx-users at gromacs.org>
>To: Discussion list for GROMACS users <gmx-users at gromacs.org>
>Subject: Re: [gmx-users] problem with profiling grompp using callgrind
>Date: Tue, 09 May 2006 09:36:36 +0200
>
>Berk Hess wrote:
>>
>>>
>>>this seems more like a bug that is dependent on memory allocation. I'm no 
>>>aware of any known bug in grompp. Maybe you can recompile all of grompp 
>>>with the -g flag and retry. For memory debugging simpler tools like 
>>>Electric Fence usually work. For profiling, you'd probably want to 
>>>profile mdrun, although there is a bugzilla about grompp being 
>>>excessively slow for large systems with OPLS and dummies.
>>
>>grompp with OPLS is excessively slow in general, because it generates
>>LJ parameters for all ~1000^2 atom type combinations.
>>If you have little memory it will start swapping to disk.
>
>the real problem is in the dummy code, I've done some profiling and there 
>are quite a few nested loops there. It's a low priority bug as far as I'm 
>concerned, but it's in bugzilla so it will get fixed some time.

That looks like a more serious problem.

But the LJ parameter calculation is also annoying.
I have some free-energy simulations where each OPLS atom type
has an zero LJ equivalent so the LJ matrix is ~2000^2.
grompp allocates 600 MB and my machine with 1 GB of physical memory
and several tasks gets unworkable for several minutes.
I just tested before sending this mail and grompp actually crashed
as it could not allocate enough memory.
Generating the 1-4 parameters seems to take the most time,
probably this causes the most memory access.
On a machine with more memory or less tasks the same system
runs through grompp in a few seconds.

Berk.





More information about the gromacs.org_gmx-users mailing list