Segmentation fault when reading VMD PDB

[Anonymous]

All,

I receive this output when trying to create a pose from a pdb file I outputted using VMD. Initially, it is giving me an error about “HSD” residues, which I rename to “HIS”. Does anyone know what might trigger a segmentation fault at this particular location?

…
…
…
core.pack.pack_missing_sidechains: packing residue number 375 because of missing atom number 8 atom name CD1
core.pack.pack_missing_sidechains: packing residue number 377 because of missing atom number 8 atom name CD1
core.pack.pack_missing_sidechains: packing residue number 385 because of missing atom number 8 atom name CD1
core.scoring.etable: Starting energy table calculation
core.scoring.etable: smooth_etable: changing atr/rep split to bottom of energy well
core.scoring.etable: smooth_etable: spline smoothing lj etables (maxdis = 6)
core.scoring.etable: smooth_etable: spline smoothing solvation etables (max_dis = 6)
core.scoring.etable: Finished calculating energy tables.
core.io.database: Database file opened: software/lib/pyrosetta/minirosetta_database/pdb_pair_stats_fine
core.io.database: Database file opened: software/lib/pyrosetta/minirosetta_database/P_AA
core.io.database: Database file opened: software/lib/pyrosetta/minirosetta_database/P_AA_n
core.io.database: Database file opened: software/lib/pyrosetta/minirosetta_database/P_AA_pp
core.io.database: Database file opened: software/lib/pyrosetta/minirosetta_database/Rama_smooth_dyn.dat_ss_6.4
core.io.database: Database file opened: software/lib/pyrosetta/minirosetta_database/scoring/score_functions/disulfides/fa_SS_distance_score
core.io.database: Database file opened: software/lib/pyrosetta/minirosetta_database/scoring/score_functions/disulfides/fa_CaCbS_angle_score
core.io.database: Database file opened: software/lib/pyrosetta/minirosetta_database/scoring/score_functions/disulfides/fa_CbSSCb_dihedral_score
core.scoring.dunbrack: Dunbrack library took 0.04 seconds to load from binary
Segmentation fault

Thanks.

[Anonymous]

Unrecognized residues (like HSD for HIS) should lead to “unrecognized residue” errors, not segfaults.

The list of possible flaws in PDBs that can cause segfaults is both long and unenumerated. The last time someone had an error, it was because all their occupancies were 0 – if your whole occupancy column is 0 for all residues it is likely to cause this problem.

Try:
A) compile in debug mode; run in debug mode (or even in the debugger), post the error then (it’s 99% chance an uninformative vector overrun, requiring the debugger)

post the PDB here (there’s a file attach option) and I’ll look for obvious flaws.

EDIT: I didn’t realize this was in the pyrosetta forum – I guess you can’t do debugging?

[Anonymous]

Okay, I’ll check occupancies. Thanks.

[Anonymous]

I stepped away from this problem for bit, but finally managed to get something working. For those interested there are two solutions I found for inputting a psfgen’d PDB file into Rosetta (directly this results in an error, hence the post title). I am new to this software and file format, so perhaps this already well known.

Problem: CHARMM parameter file used in PSFGEN contains atom aliases that are not readable by Rosetta.

Solutions:

1. The first is just a brute force approach and the first thing I tried: Strip hydrogens from the PDB. Rosetta identifies residues well enough (at least for my proteins), but you lose configurational information of the sidechains.

2. Compare the atom naming from a Rosetta generated PDB with a CHARMM topology file. There are several differences here and you can write a simple script to convert the names of these atoms to Rosetta-friendly versions. For example: HH11 (CHARM) is 1HH1 (Rosetta), as well as delta carbon on ILE and terminal oxygens.

Hope this helps anyone with the same issues.

[Anonymous]

You could examine the effects of -randomize_missing_coords false (default) and -pack_missing_sidechains false (not default). I don’t know what Rosetta will do to the missing/misnamed atoms if it’s not allowed to repack them…

[Anonymous]

As a general rule, stripping all hydrogens from a PDB will not affect the quality of Rosetta results generated with that PDB as a starting point (in other words, Rosetta usually replaces them anyway).

[Anonymous]

Okay.

For me I think two things were going on:

1. A few of the hydrogen names were causing a segmentation fault, for whatever reason.
2. One of the atom types in the PDB was triggering a repacking of some of the sidechains (C or O) because it couldn’t be identified. I need to be sure that the structure of what I’m loading in the pose is maintained, at least until I invoke a particular protocol.

So far scrubbing the PDB seems to be working but may not be the most efficient solution.

[Author]

Posts