So I found a setting in Rosetta@home preferences and it's called Target CPU run time, I changed it to one day from three hours; now I'm noticing that tasks take a day to complete which is fine for me, but does that mean Rosetta@home will find the lower energy state for that protein, than if the Target CPU run time was only 3 three hours? So what is better? I don't care about points I'm interested in predicting the lowest energy states.

Yes, the longer the task runs, the more <attempts> it will make to find the lowest energy state.
That's not to say it will find the lowest energy state, but the more attempts the better

---

Just wondering.

If after changing the settings the same task is calculated by the processor for a longer time - will the points be the same or will they be increased?

And what does the information on the task “Estimated computation size 80,000 GFLOPs” mean -- if the amount of calculations can vary greatly through settings?

---

I noticed that with this setting you can actually reduce the computation time almost immediately.
This is convenient if, for example, the computer clearly does not have time to finish the calculations before the deadline.

For this, it is necessary not only to change the settings on the site, but also restart the BOINK, ask him to contact the project and wait a bit.

Credit is based on completed work. Completed work is measured in model (called "decoys" in the outfiles). The more models you complete, the more credit you receive, and the better your chances of producing a low energy model. Since most WU models take less than 30 minutes, the difference between a 3 hour work unit and a 24 hour work unit is really just whether your machine searches 6 models, or 48. Someone else comes along with a machine that does the same models in 20 minutes, they will complete 9 models in 3 hours and receive credit for 9 models.

Yes, changes to the runtime preference can take effect on work you've already downloaded. So, be careful that you don't dramatically reduce the preference or the watchdog might believe a long-running work unit is running abnormally long. Also don't dramatically increase the runtimes, or BOINC Manager is very likely to request too much work. I always suggest just moving the setting a notch or two each day in the direction you wish to go.

---

Rosetta Moderator: Mod.Sense

Thank you so much! -)

And what do these 80.000 GFlops belong to?

And what do these 80.000 GFlops belong to?

It's just an Estimate of the work to be done to seed the Estimated completion times.
As you've probably noticed, the Estimated completion time when you first start processing work (or first do work with a new application) are initially a long way out, but as work is returned over a few weeks they will end up getting very close the the actual processing time.

---

Grant
Darwin NT

That is, 80.000 GFlops refers to the one model or to the task as a whole?

That is, 80.000 GFlops refers to the one model or to the task as a whole?

The Task as a whole.

---

Grant
Darwin NT

Thank you very much!

Thanks for this info. So for a machine running R@h 24/7 are there any pros & cons for changing from the "Target CPU run time" default of 8 hours?
- for example, dropping it to 6 hours.
- for example, upping it to 10 hours.

I'm trying to understand how this setting works in practice.
1) Are different types of tasks downloaded?
2) Are there changes to the amount of points awarded?
3) Any benefit to the R&h project? (i.e., they need more people to take on 10-12 hour tasks.)

Thanks in advance.

Thanks for this info. So for a machine running R@h 24/7 are there any pros & cons for changing from the "Target CPU run time" default of 8 hours?
- for example, dropping it to 6 hours.
- for example, upping it to 10 hours.

I'm trying to understand how this setting works in practice.
1) Are different types of tasks downloaded?
2) Are there changes to the amount of points awarded?
3) Any benefit to the R&h project? (i.e., they need more people to take on 10-12 hour tasks.)

Thanks in advance.

For the project, I don't think there's any benefit in changing runtimes from the default. It's a balance of overall workload and server capacity.
For individual users, it may help people if they have irregular access to the internet, but otherwise almost none either way.

---

1) Are different types of tasks downloaded?

Nope.
They're the same Tasks, they just run for more or less time.

2) Are there changes to the amount of points awarded?

If you run the Task for longer, you will get more Credit. You run it for less time, you get less Credit; but the amount of Credit per hour remains pretty much the same so the RAC will remain (roughly) the same.

3) Any benefit to the R&h project? (i.e., they need more people to take on 10-12 hour tasks.)

Nope.
The project prefers you to use the default. That way if there is a major change to the application and it doesn't need to run as long to produce useful results, or it needs to run longer to produce useful results, then the Project changing it's default value will mean that all the computers using the default will automatically make the change. Systems using non default times will end up either running for longer than they need too, or not running long enough to produce useful results.
As things are, some Tasks will finish before the Target CPU Run time, and others may run longer than the Target CPU Runtime if they need to in order to finish off a decoy.

---

Grant
Darwin NT

Thanks for answers, I appreciate the insights.