[gmx-users] problem in hdb file
Mark.Abraham at anu.edu.au
Tue Feb 19 16:02:43 CET 2008
Zuzana Benkova wrote:
Thanks for the clear description of what you are attempting to do.
> Eth 2
> 2 6 H1 C1 C2 +C1
> 2 6 H2 C2 C1 -C2
> At this point I have to note that the presence of the last control atoms
> in this file has not influenced the process.
They should - this is behaviour that the .hdb file should implement,
since it's analogous to adding an amino hydrogen to a peptide residue.
The problem that is occurring below is occurring at or before the
attempt by pdb2gmx to interpret these lines, so it's not too surprising
you don't observe any effect with the last control atom. You shouldn't
see any for the other control atoms either :-)
> Sorting it all out...
> Opening library file ffoplsaa.hdb
> Error in hdb file: nah = 41
> line = ''
> Opening library file ffoplsaa-n.tdb
> Opening library file ffoplsaa-c.tdb
> Back Off! I just backed up topol.top to ./#topol.top.8#
> Processing chain 1 (6 atoms, 3 residues)
> There are 0 donors and 0 acceptors
> There are 0 hydrogen bonds
> Checking for duplicate atoms....
> Opening library file
> 5 out of 5 lines of specbond.dat converted succesfully
> N-terminus: Eth
> C-terminus: Eth
> Segmentation fault
> Could you specify what means Error in hdb file: nah = 41
> line = '' and what is the problem with segmentation.
The error message is a bit cryptic. "nah" is an index variable that
meant that pdb2gmx had a problem reading what it thought was a potential
42nd residue hydrogen database entry. "line = ''" suggests that it found
a blank line. Probably the file format is intolerant of "spare" blank
lines, even at the end. The standard ffoplsaa.hdb only has about 35
entries, so clearly yours has been modified by more than just your one
residue above. If you can't see any problems in your copy of this file,
you'll need to provide us the last 50-odd lines of your ffoplsaa.hdb
file. Guessing wildly, you might have a problem with DOS vs Unix line
endings if you've edited this file on a Windows machine. You might try
the dos2unix utility to be sure this isn't the problem.
Segmentation faults refer to segmentation of memory in the computer.
When a programmer errs, or the user inputs data that the programmer
didn't anticipate but attempts to act on anyway (i.e. the programmer
errs :-)) then sometimes the program attempts to store/access data
to/from a memory location where that's not allowed. C programs tend to
die ungracefully at this point with the above message. GROMACS is
actually very good at not doing this without outputting something else
helpful on the way.
Thus, I think your .hdb file formatting is breaking pdb2gmx somehow. The
simplest solution is to keep pdb2gmx happy :-)
More information about the gromacs.org_gmx-users