[gmx-developers] pdb2gmx segmentation fault

[David van der Spoel]

Ran Friedman wrote:
> Hi,
> 
> I have a similar problem (on linux, tried with few PDBs, this has only 1
> chain)
> pdb2gmx -f ~/Proteins/PM_II/PDB/3F9Q.pdb -o prot.gro
> 
> ...
> Processing chain 2 (213 atoms, 213 residues)
> There are 213 donors and 213 acceptors
> There are 67 hydrogen bonds
> Segmentation fault
> ...
> 
> The problem is with the waters. It seems that the program crashes in
> hizzi.c, in set_histp
> (lines: 223-225)
>   for(i=0; (i<natom); ) {
>     if (strcasecmp(*pdba->resinfo[pdba->atom[i].resind].name,"HIS") != 0)
>       i++;
> 
> Apparently *pdba->resinfo[pdba->atom[i].resind].name is not initialised
> and this causes the problem to die. I couldn't get further so far.
> 

It seems that there are problems in pdb2gmx due to it retaining original 
residue numbers. In principle this is a good thing, and this was much 
requested. However, I suspect that your resind is actually larger than 
the number of residues (you could check this in your pdb file). In other 
words, this feature has not been implemented completely consistenly, I 
also found a problem in grompp with a new top file the other day, where 
the peptide had residue number 16, and the solvent had lower residue 
numbers. I'm not really sure how to continue, the code really has to be 
fixed.

A workaround (if this really is the issue in your case) is to run the 
pdb files through editconf first: editconf -f in.pdb -o out.pdb as this 
program will actually renumber atoms and residue...


> Ran.
> 
> Michel Cuendet wrote:
>> Dear David,
>>
>> Thanks for trying to reproduce this annoying SegFault. Yes, it works
>> fine with the 4.0.x releases, and it seems that the problem appeared
>> when the new residue numbering was introduced. I however need the
>> development version of gmx, because I'm testing the CMAP
>> implementation with charmm27.
>>
>> I was really optimistic when I read your reply, so I immediately
>> downloaded the GIT version of today, compiled on the machines at hand,
>> and tested again with 2GUO_nowat.pdb.
>>
>> Alas !
>>
>> osx_gcc4.0.1 shared      : OK
>> i686_gcc4.2.4 shared     : SegFault     (chain A)
>> i686_gcc4.2.4 static     : SegFault     (chain A)
>> em64t_gcc3.4.6 static    : SegFault     (chain B)
>>
>> This looks like a nasty, difficult to reproduce bug... It's annoying,
>> because I would need to produce topologies on a Linux machine, not on
>> my mac...
>>
>> Thanks or your help,
>>
>> Michel
>>> I am now doing this using the latest git source, but it works fine on
>>> my Mac.
>>> However, with a slightly older develop code it fails. With the .4.0.x
>>> release tit works fine though.
>>> It seems to be a temporary bug that was resolved again.
>>>
>>> Plz upgrade...
>>>   
>> _______________________________________________
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>> Please don't post (un)subscribe requests to the list. Use the www
>> interface or send it to gmx-developers-request at gromacs.org.
>>
> 
> 


-- 
David van der Spoel, Ph.D., Professor of Biology
Molec. Biophys. group, Dept. of Cell & Molec. Biol., Uppsala University.
Box 596, 75124 Uppsala, Sweden. Phone:	+46184714205. Fax: +4618511755.
spoel at xray.bmc.uu.se	spoel at gromacs.org   http://folding.bmc.uu.se