[gmx-users] memory problem of g_hbond?

[Mark Abraham]

On 23/05/2011 7:23 PM, Baofu Qiao wrote:
>
> Thanks a lot, Erik!
>
> But could you specify how to build the index of water in certain 
> region, say 0<z<2nm? It seems that make_ndx can't do that.

g_select can make such a selection, but you will have to script any 
approach using its output to build (say) a pseudo-trajectory of the 
water molecules that satisfy that criterion. However before you do that, 
surely the hydrogen bonding matrix would lose meaning if molecules were 
allow to diffuse out of the region treatrd by the matrix.

Mark

>
>
>
> On 05/23/2011 11:05 AM, Erik Marklund wrote:
>> Baofu Qiao skrev 2011-05-23 10.47:
>>> Hi all,
>>>
>>> Very recently, I meet a problem when using g_hbond (gromacs 4.5.3 
>>> with the bugfixed)
>>> *********************************
>>> Select a group: Selected 1: 'SOL'
>>> Select a group: Selected 1: 'SOL'
>>> Calculating hydrogen bonds in SOL (98280 atoms)
>>> Found 32760 donors and 32760 acceptors
>>> *Segmentation fault*
>>> *********************************
>>> I check the code of gmx_hbond.c. The problem comes from the function 
>>> of "mk_hbmap". However, g_hbond doesn't complain  
>>> "gmx_fatal(FARGS,"Could not allocate enough memory for hbmap")' 
>>> while giving the "Segmentation fault". My first guess is 1) the 
>>> function doesn't work correctly; 2) there is no enough memory for 
>>> 32760 donors and 32760 acceptors.
>>>
>>> What I really want to calculate is the HB correlation function is 
>>> some slab structure of thickness of about 3ns, where there is only 
>>> ~3000 waters. Can someone give me some suggestions? Thanks a lot!
>>>
>>> best regards,
>>> Baofu Qiao
>>>
>> That sounds like a memory problem indeed, and it could be outside the 
>> control of g_hbond. From the manpages of malloc:
>>
>> "By default, Linux follows an  optimistic  memory  allocation  
>> strategy. This  means  that  when malloc() returns non-NULL there is 
>> no guarantee that the memory really is available. This is a really 
>> bad bug."
>>
>> g_hbond checks for NULL pointers to decide whether snew() was 
>> successful or not. Hence the menetioned bug could be the culprit. 
>> That said, the hbmap of your system requires 32760^2 pointers (> 8 Gb 
>> on 64 bit systems) that in turn points to existence arrays with size 
>> that scales with trajectory length. Hence you will easily run out of 
>> memory. I suggest that you build the acf for a subset of your system, 
>> e.g. 1000 waters. The acf will converge slower, but have the same 
>> features. You can do this many times and take an average for better 
>> statistics.
>>
>> Cheers,
>>