How to use -cst_fa_file and -relax:constrain_relax_to_native_coords at the same time

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.

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?

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.

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.

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

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.