fragment picker does not follow dihedral constraints

Member Site › Forums › Rosetta 3 › Rosetta 3 – Applications › fragment picker does not follow dihedral constraints

Viewing 8 reply threads
  • Author
    Posts
    • May 25, 2016 at 6:22 am #2431
      Anonymous

        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

         

      • May 25, 2016 at 4:31 pm #11595
        Anonymous

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

        • May 26, 2016 at 11:40 am #11597
          Anonymous

            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.

          • May 26, 2016 at 9:14 pm #11599
            Anonymous

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

            • May 27, 2016 at 12:52 am #11600
              Anonymous

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

              • May 27, 2016 at 8:55 am #11601
                Anonymous

                  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 )

                • May 27, 2016 at 12:15 pm #11602
                  Anonymous

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

                  • May 27, 2016 at 3:55 pm #11603
                    Anonymous

                      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.

                    • August 17, 2016 at 12:55 pm #11798
                      Anonymous

                        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. 

                         

                      • May 26, 2016 at 4:47 pm #11598
                        Anonymous

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

                        • May 27, 2016 at 5:08 pm #11604
                          Anonymous

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

                          • May 28, 2016 at 3:24 am #11605
                            Anonymous

                              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.

                               

                            • August 17, 2016 at 2:56 pm #11799
                              Anonymous

                                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?

                            • Author
                              Posts
                            Viewing 8 reply threads
                            • You must be logged in to reply to this topic.