What will your tasks be called so we know when they come to our systems?

Hi!
My computer is crunching something like this at the moment:

MVH_2s_K_2q6m_ProteinInterfaceDesign_20110505_26665_45_0

And I think this must be what we're talking about ;)
Am I right?

Hey, this is correct! I'll be submitting a lot of different jobs for these guys with different strategies, but all of them will begin with "MVH_" and will contain "ProteinInterfaceDesign" in the middle!

I am running a couple of these tasks and need to reboot my computer and do not want to lose hours of core time when there is some way of avoiding this. I cannot sit for ages checking on the task properties.

Is it possible to predict when a checkpoint will take place?

I am running a couple of these tasks and need to reboot my computer and do not want to lose hours of core time when there is some way of avoiding this. I cannot sit for ages checking on the task properties.

Ditto on complaint. Four hours between checkpoints is a bit much!

BTW, I have a program manager that I use solely for watching when tasks checkpoint. I have EF Commander Free permanently pointed at the "...Application DataBOINCslots" folder.

This program updates dynamically whereas the Properties window is a snapshot.

I am running a couple of these tasks and need to reboot my computer and do not want to lose hours of core time when there is some way of avoiding this. I cannot sit for ages checking on the task properties.

Ditto on complaint. Four hours between checkpoints is a bit much!

BTW, I have a program manager that I use solely for watching when tasks checkpoint. I have EF Commander Free permanently pointed at the "...Application DataBOINCslots" folder.

This program updates dynamically whereas the Properties window is a snapshot.

Thanks for the feedback, we're looking into this!

I am running a couple of these tasks and need to reboot my computer and do not want to lose hours of core time when there is some way of avoiding this. I cannot sit for ages checking on the task properties.

Ditto on complaint. Four hours between checkpoints is a bit much!

BTW, I have a program manager that I use solely for watching when tasks checkpoint. I have EF Commander Free permanently pointed at the "...Application DataBOINCslots" folder.

This program updates dynamically whereas the Properties window is a snapshot.

Thanks for the feedback, we're looking into this!

Also, have you been having problems with one particular set of jobs, or is it a more general problem with many different Rosetta@home jobs?

Hi everybody,

Our paper describing the design of flu inhibitors using Rosetta @ Home has just been published as a Research Article by Science.

To summarize the results, using the resources provided by your computers we were able to identify ~80 designed proteins that might be candidates as flu diagnostics and inhibitors. Two of these proteins bound to Spanish and avian flu hemagglutinin quite tightly and one of them was crystallized in the presence of Spanish flu hemagglutinin to show that the designed interaction is exceptionally accurate.

Beyond the specific application to the flu, your resources have been extremely useful in getting our methods up to scratch to deal with this and other very challenging problems. If you follow some of the previous posts in this thread you can see the sort of problems that we're hoping to address with this new method and your contributions. Hopefully, these will help address some significant outstanding challenges in the development of antivirals and in studying recalcitrant biological questions.

---

[quote]I am running a couple of these tasks and need to reboot my computer and do not want to lose hours of core time when there is some way of avoiding this.

Ditto on complaint. Four hours between checkpoints is a bit much!

Thanks for the feedback, we're looking into this!

Also, have you been having problems with one particular set of jobs, or is it a more general problem with many different Rosetta@home jobs?

I'm fairly sure it was one of the Measles Protein interface design tasks - MVH etc. Most tasks update ok.

@ Sarel. It's good to see the results of our crunching being of benefit.

@ Shawn. I have a preference of 4 hours (i.e. 14400 seconds) of runtime. One of the MVH tasks (this one) ran for 21381 seconds and yielded a paltry 2.65 points credit. It completed only 5 decoys.

Another task (second one) ran for 27798 seconds and completed 12 decoys and I received 59.17 points, also well below the average rate for this machine on Rosetta.

Both of these tasks had watchdog force a shutdown. What occurred to me is that each decoy seems to take quite long to complete causing the last one to run well beyond the preferred work unit run time. It appears that the forced shutdown by watchdog is wasting valuable crunching time.

What to do about this is difficult to answer:
1. Should we increase the preferred runtime so that the proportion of time wasted when watchdog ends the unit is reduced?
2. We are not able to select different types of work units for each profile (as is the case at WCG) in order to minimise time lost. This would help.
3. Does checkpointing occur only at the end of each decoy? Is it possible to change this?
4. Is it possible to reduce the run length of the decoys?

From observing my own machine, and your comments, it seems that some models are taking dramatically longer (say 5x) then others. This is why the runtime estimates are difficult. When the first 4 models complete in say 3 hours, one would estimate there is easily time to complete one more within your 4hr preference, and so one more begins. But that 5th one happens to run for over 4 hours itself (it takes 4 hours over preferred runtime for the watchdog to be envoked). I should point out that the reason the watchdog waits 4 hours after end of runtime preference is that this is typically enough time to complete that last model and end without the watchdog's intervention.

This is also the reason for sporatic credit granted. If you happen to run without hitting a long-running model, you will get better credit, because credit is granted on a per model average of runtime, across all project hosts, for the specific protein and method being used. Since others are often hitting a long running model in their run, their average time per model swings higher then the machine that got lucky and did not hit any of those.

Changing the runtime preference really doesn't improve you odds, it just depends on whether the last model under review at the end of the runtime preference happens to be long-running.

---

Rosetta Moderator: Mod.Sense

@ Sarel. It's good to see the results of our crunching being of benefit.

@ Shawn. I have a preference of 4 hours (i.e. 14400 seconds) of runtime. One of the MVH tasks (this one) ran for 21381 seconds and yielded a paltry 2.65 points credit. It completed only 5 decoys.

Another task (second one) ran for 27798 seconds and completed 12 decoys and I received 59.17 points, also well below the average rate for this machine on Rosetta.

Both of these tasks had watchdog force a shutdown. What occurred to me is that each decoy seems to take quite long to complete causing the last one to run well beyond the preferred work unit run time. It appears that the forced shutdown by watchdog is wasting valuable crunching time.

What makes you think the watchdog forced a shutdown? The line (from the stderr out):
BOINC :: Watchdog shutting down...
appears for all of the workunits including those ending just prior to reaching the preferred runtime. The watchdog will shut down mid-model once the workunit has reached the preferred runtime plus 4 hours. Neither of your examples had run that long. I did once speculate that new conditions in addition to the runtime limit and the number of models limit had been introduced but never received any response. In that case though, workunits were ending far earlier than expected but completing far fewer than 100 models.

I checked my MVH tasks for credit and mine too seem to receive fewer credits than average (but then I don't usually pay attention to credits so this is a pretty wobbly impression). However I did complete far more models than you, 389 and 226 in just under 10 hours for 95.72 and 75.44 credits. Generally speaking, this discrepancy just means that this particular type of workunit runs less efficiently on your(my) machines than on other machines compared to the efficiency with which you(me) run other types of workunits. Given the very large variety of workunits on Rosetta this is bound to happen occasionally. I suppose it's possible that the initial second per model estimate was dramatically wrong(a typo perhaps) and everyone's credit is significantly less than expected. In your case you most likley hit upon an interesting model quite early on and so didn't complete many models in total, thus low total credit. Mod.sense wrote a nice explanation of how this works but I can't put my finger on it at this moment.



Best,
Snags


edited to add: Wow, I really am a slow writer. :/

And to add my appreciation to the scientists for posting here. Though you post too infrequently to satisfy when you do post you do an excellent job of explaining what you are working on. Thank you.

(That said, I still fantasize about a catalog cross-referencing proteins and strategies so one could know what was being worked on by looking up the workunit name.)

Thanks for the response, Mod.Sense.

I agree with you:

Changing the runtime preference really doesn't improve you odds, it just depends on whether the last model under review at the end of the runtime preference happens to be long-running.

However, what I mean is that the proportion of my total run time which did useful crunching will be higher if a longer target CPU run time were selected. If I had a 16 hour run time preference, I would waste a much smaller proportion of my crunching time if 4 hours were wasted on every work unit than would be the case if I merely used the default of 3 hours per work unit and then wasted 4 hours at the end of each one.

Should the administrators not be suggesting that we increase this run time preference if the machine is always on? In particular since it seems that there is no way of determining (or selecting) which work unit type we will receive. In my limited experience, the MV-H tasks seem to be prone to this long checkpoint issue.

Warped, actually, since even the long-running models generally will complete before the watchdog steps in, it is not a major benefit. But I see your point. If any effort is being wasted, then having fewer chances for it to occur (i.e. fewer WU completions per day) would further minimize any impacts.

Snags, yes the watchdog shutting down message is normal. It indicates that the watchdog, and other processes are ending normally... not that the watchdog has taken any action.

---

Rosetta Moderator: Mod.Sense

Let's get back on-topic in this protein-protein interfaces thread. We take the rest of the discussion back to other threads.

---

Rosetta Moderator: Mod.Sense

Mod - maybe you can move the other discussion to whatever place it belongs to get this thread back in shape (you can delete my post after you move the non topic discussion)

Hey guys, thanks for the feedback on the MVH jobs. I'll see what I can do to keep the tasks more manageable.

I wanted to address some of the issues posted recently by Rosetta@home users in this thread, as they pertained specifically to protein interface design.

As you might be aware, these types of jobs (including my MVH ones) tend to be a bit "jumpy" in terms of how long the trajectories take. Sometimes, one hour of CPU time might yield a lot of structures (and 100 credits). Other times, a trajectory on one model might take a long time, and nearly 6 hours of CPU time might yield less than 3 credits, as unfortunately happened to Warped. The amount of credit granted is normalized for each job type, so hopefully next time you are assigned one of these jobs, you'll be lucky enough to get more credits.

If you are assigned one of the longer tasks (and we have no way of knowing beforehand which tasks are longer), you unfortunately won't get as many credits. But on the other hand, these longer trajectories tend to result in better design models--if you're naturally optimistic, you might be happy that you've stumbled into one of the tasks that are more likely yield an MVH inhibitor! =)

In the meantime, I will be submitting new MVH jobs but managing the workunits so that don't take as long to compute and are less "jumpy" in terms of overall length. Sarel has also developed new options for our protocols that would also help in this regard, and David K and other members of the lab are working hard to get those features integrated into Rosetta@home.

Thanks again for your contributions!

I promised an update on my Ebola project, and I've recently focused more of my time on this target, so I thought I'd give you guys another update!

As you might know, Ebola virus causes terrible hemorrhagic fever, which usually results in death in the patient 6-9 days after the onset of symptoms. Unfortunately, there are currently no therapeutics available for human use, but hopefully, we can do something to change that.

Recently, researchers at the Scripps Institute were able to determine the crystal structure of the Ebola virus surface glycoprotein (GP) in conjunction with a neutralizing antibody (KZ52) from a human survivor of a 1995 outbreak in the former Zaire. KZ52 interacts with both the GP1 and GP2 subunits of the GP complex, but more so with GP2.

We're trying to use the hotspot method (which I mentioned during my discussion of the measles project) to design our protein, which would bind GP in roughly the same place that KZ52 also binds. A very preliminary picture of some of stubs we're considering looks as follows:



Of course, computational design of protein binders is tricky, and each specific project also has its own particular challenges. In this case, there isn't much surface area for KZ52 to interact with GP, but we're hoping to design a binder that can make more use of the surface that is available.

Thanks once again for being involved with Rosetta@home! I'm really excited about this project, and I would love to share it with everyone, so once again, please let me know if you have any questions or comments!

Hello,

as I have described in the LigDes thread originated by Mr. Moretti, I am pretty interested in the scientific progress of Rosetta@home, including projects mentioned in this thread like Ebola virus surface glycoprotein research.

As it would be nice to keep up everyone with your science, please do not hesitate to post us some updates! :) They are always very welcome. :)

Best Regards from Warsaw,
a.m.
BOINC@Poland

In response to recent requests for an update on what we are doing with your donated computer time, here goes:

The communication networks inside every one of our cells depend in many cases on proteins interacting with one another. When these communication networks go awry, cancer often results. I'm using Rosetta to design proteins that will interfere with three protein-protein interactions often involved in cancer. I'll tell you about the first project below, and the others shortly.

Project 1:
The first of these interactions involves a protein called p53 and another called Mdm4. p53 is a communication hub in our cells, used to translate information about unwanted DNA mutations into an effective response by the cell. The activity of p53 is modulated by a pair of other proteins, Mdm4 and Mdm2, which act to shut off p53 when all is well. Cancer cells depend on DNA mutations to stay alive and so they find ways to shut off p53, either by reducing the amount available p53 or by expanding the amount of available Mdm4 or Mdm2. that way p53 doesn't rat out mutations that the cancer might need to survive. Scientists have spent a lot of time trying to understand how Mdm4 and Mdm2 work. They do this by shutting off Mdm2 and Mdm4 with drugs. There are even drugs that will shut off just Mdm2. There are no drugs, however, that will shut off just Mdm4. So I'm trying to make one. This is a tricky process since Mdm2 and Mdm4 are very similar, making it hard for proteins to tell them apart.

I aim to use Rosetta@home to design proteins that will attach to Mdm4 while ignoring Mdm2. I hope to provide a research tool to scientists that work on Mdm4, Mdm2 and p53, allowing them to better understand how this critical communication hub works. I hope that this leads to new cancer treatments. So far, I've used Rosetta@home to design 26 proteins that should attach to Mdm4 but not Mdm2. Many of the designed proteins do stick to Mdm4, but unfortunately, they also stick to Mdm2. I am working on a third round of design using a new approach that I hope will work. For more info about the proteins involved in this project, please visit the links below:





Thanks for lending us your spare computer time. Projects like this one require so much computational time that they would be impossible without you. I'll post more about the other two projects at a later date.

How do I know I am running your WU's?