Back to Recipes Homepage
recipe picture
Recipe: MicroIdealize 4.0 test
Created by LociOiling 2 1
Your rating: None Average: 5 (1 vote)


Name: MicroIdealize 4.0 test
ID: 102586
Created on: Tue, 12/19/2017 - 09:42
Updated on: Tue, 12/19/2017 - 17:42

This version deals with locked segments. It's designed to test for conditions observed in the aflatoxin puzzles.

Best For


LociOiling's picture
User offline. Last seen 2 hours 12 sec ago. Offline
Joined: 12/27/2012
Test for ideality changes in locked segments

In the first aflatoxin challenge puzzle, Puzzle 1440, some players observed ideality changes in locked segments.

This version of Microidealize looks at the issue in detail, checking for locked segments. If no locked segments are found, the recipe should behave almost like the base version, Microidealize 4.0.

If locked segments are detected, the recipe offers three new options:
* Do locked segments only?
* Include locked in wiggle?
* Include unlocked in wiggle?

The "do locked" option is unchecked by default, meaning the recipe attempts to idealize only the unlocked segments.

The "include locked" option is unchecked by default, meaning the recipe does not attempt to wiggle any locked segments after idealizing.

The "include unlocked" option is checked by default, meaning the recipe wiggles unlocked segments around the idealized section.

So far, this version has only been tested on Puzzle 1440. With all three of the options checked, the ideality scores of the locked segments immediately before or immediately after an unlocked section can change. From the starting position of 1440, locked segment 291 gained nearly 20 points in ideality with all three of these options checked.

The recipe includes a tab-delimited report of the ideality changes for each segment, which is produced at the end of the recipe. The report can be copied from the scriptlog file and pasted into a spreadsheet.

(The recipe print protein 2.7 can be used before and after this recipe for more detailed analysis, but unfortunately it doesn't identify locked segments. Look for an updated print protein 2.8 in the near future.)

Some limited additional testing shows that the gains from idealizing locked segments are all from wiggling the adjacent unlocked segments. If "do locked" is checked, and "include unlocked" is not checked, the recipe concludes very quickly, and no gain is reported. This is because unlocked segments can't be selected, and idealize applies only to selected segments. With "do locked" checked, the idealize function (structure.IdealizeSelected) doesn't do anything. The recipe attempts to select locked segments, but this has no effect. This means that "include locked in wiggle" also does nothing.

To summarize, the subscores of locked segments in puzzle 1440 can change due to changes in nearby locked segments. For example, the clashing subscore of a locked segment can improve is shake moves an unlocked sidechain away from it. Changes in ideality of a locked segment seem to result from changes to nearby unlocked segments.

The testing so far does not necessarily explain all issues seen with puzzle 1440. Some players have reported seeing backbone issues in locked sections when the "show backbone issues" view option is selected. I did not observe any backbone issues on locked segments, but there were lots of them on the unlocked segments.

As a side note, on some puzzles with locked segments, the sidechains of some locked segments are actually unlocked. This does not appear to be the case in puzzle 1440. Using "ligand specific" coloring, all the sidechains of the locked segments in 1440 appear in the same gray color as the backbone. Any unlocked sidechains would appear in the score-based coloring seen on the unlocked segments. There is no direct way for a recipe to detect unlocked sidechains of a locked segment.

Internally, this version of the recipe uses the segment set and list functions developed by Timo van der Laan, lifted and slightly modified from his EDRW family of recipes. These functions are used during initialization, and there's a little duplicated effort there. The sets of locked or unlocked segments are used to generate "work lists". The work lists are sets of segment ranges to be idealized.

There are also some other minor internal changes. The use of work lists made it easy to combine two different "Go" functions into one. Table sorting has been replaced by Rav3n_pl's "ShuffleTable", and a standard Lua "table.sort". The cleanup method has been updated to a standard version to provide error reporting. The recipe now uses standard "Timo logic" to detect ligands at the end of a protein. Any such ligands are automatically excluded.

The logic used for detecting locked segments can be extended to other recipes. In general, just working on the unlocked segments may be good enough for most puzzles. A complete method would need to allow for locked segments with unlocked sidechains, and ligands with multiple rotamers, which have been seen in some recent puzzles.

Want to try?
Add to Cookbook!
To download recipes to your cookbook, you need to have the game client running.

Developed by: UW Center for Game Science, UW Institute for Protein Design, Northeastern University, Vanderbilt University Meiler Lab, UC Davis
Supported by: DARPA, NSF, NIH, HHMI, Amazon, Microsoft, Adobe, Boehringer Ingelheim, RosettaCommons