[gmx-users] memory problem of g_hbond?

[Erik Marklund]

Hi,

Try g_select. I've never used it myself, so I can't say exactly what 
it's capable of. Or use a gro file to extract the molecules that are 
fulfil your criterion. ndx-files are just sets of atom indices in rather 
free ascii format, so making them from gro files with standard *nix 
tools is pretty simple.

Erik

Baofu Qiao skrev 2011-05-23 11.23:
>
> 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.
>
>
>
> 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,
>>


-- 
-----------------------------------------------
Erik Marklund, PhD student
Dept. of Cell and Molecular Biology, Uppsala University.
Husargatan 3, Box 596,    75124 Uppsala, Sweden
phone:    +46 18 471 4537        fax: +46 18 511 755
erikm at xray.bmc.uu.se    http://folding.bmc.uu.se/