Bug in Loop Modeling

[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

[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
>

[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.

[Author]

Posts