Segmentation fault when reading VMD PDB

Member Site › Forums › PyRosetta › PyRosetta – General › Segmentation fault when reading VMD PDB

Viewing 3 reply threads
  • Author
    Posts
    • January 3, 2011 at 3:14 pm #728
      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.

      • January 3, 2011 at 3:24 pm #4792
        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)

          B) 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?

          • January 3, 2011 at 3:51 pm #4793
            Anonymous

              Okay, I’ll check occupancies. Thanks.

          • March 7, 2011 at 3:59 pm #5129
            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.

            • March 8, 2011 at 7:09 pm #5133
              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…

              • March 7, 2011 at 10:06 pm #5131
                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).

                • March 7, 2011 at 11:11 pm #5132
                  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
                Viewing 3 reply threads
                • You must be logged in to reply to this topic.