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
[email protected] http://folding.bmc.uu.se/
--
gmx-users mailing list [email protected]
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to [email protected].
Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
