Member Site › Forums › Rosetta 3 › Rosetta 3 – Applications › Surface Docking Application Crash
- This topic has 12 replies, 3 voices, and was last updated 6 years, 3 months ago by Anonymous.
-
AuthorPosts
-
-
September 3, 2017 at 1:32 am #2732Anonymous
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
-
September 4, 2017 at 5:26 pm #13748Anonymous
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..
-
September 6, 2017 at 10:18 pm #13759Anonymous
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
-
September 6, 2017 at 10:53 pm #13760Anonymous
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.
-
September 7, 2017 at 2:34 am #13761Anonymous
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!
-
September 7, 2017 at 3:00 pm #13762Anonymous
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.
-
September 7, 2017 at 7:44 pm #13763Anonymous
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!
-
September 7, 2017 at 8:49 pm #13765Anonymous
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.
-
September 8, 2017 at 10:40 pm #13773Anonymous
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
-
September 8, 2017 at 11:01 pm #13774Anonymous
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.
-
September 8, 2017 at 11:39 pm #13775Anonymous
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
-
September 9, 2017 at 3:51 pm #13777Anonymous
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
-
-
September 26, 2018 at 2:06 am #14450Anonymous
Hi,
I am a new user trying to follow RosettaSurface too. Do you know how to build the .surf for modeling? It is difficult for me to understand this now. Such as to build a model for Fe3O4, Fe2O3, SiO2 etc. I can build the pdb files for them, but do not know how to edit the .surf file, there are three lines in a demo files of the “calcite.surf”. Besides, the first line pointing to the surface center; other two lines are confusing me yet.
Anpu
-
-
AuthorPosts
- You must be logged in to reply to this topic.