http://www.powerplantjobs.com/ppj.nsf/powerplants1?openform&cat=ny&Count=500

(No idea why the picture is not displaying, tags are correct...?)

It appears that the img tag does not support HTTPS addresses (if you right click on the image in your post and 'copy image URL' it comes out like this: http://https//farm9.staticflickr.com/8637/16610904862_fb4cd398e2_z.jpg) Fixed by simply changing 'HTTPS://' to vanilla 'HTTP://' :) Cheers

The lack of a trend line for increased decoy count for a larger protein could also be an accounting difference. As was discussed previously in the thread, some proteins are studied in phases and so from start to finish perhaps data for such a protein appears as 4 or 5 separate runs.

Are you looking for decoy sets? If you are looking for runtime benchmarks/data, I believe the decoy sets have runtime info for each decoy, which of course are dependent on the machines that produced them.

I can also provide the input files but I can't spend much time helping you with details.

Rosetta is developed by numerous academic institutions through the Rosetta Commons. There are continuous unit tests, performance benchmarks, etc.. run after each code checkin. The unit and performance tests framework is part of the code distribution. The code is constantly being developed. In fact there's a developers meeting going on right now in Boulder, CO where many developers from the various commons institutions meet to talk about code development, testing, optimization, etc. There's also an annual meeting to talk about the science.

If you are talking about a specific protocol benchmark like ab initio folding. We do have benchmark sets that we use for testing etc.

No, I'm not aware of any aggregated data on runtimes.

Definitely not sensitive info :)
Assuming a runtime of around 2 minutes per decoy for a 100 residue protein gives around 56 cpu days for a somewhat modern cpu.

I started looking at a couple of my tasks and most of them say they've completed between 6 and 10 decoys (An example here) - what am I missing because that would work out to 40-60 minutes per decoy considering the total CPU time is around ~6 hours??

I am as curious as Mark is about this kind of thing - I work as a Database Developer / Business Intelligence Analyst and one of the things that amazes me/motivates me to contribute to projects like this is that I get frustrated when I have to wait for hours for data crunching queries to run at my day job, I can hardly imagine having to wait 50-60 days for results!!! ... Especially if some of what you're doing is iterative in nature, I try to imagine compiling code/running a query, waiting 60 days for it to crunch, tweaking it a bit and running the tweaked version.. rinse and repeat... that's gotta be really frustrating!?!?

Definitely not sensitive info :)

The algorithm for ab initio folding has not changed much since. Our Robetta automated structure prediction server which uses R@h for sampling aims for around 20,000 decoys of the target and 5,000 decoys from up to 4 homologs. Assuming a runtime of around 2 minutes per decoy for a 100 residue protein gives around 56 cpu days for a somewhat modern cpu. Of course there are many factors that determine the runtimes and they vary depending on the specific types of jobs and targets being run, and of course the computer. I'll see if anyone in our lab can contribute to this discussion. I'm pretty sure someone doing protein design and forward folding (ab initio tests on the designed sequences) can chime in. But keep in mind, experiments may vary considerably in their computing requirements etc..

Runtimes and decoy counts are given for each job in the stderr output which is available for each job you run. If you look at the tasks from your computer(s) you can click on the Task ID to get this info.

The "Sampling bottlenecks in de novo protein structure prediction" paper provides some insight.

The quick answer is that it depends on the protein.

Some proteins are studied in phases, where results from one phase are used to place some constraints on the search space of subsequent phases. So I'm sure there is no simple answer to your question.

To gain an intuitive sense of it, you might spend some time playing FoldIt!

I believe the total potential search space is on the order of the number of AAs cubed. Even that depends upon the specific AAs. But the search algorithms are able to do better than that. And it's a good thing, otherwise you'd need billions of years of all existing computing power to perform an exhaustive search on a large protein.

Still no real updates here? No news seems to indicate an aloofness to us mere mortals.

From my standpoint, this project has potential with a GPU app. BOINC regularly polls this project trying to find tasks for my Nvidia, even though I don't see any GPU apps. From what I know, the way data is analyzed and processed, I think a GPU would be able to process tasks much faster than a CPU. There's plenty of RAM to hold the process, and the multiple cores would allow for more data to be sent through. How hard would it be to implement a GPU version of Rosetta@home?

Hi Mark et al.

I think I understand the confusion here- we aren't commonly using Rosetta@home to predict the structure for proteins where we already know the structure (the closest we come to this is CASP).

However, we are heavily utilizing Rosetta@home to validate and test de novo designed proteins. In these cases, we've designed a totally new structure and protein sequence that has never existed before in nature. Then, we take the amino acid sequence which codes for our de novo protein and ask Rosetta@home how this sequence will fold. Finally, we compare each Rosetta@home model to our designed model and ask how well they match up, which I think is what you're seeing as a "known native solution." In reality, this isn't a "known" structure, rather it's one we're attempting to make. Evaluation with Rosetta@home is currently the most important verification criterion we use to assess the quality of our de novo designed proteins prior to testing in the lab.

As always, many thanks for donating your CPU hours; you make de novo protein design possible!

Cheers,
-Chris

I am just a volunteer and not in the BakerLab, but in very general terms, if you were to develop an algorithm that is to predict structures, and you test it by creating a pile of possible models of things of unknown structure... then what have to learned about how to improve your algorithm? Running it against known structures is how you prove your algorithm is working well, or came up with the same correct answer, or an answer with even better precision, or using dramatically less compute power.

I guess perhaps the perspective you are missing is that the aim of the project is not to "solve unknown structures", but to "develop generalized computer algorithms that are able to accurately solve unknown structures". (I'm not quoting anyone there, I'm just trying to denote a possible title that summarizes things)

I am curious about this as well.

By the way, how can you tell that the folding being done is of structures with a known solution?