You are here

Surface Docking Application Crash

12 posts / 0 new
Last post
Surface Docking Application Crash
#1

Hello,

(New user to Rosetta, so I apologize if this is the wrong place to post this or a silly question)

I am trying to use the Surface Docking application (https://www.rosettacommons.org/docs/latest/application_documentation/docking/surface-docking) to dock a protein to a crystal surface using only a fasta sequence file.

I start by making fragments (which I believe are required by surface_docking) with the fragment_picker application (https://www.rosettacommons.org/manuals/archive/rosetta3.4_user_guide/dc/d10/app_fragment_picker.html)  using the following flags file:
-in::path::database             path/to/database
-in::file::vall                 /path/to/vall.apr24.2008.extended.gz
-in::file::fasta                        file.fasta.txt
-out::file::frag_prefix         frags
-frags::describe_fragments      frags.fsc
-frags::frag_sizes              9 3

I use the command "fragment_picker.linuxgccrelease @flags" and this proceeds without error. Then I run the surface_docking application. 

Here I am using the following flags file with the command "surface_docking.linuxgccrelease @flags": 

-database /path/to/database/
-s input/file.pdb
-in:file:frag9 input/file.9mer
-in:file:frag3 input/file.3mer
-in:file:surface_vectors input/file.surf
-nstruct 5

This gives the following error:

> protocols.SurfaceDocking.SurfaceDockingProtocol: Loading Fragment 9:

> Open failed for file:

> ERROR:: Exit from: src/core/fragment/ConstantLengthFragSet.cc line: 155

This seems to indicate some kind of problem with the fragment files, but I don't know what the issue is. I would like to avoid using the Robetta server for fragement generation as I need to do this relatively quickly. I have also tried the fragment_picker demo and the surface_docking demo, which both completed successfully, so it is not an installation issue. The link to the fragement_picker tutorial also appears to be broken (https://www.rosettacommons.org/demos/latest/create/tutorials/denovo_structure_prediction/tutorial%20for%20fragment%20picking)

Any hep would be appreciated.

Thanks,

Dan

Category: 
Post Situation: 
Sat, 2017-09-02 18:32
dkozuch

Welcome, this is the correct place to post, and it's not a silly question.

It looks like it's not recognizing the -in:file:frag9 option for some reason. (If there was some formatting issue with the input/file.9mer file, it should be printing that filename on the "Open failed for file:" line.) I'm not sure why that is. One possibilility is that there's invisible character issues in the options file. Try running  the `dos2unix` application on your surface docking flags file and see if that helps. If it doesn't, try putting all the options on the commandline, rather than in an option file. If worse comes to worse, try retyping the options file from scratch (rather than copy/paste).

 

By the way, I'm slighly concered by "dock a protein to a crystal surface using only a fasta sequence file" -- the surface docking application assumes that you already have a folded protein structure in approximately the correct conformation to bind the surface. It doesn't have the sampling to take something like an extended protein structure (or just a fasta file) and fold the protein on the surface.

If you don't have the structure of the folded protein, you need to first make a model of the folded protein with comparative modeling (preferred, if possible) or ab initio, and *then* dock the model (or multiple models)  to the surface..

 

Mon, 2017-09-04 10:26
rmoretti

Thanks for your response. I finally determined that it was actually the file names of the fragments (frags.200.9mer, frags.200.3mer) that was causing the problem. Once I renamed the files to "9mers" and "3mers" the program did not throw that error. There must be something particular about haveing two "." in the name.

Unfortunately, surface_docking.linuxgccrelease did throw a segmentation fault shortly after (shown below). Is there a common error that leads to this kind of crash?

Thanks,

Dan

 

protocols.SurfaceDocking.SurfaceDockingProtocol: Setting up classic abinitio
protocols.SurfaceDocking.SurfaceDockingProtocol: Loading Fragment 9:
core.fragments.ConstantLengthFragSet: finished reading top 200 9mer fragments from file input/9mers
protocols.SurfaceDocking.SurfaceDockingProtocol: Loading Fragment 3:
core.fragments.ConstantLengthFragSet: finished reading top 200 3mer fragments from file input/3mers
protocols.SurfaceDocking.CentroidRelaxMover: CentroidRelaxMover Constructor Called
protocols.SurfaceDocking.CentroidRelaxMover: Setting Defaults
basic.io.database: Database file opened: scoring/score_functions/EnvPairPotential/env_log.txt
basic.io.database: Database file opened: scoring/score_functions/EnvPairPotential/cbeta_den.txt
basic.io.database: Database file opened: scoring/score_functions/EnvPairPotential/pair_log.txt
basic.io.database: Database file opened: scoring/score_functions/EnvPairPotential/cenpack_log.txt
basic.io.database: Database file opened: scoring/score_functions/SecondaryStructurePotential/phi.theta.36.HS.resmooth
basic.io.database: Database file opened: scoring/score_functions/SecondaryStructurePotential/phi.theta.36.SS.resmooth
Segmentation fault

Wed, 2017-09-06 15:18
dkozuch

Unfortunately, there really isn't a single common reason why you might get a Segmentation Fault - a SegFault is basically saying that Rosetta encountered a condition that the programmers didn't anticipate.

To debug this, the best approach is to recompile Rosetta in debug mode (so use "mode=debug" instead on "mode=release" in the scons.py command). If you re-run the command that failed with surface_docking.linuxgccdebug instead of surface_docking.linuxgccrelease, hopefully there should be additional diagnostics which are run, which may show what the issue is.

If surface_docking.linuxgccdebug still gives you a Segmentation fault, the next step would be to run it under the `catchsegv` command (so `catchsegv surface_docking.linuxgccdebug ....`), which can catch the segmentation fault, and print some information about where the segmentation fault happened.  This is not necessarily illuminative by itself, but if you post it here, it may help us track down where the issue is coming from.

Wed, 2017-09-06 15:53
rmoretti

Okay, I ran it in debug and I didn't get segfault, but I don't quite understand the error that was thrown after running surface_docking.linuxgccdebug (shown below).  From my limited understanding I guess an input was of the wrong variable type, but I have no idea how to remedy that. Any help would again be appreciated.

Thanks,

Dan

...

core.fragments.ConstantLengthFragSet: finished reading top 200 9mer fragments from file input/9mers
protocols.SurfaceDocking.SurfaceDockingProtocol: Loading Fragment 3:
core.fragments.ConstantLengthFragSet: finished reading top 200 3mer fragments from file input/3mers
protocols.SurfaceDocking.CentroidRelaxMover: CentroidRelaxMover Constructor Called
protocols.SurfaceDocking.CentroidRelaxMover: Setting Defaults
basic.io.database: Database file opened: scoring/score_functions/EnvPairPotential/env_log.txt
basic.io.database: Database file opened: scoring/score_functions/EnvPairPotential/cbeta_den.txt
basic.io.database: Database file opened: scoring/score_functions/EnvPairPotential/pair_log.txt
basic.io.database: Database file opened: scoring/score_functions/EnvPairPotential/cenpack_log.txt
basic.io.database: Database file opened: scoring/score_functions/SecondaryStructurePotential/phi.theta.36.HS.resmooth
basic.io.database: Database file opened: scoring/score_functions/SecondaryStructurePotential/phi.theta.36.SS.resmooth
...
surface_docking.linuxgccdebug: src/utility/backtrace.hh:162: bool print_backtrace_NR(const char*): Assertion `false' failed.
Got some signal... It is:6
Process was aborted!
 

Wed, 2017-09-06 19:34
dkozuch

The gobbledygook towards the end of the tracer output (that it looks like you elided with the "..."  between "phi.theta.36.SS.resmooth" and "surface_docking.linuxgccdebug") is actually what  is needed in order for me to get a better sense of where the error is. 

Thu, 2017-09-07 08:00
rmoretti

My bad, here it is:

 

basic.io.database: Database file opened: scoring/score_functions/EnvPairPotential/env_log.txt
basic.io.database: Database file opened: scoring/score_functions/EnvPairPotential/cbeta_den.txt
basic.io.database: Database file opened: scoring/score_functions/EnvPairPotential/pair_log.txt
basic.io.database: Database file opened: scoring/score_functions/EnvPairPotential/cenpack_log.txt
basic.io.database: Database file opened: scoring/score_functions/SecondaryStructurePotential/phi.theta.36.HS.resmooth
basic.io.database: Database file opened: scoring/score_functions/SecondaryStructurePotential/phi.theta.36.SS.resmooth
home/programs/rosetta_src_2017.08.59291_bundle/main/source/build/src/debug/linux/3.10/64/x86/gcc/4.8/default/libprotocols.6.so(print_backtrace(char const*)+0x3e) [0x2b7529e49e29]
home/programs/rosetta_src_2017.08.59291_bundle/main/source/build/src/debug/linux/3.10/64/x86/gcc/4.8/default/libprotocols.6.so(print_backtrace_NR(char const*)+0x18) [0x2b7529e49f9a]
home/programs/rosetta_src_2017.08.59291_bundle/main/source/build/src/debug/linux/3.10/64/x86/gcc/4.8/default/libprotocols_e.5.so(utility::vectorL<1l, std::pair<int, int>, std::allocator<std::pair<int, int> > >::operator[](unsigned long)+0x35) [0x2b752aeba7a5]
home/programs/rosetta_src_2017.08.59291_bundle/main/source/build/src/debug/linux/3.10/64/x86/gcc/4.8/default/libcore.2.so(core::kinematics::FoldTree::partition_by_jump(int, ObjexxFCL::FArray1D<bool>&) const+0x7f) [0x2b753b48763d]
home/programs/rosetta_src_2017.08.59291_bundle/main/source/build/src/debug/linux/3.10/64/x86/gcc/4.8/default/libprotocols.3.so(protocols::geometry::centroids_by_jump(core::pose::Pose const&, unsigned long, numeric::xyzVector<double>&, numeric::xyzVector<double>&, utility::vector1<bool, std::allocator<bool> >)+0xb0) [0x2b7533297847]
home/programs/rosetta_src_2017.08.59291_bundle/main/source/build/src/debug/linux/3.10/64/x86/gcc/4.8/default/libprotocols.3.so(protocols::geometry::centroids_by_jump(core::pose::Pose const&, unsigned long, numeric::xyzVector<double>&, numeric::xyzVector<double>&)+0x91) [0x2b753329772e]
home/programs/rosetta_src_2017.08.59291_bundle/main/source/build/src/debug/linux/3.10/64/x86/gcc/4.8/default/libprotocols_b.5.so(protocols::surface_docking::SurfaceDockingProtocol::setup_slide_movers(core::pose::Pose const&)+0xb8) [0x2b752cd3a326]
home/programs/rosetta_src_2017.08.59291_bundle/main/source/build/src/debug/linux/3.10/64/x86/gcc/4.8/default/libprotocols_b.5.so(protocols::surface_docking::SurfaceDockingProtocol::setup_movers(core::pose::Pose const&, unsigned long)+0x3b9) [0x2b752cd399ef]
home/programs/rosetta_src_2017.08.59291_bundle/main/source/build/src/debug/linux/3.10/64/x86/gcc/4.8/default/libprotocols_b.5.so(protocols::surface_docking::SurfaceDockingProtocol::apply(core::pose::Pose&)+0xab) [0x2b752cd38261]
home/programs/rosetta_src_2017.08.59291_bundle/main/source/build/src/debug/linux/3.10/64/x86/gcc/4.8/default/libprotocols.1.so(protocols::jd2::JobDistributor::run_one_job(std::shared_ptr<protocols::moves::Mover>&, long, std::string&, std::string&, unsigned long&, unsigned long&, bool)+0xf21) [0x2b7535a6d07f]
home/programs/rosetta_src_2017.08.59291_bundle/main/source/build/src/debug/linux/3.10/64/x86/gcc/4.8/default/libprotocols.1.so(protocols::jd2::JobDistributor::go_main(std::shared_ptr<protocols::moves::Mover>)+0xb4) [0x2b7535a6b538]
home/programs/rosetta_src_2017.08.59291_bundle/main/source/build/src/debug/linux/3.10/64/x86/gcc/4.8/default/libprotocols.1.so(protocols::jd2::FileSystemJobDistributor::go(std::shared_ptr<protocols::moves::Mover>)+0x46) [0x2b7535a44734]
surface_docking.linuxgccdebug() [0x4029db]
/usr/lib64/libc.so.6(__libc_start_main+0xf5) [0x2b753f62fb35]
surface_docking.linuxgccdebug() [0x402789]
surface_docking.linuxgccdebug: src/utility/backtrace.hh:162: bool print_backtrace_NR(const char*): Assertion `false' failed.
Got some signal... It is:6
Process was aborted!
 

Thu, 2017-09-07 12:44
dkozuch

What does your input PDB look like?

From those errors, it's looking like you're using a single chain monomer as your input file. This causes the crash when the surface docking application attempts to determine the docking partner. (Which doesn't exist in the input file.)

See Rosetta/demos/public/surface_docking_cpp/rosetta_inputs/lk_alpha_calcite.pdb for an example of how to construct the input file.

Note that the input PDB passed to -in:file:s also contains all the atoms for the surface on which you're going to do the docking. Moreover, the surface atoms should come first in the PDB, and the (single chain) protein should be the last thing in the PDB file.

Thu, 2017-09-07 13:49
rmoretti

I don't think it is the structure of the PDB file - at least mine looks very similar to the demo (representative section shown below).

Could it be that my surface vector is causing the problem somehow? (I did not have a very scientific way of generating it)

 

PDB:

HETATM    1  O   HOH B   1       1.310   1.720   3.460  1.00  0.00           O
HETATM    2  H   HOH B   1       1.740   1.430   2.660  1.00  0.00           H
HETATM    3  H   HOH B   1       1.340   2.680   3.420  1.00  0.00           H
HETATM    4  O   HOH B   2       5.220   4.590   1.030  1.00  0.00           O
HETATM    5  H   HOH B   2       5.670   4.850   1.820  1.00  0.00           H
HETATM    6  H   HOH B   2       5.250   3.610   1.060  1.00  0.00           H
HETATM    7  O   HOH B   3       6.540   5.380   3.280  1.00  0.00           O
HETATM    8  H   HOH B   3       6.110   5.100   4.090  1.00  0.00           H
... (truncated)
ATOM   9600  N   GLY A3201      14.266  33.555  45.626  1.00 29.90           N
ATOM   9601  CA  GLY A3201      15.399  32.871  46.359  1.00 29.36           C
ATOM   9602  C   GLY A3201      16.666  33.685  46.190  1.00 29.48           C
ATOM   9603  O   GLY A3201      17.621  33.264  45.542  1.00 26.74           O
ATOM   9604  N   THR A3202      16.661  34.865  46.796  1.00 32.04           N
ATOM   9605  CA  THR A3202      17.775  35.800  46.706  1.00 33.10           C
ATOM   9606  C   THR A3202      18.830  35.569  47.762  1.00 33.03           C
ATOM   9607  O   THR A3202      19.712  36.399  47.949  1.00 33.89           O
ATOM   9608  CB  THR A3202      17.276  37.245  46.838  1.00 33.61           C
ATOM   9609  OG1 THR A3202      16.532  37.377  48.058  1.00 35.59           O
ATOM   9610  CG2 THR A3202      16.381  37.610  45.656  1.00 33.34           C
... (truncated)
END

 

Thanks,

Dan

Fri, 2017-09-08 15:40
dkozuch

Ah! You're using (HOH) waters. By default Rosetta will ignore any waters which are in the input structure. (Because most of the time waters in the protein structure are superflous.) So to Rosetta your ice surface disappears, and it's only the protein which Rosetta sees. 

You need to tell Rosetta to include the waters when it reads the input PDB, which the option `-ignore_waters false` will do for you.

Fri, 2017-09-08 16:01
rmoretti

Thanks so much - fixed that error. Although now it complains:

 

core.io.pose_from_sfr.PoseFromSFRBuilder: [ WARNING ] discarding 1 atoms at position 2 in file input/myfile.pdb. Best match rsd_type:  HOH

Is this a naming issue with the atoms?

 

Dan

Fri, 2017-09-08 16:39
dkozuch

Naming was the issue - had to rename hydrogens to H1 ad H2 (instead of just H); sorry for the trivial question.

I am getting a more standard error now:

surface_docking.linuxgccdebug: src/protocols/surface_docking/SurfaceDockingProtocol.cc:358: void protocols::surface_docking::SurfaceDockingProtocol::split_protein_surface_poses(const core::pose::Pose&, core::pose::Pose&, core::pose::Pose&): Assertion `valid_surface_pose( pose )' failed.
Got some signal... It is:6
Process was aborted!

 

I assume this means it does not like the surface geometry or the surface vector. Anyone have any troubleshooting suggestions?

 

Dan

Sat, 2017-09-09 08:51
dkozuch