I have been try fragment_picker from Rosetta weekly build 2015_39. I want to enforce a set of dihedral restraints. So I wrote the following .cst file ():
Dihedral N 9 CA 9 C 9 N 10 CIRCULARHARMONIC 2.227 0.087
Dihedral C 9 N 10 CA 10 C 10 CIRCULARHARMONIC 0.961 0.087
Dihedral N 10 CA 10 C 10 N 11 CIRCULARHARMONIC 0.630 0.087
Dihedral C 10 N 11 CA 11 C 11 CIRCULARHARMONIC 1.361 0.087
Dihedral N 11 CA 11 C 11 N 12 CIRCULARHARMONIC 0.174 0.087
Dihedral C 11 N 12 CA 12 C 12 CIRCULARHARMONIC -1.453 0.087
# and some more ....
As a matter of fact, I extracted these set of angles from one fragment in the vall database:
position: 10 neighbors: 200
3obh A 34 F E -119.915 127.617 176.140
3obh A 35 N L 55.042 36.081 172.555
3obh A 36 G L 77.967 9.958 179.454
3obh A 37 A L -83.262 159.599 173.881
3obh A 38 P L -51.292 136.669 -177.055
3obh A 39 A L -59.064 139.528 174.781
3obh A 40 K E -126.641 156.784 172.732
3obh A 41 F E -57.477 131.134 -174.767
3obh A 42 D E -139.442 126.892 179.511
Obviously, I did this because I want see if fragment picker would pick out this fragment. Fragment_picker runs normally and output is generated correctly. I give massive weight to DihedralConstraint (see the weight file below) and null weight to other criteria. However, this fragment is not picked in the output at all. The top hits are nowhere similar to the fragment from 3obh, or the angle restraints I specified. And they are very different from each other (see the end of the post). My question is, why is the original test fragment not picked at all?
I used the following flags file
# What should we do?
# Weights file
# torsion angle constraints
# we need nine-mers and three-mers
# can I also try other lengths
-frags::frag_sizes 3 # I also tried other lengths like 9.
# Select 200 fragments from 1000 candidates. We need more candidates
# than fragments for the selector to work properly
The weight file is:
# score name priority wght max_allowed extras
DihedralConstraintsScore 500 500.0 -
SecondarySimilarity 0 0.0 - psipred
RamaScore 0 0.0 - psipred
FragmentCrmsd 0 0.0 -
the top hits are :
position: 10 neighbors: 100
2no4 A 11 V L -115.361 -49.687 175.162
2no4 A 12 D L -136.816 75.580 -161.366
2no4 A 13 S L -108.226 -14.216 -172.133
1u1j A 320 D L 61.503 32.029 -179.660
1u1j A 321 K L -117.956 -18.670 176.783
1u1j A 322 L E -83.039 123.539 178.990
3dlq R 110 T E -97.509 120.108 178.082
3dlq R 111 C E -105.454 113.337 -176.842
3dlq R 112 I E -108.281 130.176 -176.115
2vso E 265 R H -53.063 -49.582 -176.257
2vso E 266 I H -74.060 -37.401 176.264
2vso E 267 K H -57.932 -40.173 178.977
1r7a A 369 F H -66.314 -30.808 -172.168
1r7a A 370 F H -86.590 -6.103 175.150
1r7a A 371 L L -89.574 139.955 -178.038
I've sent this along to someone experience with fragments for an expert opinion.
I just want to add, I also tried using AtomPair constraints to specify BB atom distances. In this case, fragment_picker worked very well and 3obh was picked as the best fragment.
I also want to mention that the dihedral angles I used in the Dihedral constraints were taken from Vall, not PDB.
Stupid question: are we confident that it's just not an angle in degrees versus angles in radians problem?
What do you mean? Even though, how come the top hits are so different?
According to the documentation for dihedral constraints, "Dihedral is measured in radians on -pi -> pi." Looking harder at your files, it looks like you formatted the input that way, and converted from the vall correctly. Thus, it was a stupid question: but at the time that I asked it, I was just throwing the idea out as I ate lunch instead of reading carefully :)
Some other things about constraint file:
1. 1st line in .cst file is not read in as constraint. This is somewhat surprising to me as it is not stated in the documentation. I suggest to update the Sample Files in the help page to reflect this.
2. in the documentation, it says: "Constraints can be specified using two different file formats, line-based and section-based.". And then no information is available about "section-based" format in the document ( https://www.rosettacommons.org/docs/latest/rosetta_basics/file_types/constraint-file )
nailed it: it is a bug in DihedralConstraintsScore.cc line 128:
double torsion = dihedral_degrees(v1, v2, v3, v4);
it should be:
double torsion = dihedral_radians(v1, v2, v3, v4);
I introduced the fix in my own code and recompiled Rosetta. Now it returns the correct fragments! So in the end it turned out that you were right: it is a degree / radian problem! You rock :-)
I'm glad the answer was on the right track. Unfortunately it's a slightly different problem. The documentation "https://www.rosettacommons.org/docs/latest/rosetta_basics/file_types/constraint-file" is for constraints during regular Rosetta, and the dihedral constraint there refers to ./core/scoring/constraints/DihedralConstraint.cc, which IS on radians. I thought it was strange that you could use those constraints with fragment picking but didn't pay attention. It turns out that there's a parallel constraint machinery (that you are using) including the ./protocols/frag_picker/scores/DihedralConstraintsScore.cc that you identified. That fragment picking constraint format is totally undocumented as far as I can tell - I'd've expected it to be here (https://www.rosettacommons.org/docs/latest/application_documentation/utilities/app-fragment-picker) but it isn't.
I'll ask Dominik to document the frag-picker constraints.
I understand your advice about degree/radian was more for my input constraint file.
I think what's more urgent to fix is the source code rather than the document. The current source code just cannot do fragment picking with dihedral constraints.
As for the documentation for constraint file used in "regular rosetta", I think the 2nd issue I reported remains: it says the file has two format: line-based and section-based. But only the line-based is documented. See "https://www.rosettacommons.org/docs/latest/rosetta_basics/file_types/constraint-file". And the section-based format is undocumented. I am curious and would like to learn more on the section-based format (or does it actually refer to the MultiConstraint and AmbiguousConstraint?).
Code: I'm not sure why DihedralConstraintsScore.cc needs to be modified? It just takes input in degrees instead of radians? Did I miss a bit of logic here? The radians-input constraint (which is regular DihedralConstraint.cc, not this one) takes radians and says radians; this one is unfortunately totally undocumented, as you've correctly identified.
Section-based constraints: I don't know what they are either and have wondered for years. I think that format has been abandoned. I'm going to just remove it from the documentation.
I stronly suggest to fix the bug in coming releases. I recently upgraded to Rosetta 3.6 and got stumbled again on the same bug.
Unfortunately cannot confirm it with Dominik Gront because no reply was given after 3 months.
The undocumented constraint you are using takes degrees, right? I was under the impression it worked fine when using degrees instead of radians? The regular constraints documentation page does not apply at all to the fragment-picking constraints. The 'bug' is the total lack of documentation, then?