almost as effective

I can't speak for anyone else of course, but as long as the credit is sorted out, I'd rather have the long wu with the optimal science payload.

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

almost as effective

I can't speak for anyone else of course, but as long as the credit is sorted out, I'd rather have the long wu with the optimal science payload.

The difference in science payload for any given returned structure between the two protocols is very marginal, but being able to produce way more decoys in a given time has a huge advantage. So everything taken into account, using the faster relax protocol should actually be advantageous scientifically too, not just in terms of shortening the WU length.

Mike

---

http://beautifulproteins.blogspot.com/
http://www.miketyka.com/

Okay, fine by me.

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

I've tracked down some problems with the hombench_ WUs, so the next batches going out soon (in preparation now) should take considerably less time, certainly less than 2-3 per model, more likely (depending on the sie of the protiens) less than half an hour.

THe reasons for the long WUs were to do with the size of the protiens, which is why the problem was much worse for some of the guys than others.
Some of the proteins in the hombench WUs are larger than the usual stuff
we had run un BOINC before. THe refinement stage of the code was using an older algorithm that turned out to scale poorly with protien size.
I've replace that part with an almost as effective, but much much more efficient algoithm.

THanks for alerting us to this problem. FOr some of the smaller sized WUs i've sent out after noticing (e.g.hombench_mtyka_looprelax_ccd_moves_2_looprelax_ccd_moves_t302_)
i'm seeing as much as 10models / hr now !
while the larger proteins (e.g. _t293 that was previously causing trouble) are now down to an acceptable 2 hours per model.


This is exciting! THere'll be a bunch of stuff going out soon. Once we've got some preliminary results we'll display them in the science thread.



Mike




Mike

G'Day Mike,
I think you had better have a look at the Ralph Forum.
You have made a major change to run time that is for sure, from up to 11+ hours down to 9 seconds,
it then errors out on all work unit "hombench_tex" types.
Still needs work I'm afraid.

---

G'Day Mike,
I think you had better have a look at the Ralph Forum.
You have made a major change to run time that is for sure, from up to 11+ hours down to 9 seconds,
it then errors out on all work unit "hombench_tex" types.
Still needs work I'm afraid.

Yes James's WUs are all failing on RALPH - he's tracking down why, he's been adding constraints to these runs (to hopefully steer the search towards the native structure). I should add that even though all the WUs start with hombench_ their inner details can be very different. We're running at least 4 different protocols right now in an efford to establish what approach works best for which sort of problem - something we can determine properly and reliably through very large runs - hence BOINC.

We'll get this fixed of course before moving to BOINC.

I can't see any WUs with 9 second runtimes though ?! If you mean James' WUs then yes, they seem to fail very early on, but that's a seperate problem. (not to do with my change).
The units called hombench_mtyka_looprelax_ccd_moves_2_looprelax_ccd_moves see ok though right ? (i guess thi is RALPH specific discussion and not relevant to BOINC users)

Thanks for looking out for problems :)

Mike

---

http://beautifulproteins.blogspot.com/
http://www.miketyka.com/

You just can't win'em all:

https://boinc.bakerlab.org/rosetta/workunit.php?wuid=182132039

hombench_mtyka_foldcst_simple_foldcst_simple_t303___4611_4660

Task ID: 199398597

CPU time: 58,300.45 [!!]
Claimed credit: 389.05
Granted credit: 12.00 [!!]

Computer:
GenuineIntel
Intel(R) Core(TM)2 Duo CPU T8100 @ 2.10GHz [x86 Family 6 Model 23 Stepping 6]
Number of CPUs 2
Operating System Darwin 9.5.0
Memory 4096 MB
Cache 976.56 KB
Swap space 92321.28 MB