Member Site › Forums › Rosetta 3 › Rosetta 3 – Applications › How to use -cst_fa_file and -relax:constrain_relax_to_native_coords at the same time
- This topic has 11 replies, 3 voices, and was last updated 12 years ago by Anonymous.
-
AuthorPosts
-
-
November 29, 2012 at 10:12 pm #1472Anonymous
Hi:
I would like to relax my X1.pdb structure with the atom coordinate constraints relative to the backbone atoms of another structure X2.pdb and some other constraints given in -cst_fa_file constrains.
Here is what I have done:relax.linuxgccrelease -database /home2/ruvinsky/simcode/rosetta_database -in:file:s X1.pdb -in:file:fullatom -out:file:fullatom -relax:fast -score:weights score12_full -out:pdb -ex1aro -ex1 -ex2 -out:nstruct 10 -relax:constrain_relax_to_native_coords -in:file:native X2.pdb -cst_fa_file constraints
It failed with the following error message:
ERROR: Called Constraint::show method from derived class Pocket,ended up in Constraint::show
ERROR:: Exit from: src/core/scoring/constraints/Constraint.hh line: 326The relax app worked well when one of the flags (either -relax:constrain_relax_to_native_coord or -cst_fa_file) was removed. Is there a way to use both constraints at the same time?
Thanks.
Anatoly
-
November 29, 2012 at 10:15 pm #8137Anonymous
You can definitely get the effect of both constraints by writing your coordinate constraints from X2 directly into your constraint file “constraints”. I’ll see if I can debug the crash if I get a chance.
-
November 29, 2012 at 10:47 pm #8138Anonymous
Is there a script to create constraints for -in:file:native?
-
November 30, 2012 at 10:59 pm #8142Anonymous
I haven’t done it with constrain to native, but I have used -cst_fa_file with constrain to start, and it worked fine. As far as I’m aware, there shouldn’t be an issue with things on that end.
Looking at the error message you get, my hunch is that there is something off with your provided constraint file (you’re using Pocket constraints?), and I’m guessing you may run into issues even if you created the same constrain to native constraints externally.
BTW, with the released versions of Rosetta, you need to be sure that your two structures X1.pdb and X2.pdb are the same size, and each residue matches 1:1 between the two. You may get strange results if they don’t.
What does your provided constraint file look like, and which version of Rosetta are you using? -
December 1, 2012 at 5:58 pm #8146Anonymous
Yes, I am using the Pocket constraints with Rosetta 3.4. The constraint file has only one line: Pocket 0.25 657:B.
Both structures X1 and X2 are of the same size.
-
December 1, 2012 at 10:37 pm #8147Anonymous
What’s happening is that when the -constrain_relax_to_native_coords is set, it adds a virtual root to the foldtree to allow all the residues to move to the appropriate coordinates. (If you didn’t have that, you might end up with a situation where the N-terminus of your protein isn’t able to move to the correct position, and will trail from your protein like a tail.) The problem is that in adjusting the constraints to account for the extra residue the show() method is called on all the constraints, and since the PocketConstraint doesn’t have that function properly implemented, things crash.
I’m not sure how much change you’ll get in the structure from a single added pocket constraint, but if omitting it is not sufficient for you, it looks like you will have to make the coordinate constraints externally. There really isn’t a program to do it automatically for you, although the format is rather simple. There is a Python script which does something similar at rosetta/rosetta_source/src/apps/public/relax_w_allatom_cst/sidechain_cst_3.py in Rosetta 3.4. It produces constraints to side chain heavy atoms instead of to backbone heavy atoms, and does bounded constraints instead of the default harmonic constraints, but should be simple to modify to output backbone constraints.
You’ll want to make sure the native protein and the input protein are roughly overlayed in coordinates before using it, to avoid the issues with a non-virtual root mentioned above.
-
December 3, 2012 at 5:02 pm #8157Anonymous
If the problem is just a missing show method, then we can just hack-implement show for you. Open up src/core/scoring/constraints/Constraint.hh and find line 228:
virtual void show( std::ostream & /*out*/ ) const {
unimplemented_method_error( std::string( “show” ) );
}Just comment out the line unimplemented_method_error (add // to the beginning of the line, like in the comment above the function) and the code will *probably* run. It won’t show anything for your PocketConstraint, but that’s a cosmetic defect in the log file; it will probably calculate the PocketConstraint correctly.
-
December 3, 2012 at 7:21 pm #8159Anonymous
Thanks!
-
December 3, 2012 at 9:13 pm #8161Anonymous
I just found that combining atom coordinate constraints with the constraints for pocket optimization in one file does not work.
ERROR: Called Constraint::show method from derived class Pocket,ended up in Constraint::show
ERROR:: Exit from: src/core/scoring/constraints/Constraint.hh line: 326The following is my -cst_fa_file test-file:
AtomPair CA 4 CA 4 HARMONIC 0.0 0.5
Pocket 0.25 657:B -
December 5, 2012 at 10:38 pm #8180Anonymous
No problem at all. I thought you and rmoretti were suggesting two options. That’s why, first, I put all the constraints in one file and run Rosetta without any modifications in the code. Anyway, commenting out the line you suggested has not worked out. Here is the error message:
core.io.constraints: read constraints from constraints
ERROR: Called Constraint::remap_resid method from derived class Pocket,ended up in Constraint::remap_resid
ERROR:: Exit from: src/core/scoring/constraints/Constraint.hh line: 326 -
December 6, 2012 at 1:09 am #8181Anonymous
Wait, you’re IN the Karanicolas lab! This is your lab’s code! You didn’t tell us that!
The problem is that PocketConstraint is only half-implemented. show() isn’t implemented (that was your first problem), remap_resid() isn’t implemented (that’s your second problem), and in general the class is only partly implemented (derivatives aren’t implemented, which is going to cause incorrect minimization).
Undo that thing with Constraint::show() I showed you do to…that’s an ok hack for an end-user, but you have SVN access (or should), so you should go ahead and implement both show() and remap_resid() for the PocketConstraint class that you need. If you know basic C++ and need help implementing the functions, I can do that…it’s just that I need to offer very different help to developers rather than academic end-users. If you don’t know basic C++, you need to learn that first (from a book or tutorial, or someone in your lab?)
-
December 3, 2012 at 10:14 pm #8162Anonymous
My mistake for not clarifying this: did you recompile after making the change to the code that I suggested? (Re-issue the same scons command you used to originally compile the code?) The recompile should take maybe 5 minutes max, not the hour it may have initially taken.
-
-
AuthorPosts
- You must be logged in to reply to this topic.