puzzle 1073, segment 257 may show type "M" (auto structures tool creates spurious ligand)
Case number: | 699969-2000613 |
Topic: | General |
Opened by: | LociOiling |
Status: | Closed |
Type: | Bug |
Opened on: | Thursday, April 16, 2015 - 05:41 |
Last modified: | Tuesday, July 31, 2018 - 20:32 |
Puzzle 1073 has 257 segments. On some solutions, segment 257 has type "M", indicating a ligand. Many recipes adjust the segment count to ignore a ligand at the end. These recipes may not work quite as expected on this puzzle. Two solutions have been shared with scientists, one with segment 257 as a normal segment, and one with segment 257 as type "M".
On the type "M" solution, it's not possible to change segment 257 to sheet or helix. On the "normal" solutions, the secondary structure of segment 257 can be changed as expected.
Seeing this behavior on puzzle 1088. When puzzle opened in one client, segment 141 is a ligand. When opened in another client, not a ligand.
Build 20150512-0e5b7a4ade-win_x86 on both clients, Windows 7 Pro.
For 1088, shared with scientists a solution with segment 141 as type "M". It's still "M" when I open it in a different client.
Add puzzle 1090 to the list of random spurious ligands, seems like a general problem.
Add puzzle 1090 to the list of random spurious ligands, seems like a general problem.
uAlso observed on puzzle 1091.
The issue may have something to with the "auto structure" tool. On first opening 1091, using "EnzDes" coloring, segment 139 is green, and can be changed to sheet or helix. When I "select all" and run "auto structures", segment 139 turns white, and its structure can no longer be changed. In this case, "undo" reverts segment 139 back to normal loop.
The "Lig Detector" recipe, https://fold.it/portal/recipe/101024, initially shows no ligands, then after "auto structurse", shows segment 139 as a ligand in this scenario.
More ligand info.
First, structure type "M" is for "molecule". Found that looking the help() output.
Second, it may be normal for a ligand to report a non-zero score. Found this by looking at puzzle 1076, which I think is our most recent true ligand puzzle. In 1076, segment 211 is a ligand, and reports a score various positive scores at the different starting points.
Another update on the spurious ligand issue.
(Too bad we can't change the title on this feedback, since it's a general problem, apparently affecting all puzzles.)
The root cause is the auto structures tool, which incorrectly changes the last segment to a ligand if all segments are selected.
The workaround is to select all segments, then manually deselect the last segment, then use the auto structures tool.
The "reset structures" tool will reset the false ligand. So will "undo" (Z or ctrl-z) if you use it quickly enough. (I suppose "reset puzzle" works too, kind of drastic.)
Puzzle 1100 is a true ligand puzzle, with segment 211 as the ligand. This puzzle shows a couple of interesting quirks.
First, if you "select all", segment 1 is not selected. Segment 1 can't be selected manually, either. I suspect this might impact recipes that work on selected segments, but it's really a separate issue.
Second, if you "select all" the auto structures tool does not appear, apparently since the ligand at 211 is selected. If you deselect 211, the auto structures tool appears. Segment 210 becomes a fake ligand if you use auto structures at this point. Manually selecting 2-210 and using auto structures has the same effect.
This behavior is on the last build, 20150608-3283c37895-win_x86-devprev.
Thanks for this update, LociOiling! We're looking into it.
Very good analysis Loc. Now I get why my DRW reports ligands in some cases, and behaves accordingly. I was really puzzled why this happened.
This one could use a new title, like "auto structures tool creates spurious ligand".
Fixed :)
Status: Open » Closed |
My tests on release 20150819-e47db4cb4b-win_x86 show this bug has indeed been fixed.
My tests included two semi-related issues:
* the auto structures tool no longer changes the last segment to a ligand when all segments are selected
* type "molecule" -- codes "m" and "M" -- as argument 2 to structure.SetSecondary no longer terminate the recipe
The valid secondary structure are now 'e', 'h', 'l', 'm', 'E', 'H', 'L', and 'M'. The codes 'm' and 'M' don't seem to have any effect on a non-ligand puzzle. Other codes still terminate the recipe.
I'm marking this feedback closed. I'll see if there was a separate feedback on the "molecule" issue.
Status: Closed » Open |
Changing the status back to "open", this bug has been back for a while (http://fold.it/portal/node/2001300) and is still with us in 20151218-b5ec35b633-win_x86-devprev.
Status: Open » Closed |
Old problem, got fixed a while back, closing.
Meant to make this a bug....