You are here

fragment picker does not follow dihedral constraints

13 posts / 0 new
Last post
fragment picker does not follow dihedral constraints
#1

Hi, 

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

# Input
-in:file:vall       XXX/rosetta_2015_39/tools/fragment_tools/vall.jul19.2011.gz
-in:file:fasta      XXX.fasta
-frags:ss_pred      ./input/psipred/XXX.psipred
-in:file:s          ./input/XXX.pdb

# What should we do?
-frags::bounded_protocol        

# Weights file
-frags::scoring::config        input/quota-cst_protocol.wghts

# torsion angle constraints 
-constraints::cst_file         input/mydihedral.cst

# 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
-frags::n_candidates        500
-frags::n_frags            100

# Output 
-out::file::frag_prefix        output/frags
-frags::describe_fragments     output/frags.fsc

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

 

Post Situation: 
Tue, 2016-05-24 23:22
attesor

I've sent this along to someone experience with fragments for an expert opinion.  

Wed, 2016-05-25 09:31
smlewis

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.

Thu, 2016-05-26 04:40
attesor

Stupid question: are we confident that it's just not an angle in degrees versus angles in radians problem?

Thu, 2016-05-26 09:47
smlewis

What do you mean? Even though, how come the top hits are so different?

Thu, 2016-05-26 14:14
attesor

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

Thu, 2016-05-26 17:52
smlewis

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 )

Fri, 2016-05-27 01:55
attesor

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

Fri, 2016-05-27 05:15
attesor

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.

Fri, 2016-05-27 08:55
smlewis

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

Fri, 2016-05-27 10:08
attesor

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.

 

Fri, 2016-05-27 20:24
smlewis

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. 

 

Wed, 2016-08-17 05:55
attesor

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?

Wed, 2016-08-17 07:56
smlewis