Optimize frozen puzzle

Case number:845833-989128
Topic:Game: Display
Opened by:Rav3n_pl
Status:Closed
Type:Suggestion
Opened on:Sunday, January 9, 2011 - 11:11
Last modified:Sunday, January 23, 2011 - 11:59

Looks like bigger puzzle==slower client.
In 391 we have only few unlocked segments and few unlocked side chains on totally locked backbone and game is almost unplayable for me - Shake(1) takes about 2mins, rebuild(30) 3 segments takes over a hour on my P4 3Ghz.
Client should totally ignore unlocked segments on shake/wiggle routines.
Other way around is "cut" protein on pieces and give us only that ~40 segments we really need.
Locking routine should be changed also to prevent moving of that segments totally. In few occasions when I made backbone clash and wiggle all entire construct shows zillions of constrains and falls apart.

(Sun, 01/09/2011 - 11:11  |  12 comments)


Joined: 06/17/2010

I mean "ignore of locked segments" not "unlocked"... (no edit post option)

Joined: 04/19/2009

I completely agree - I can run some mid-game scripts on smaller puzzles, but the monsters make it impossible without crashing (Mac computer)

Joined: 08/09/2010
Groups: foldeRNA

I agree; another suggestion could be to change all of the alanine residues to glycine in the outer regions (I assume they were substituted for the real amino acids to speed the process). The areas that are closer to the region of interest should definitely remain intact because of their interactivity with the mutable region. After a certain amount of buffer space from the mutable region though, the rest of the protein becomes useless to see, except for interest. You might be able to determined the needed buffer space experimentally by changing all of the mutable residues to the bulkiest groups to see how far down the proteins the effects are seen with a shake.

In the post challenge analysis, you could use the full proteins on fancier computers to see if there is a difference between the altered proteins and the originals to determine the best configuration for future puzzles of this size.

Joined: 08/06/2010
Groups: Contenders

While a sad second place, One could create game specific shake and wiggle routines.
by selecting the segments one wants then wiggling them one achieves the desired results:

-----------------
function select_range (sseg, eseg, more)
if more ~= true then
deselect_all()
for x=sseg,eseg do
select_index(x)
end
end

select_range(20,30)
do_global_wiggle_all()

--------------------

this script will wiggle the selected range until stopped.

Rav3n's sphered routine taught me this.

The other thing I learned by accident is that the selection
carries from recipe to recipe so one only needs one script to
select the range then separate scripts to do the wiggles and shakes.
one in each script to replace the normal GUI buttons.

The thing one has to watch for is separate ranges for locked
backbone and sidechains. And, as strange as it seems, sometimes
do_global_wiggle_all() produces points where do_global_wiggle_sidechains()
will not even though the backbone is locked. I don't understand it.

Joined: 06/17/2010

omg 393 killed me today.....
All we need is tops 100 segments and we get over 460??? cmon!
Why not cut it to pieces? If you can build 2 locked proteins why not make 5 or 6 smaller?
Most strange is, that client not eating much more memory to handle so big puzzle, but speed is dropping dramatically....
I think turning all "far" segments to glycine may help a lot (for shake speed).... but best option IMO is cut all "far" parts or add "ignore" functionality to existing "lock" to not use that unwanted/unneeded segments in score calculations (what I think causing all that "slowdown" problem).

beta_helix's picture
User offline. Last seen 22 hours 8 min ago. Offline
Joined: 05/09/2008
Groups: None
Status: Open » Open

We're trying to come up with a solution to this problem for the next Design Puzzle.
Thanks for your feedback and patience!

Joined: 08/06/2010
Groups: Contenders

While some segments may be entirely locked it looks like a lot of sidechains on many are not. Yeah, blue fuze takes quite a bit longer than needed. I'll be documenting a routine to select a speroid tonight. I thought I'd include it in some of my scripts. I was trying to decide if I wanted to select some splined region or just a conjunction of spheres when dealing with these interface puzzles. Since I can't pass a table to select_index, I have to individually select discontigious segments. If you solve this issue before the next interface puzzle I needn't do anything.

untested (simple version, more complex would include select_index_range):

function fsl.selectSpheroid (seg1, seg2, radius, more)
local d=get_segment_distance(seg1,seg2)+(2*radius)
if not more then deselect_all() end
for i=1,game.segCount do -- game.segCount is get_segment_count() less any ligands
if (get_segment_distance(seg1,i)+get_segment_distance(seg2,1)) <= d then
select_index(i)
end
end
end

usage:

fsl.selectSpheroid(seg1,seg2,10)

fsl.fuze('Blue', fsl.selectSpheroid,seg1,seg2,10)
where
function fsl.fuze(type,selFunction,...)
selFunction=fsl.default(selFunction,select_all)
etc
selFunction(...)
etc
end

beta_helix's picture
User offline. Last seen 22 hours 8 min ago. Offline
Joined: 05/09/2008
Groups: None

I'll be posting a new interface puzzle in the next hour or two, hopefully the new fix will save you some work!

beta_helix's picture
User offline. Last seen 22 hours 8 min ago. Offline
Joined: 05/09/2008
Groups: None
Status: Open » Closed

Please let us know if Puzzle 394: Design the Interface 4b doesn't fix this problem.

We completely locked most of the sidechains and as you suggested we cut out the protein loop that we are interested in.

I hope this helps!

Joined: 06/17/2010

Better, but still...
I think number of residues (locked o not) is essential.

Maybe you can create same puzzle in few variants:
1 - only locked backbone
2 - locked backbone and unneeded ss
3 - all unneeded ss are gly (bb locked)
4 - all unneeded aas are cut out

In that way we can simple run same script few times after reset puzzle, compare times and choose best option for future :)

beta_helix's picture
User offline. Last seen 22 hours 8 min ago. Offline
Joined: 05/09/2008
Groups: None

We have thought many times about whether it is better to just remove the areas of the protein that are frozen and unimportant but then you are left with an ugly fractured mess instead of a nice looking protein so it's hard to see what is going on.

When I have a chance, I'll try to post some of those puzzles you suggested as Contests so you can all run some benchmarks.

Remind me if I forget to do this! :-)

Joined: 06/17/2010

Maybe full protein as guide in addon to cutted out part?
Looks like loaded guide not messing much in performance.

Sitemap

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