<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Baofu Qiao skrev 2011-05-23 10.47:
    <blockquote cite="mid:4DDA1F16.2010705@gmail.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      Hi all,<br>
      <br>
      Very recently, I meet a problem when using g_hbond (gromacs 4.5.3
      with the bugfixed)<br>
      *********************************<br>
      Select a group: Selected 1: 'SOL'<br>
      Select a group: Selected 1: 'SOL'<br>
      Calculating hydrogen bonds in SOL (98280 atoms)<br>
      Found 32760 donors and 32760 acceptors<br>
      <b>Segmentation fault</b><br>
      *********************************<br>
      I check the code of gmx_hbond.c. The problem comes from the
      function of "mk_hbmap". However, g_hbond doesn't complain&nbsp;
      "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.<br>
      <br>
      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!<br>
      <br>
      best regards,<br>
      Baofu Qiao<br>
      <br>
    </blockquote>
    That sounds like a memory problem indeed, and it could be outside
    the control of g_hbond. From the manpages of malloc:<br>
    <br>
    "By default, Linux follows an&nbsp; optimistic&nbsp; memory&nbsp; allocation&nbsp;
    strategy. This&nbsp; means&nbsp; that&nbsp; when malloc() returns non-NULL there is
    no guarantee that the memory really is available. This is a really
    bad bug."<br>
    <br>
    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 (&gt;
    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.<br>
    <br>
    Cheers,<br>
    <pre class="moz-signature" cols="72">-- 
-----------------------------------------------
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
<a class="moz-txt-link-abbreviated" href="mailto:erikm@xray.bmc.uu.se">erikm@xray.bmc.uu.se</a>    <a class="moz-txt-link-freetext" href="http://folding.bmc.uu.se/">http://folding.bmc.uu.se/</a>
</pre>
  </body>
</html>