Bug in Loop Modeling

Member Site Forums Rosetta 3 Rosetta 3 – General Bug in Loop Modeling

  • This topic has 2 replies, 2 voices, and was last updated 14 years ago by Anonymous.
Viewing 2 reply threads
  • Author
    Posts
    • #675
      Anonymous

        Hi,

        I found a bug in the loop modeling protocol (Rosetta 3.1).
        When the loop contains Gly and this residue is chosen as cutpoint, the program exits stating sth like “Atom CB not found in residue GLY”.

        The reason for this is that in the function “filter_loop_neighbors_by_distance” in src/protocols/loops/loops_main.cc the two lines

        if ( pose.residue( i ).name() == “GLY” ) and

        if ( pose.residue( j ).name() == “GLY” )

        don’t apply to Gly when Glycine is a cutpoint residue (it’s then called “GLY_p:……”)

        If one replaces these two lines by

        if ( pose.residue( i ).name().substr(0,3) == “GLY” ) and

        if ( pose.residue( j ).name().substr(0,3) == “GLY” )

        it works.

        Cheers,

        Daniel

      • #4634
        Anonymous

          > Hi,
          >
          > I found a bug in the loop modeling protocol when using -refine_kic (Rosetta 3.1).
          > When the loop contains Gly and this residue is chosen as cutpoint, the program exits stating sth like “Atom CB not found in residue GLY”.
          >
          > The reason for this is that in the function “filter_loop_neighbors_by_distance” in src/protocols/loops/loops_main.cc the two lines
          >
          > if ( pose.residue( i ).name() == “GLY” ) and
          >
          > if ( pose.residue( j ).name() == “GLY” )
          >
          > don’t apply to Gly when Glycine is a cutpoint residue (it’s then called “GLY_p:……”)
          >
          > If one replaces these two lines by
          >
          > if ( pose.residue( i ).name().substr(0,3) == “GLY” ) and
          >
          > if ( pose.residue( j ).name().substr(0,3) == “GLY” )
          >
          > it works.
          >
          > Cheers,
          >
          > Daniel
          >

        • #4635
          Anonymous

            Thanks for pointing this out! In case you’re curious, replacing name() with name3() would also solve the problem. This bug was fixed (in a different and slightly more effective way) 10/21/09 in the internal version, but it never got patched to the release version.

        Viewing 2 reply threads
        • You must be logged in to reply to this topic.