Q. Why is my computer stuck on 1% ? *


A. This is a known BOINC and Rosetta@Home issue, Starting with Rosetta Version 5.06, a number of new features were added to Rosetta to prevent this problem. The first of these is a new "WatchDog" thread. The watchdog monitors progress made on the workunit, and if it appears to be "Hung" it will terminate processing and return any results produced. Work Units terminated in this way ARE awarded credits in a separate process run on the server data base on Friday of each week. In addition the automatic terminate feature is enguaged if a work unit exceess 4 times the user selectable "Time" setting.

If however you feel there is a problem there are a couple of things you can do about it, they should be done in the order here:

First make certain the work unit is actually stuck or hung =

Depending on how the Wu is configured, some may have over 1,500,000 steps in the first model and still not reach 1%. This can take over 5 hours of CPU time. There are a few even larger ones.

Between checkpoints (Saves to disk, which occur when the percent complete changes) the time to completion in the BOINC work tab, will increase instead of decreasing. This is because BOINC calculates the time to completion based on the number of CPU seconds that have passed and the percent complete. So if the CPU time rises and the percent remains the same, the time to completion will increase. When the running Wu checkpoints, the percent complete will suddenly jump up, and the time to completion will suddenly drop. Then the entire process will repeat until the next checkpoint, or the WUs finishes.

The time settings in your preferences have a lot to do with what the jumps will be as the WU progresses. If you have your time set to say 2 hours, and one of the large Wus comes along, it is possible for it to run for over five hours showing 1%, and suddenly jump to 100% and finish. If the Wu is one of the smaller ones, running with the same settings, it might only run 5 min or less, doing about 35,000 steps for each model, and the percent will jump to something like 5% and keep rising until it hits about 1 hour and 55 mins and finishes.

So look at the graphic display and see what is going on every so often on these longer ones.

The project has said they are working on "leveling" all of this out so there is not so much variation. Those Wu should start appearing soon.

If the Work Unit is really Hung -

1. suspend the Work Unit, BOINC Manager -> Work (tab) -> click on the Work Unit click the Suspend button (on the left hand side) then Resume button, wait for the computer to re-start the Work Unit (it will need to finish the new Work Unit it started, if it had another available) and see if it's still stuck, give it about 20min.
2. Shutdown BOINC, restart BOINC see if the Work Unit is still stuck, give it about 20min.
3. Reboot your computer. See if the Work Unit is still stuck, give it about 20min.
4. Abort the Work Unit, BOINC Manager -> Work (tab) -> click on the Work Unit that's stuck click the Abort button (on the left hand side).

Back to Top

Thanks to hugothehermit for his work on this FAQ.

Q. Why am I getting an error every time BOINC switches tasks?

In some cases interrupting the work in progress can cause the work unit to abort with a client error. Interruptions can include pausing or suspending either the Rosetta application, or the running work unit, shutting down BOINC, restarting your system during work unit processing, and updating a project. Updating a project may cause an application switch to occur at a time prior to when it normally would occur.

The way to prevent this error is to set your preferences located in your account information to "Leave applications in memory during application switching = YES".

This problem is a know issue for the Rosetta project and work is being done to adjust the system so this will not be necessary at some future date.


{Note: This setting will keep applications for all projects to which your system is attached in memory. On systems with marginal amounts of memory this may case system performance problems.}

Back to Top

Submitted by

Snake Doctor
Team MacNN

Q. What is project "Swapping" and how should I have it set?

Project swapping occurs if a particular computer is doing work for more than one project. This would be the case if you were running Rosetta@home, and any other BOINC project such as Protein Predictor@home, Einstein@home, or Climate predictor to name a few. The BOINC software installed on your machine regulates how much of your computers time is devoted to the work for each projects to which your machine is attached. When it is time for one project to allow another to project some computer time, the currently running application will stop and the one requiring processing time will start. This is call an "application swap".

There is an option in the user preferences to either keep applications (like Rosetta) that are inactive due to application swapping loaded in the memory of the computer while they are inactive, or remove them from memory. The default setting for this preference is to remove applications from memory during swaps.

For most projects this preference can be set either way. However, due to the way in which Rosetta stores data as processing proceeds, much processing time can be lost if the applications are not kept in memory during applications swaps. Moreover, when the BOINC software activates Rosetta to continue processing a partially processed work unit, an error can result during the reloading process. For this reason you should set your preferences to keep applications in memory during swaps.

Once set, this preference will apply to all active projects on your machine. For this reason you may see some performance issues on your system, such as slower operation, or the inability to load and run memory intensive programs. This would include things like video and image editing software, some audio and streaming video functions, Games, and multi media presentation packages.

Back to Top

Q. I am not connected to the internet all the time and Rosetta@home runs out of work, What can I do?

You should determine how often you will be connected to the internet, and adjust your project preferences to the number of days (up to 10) that you plan to be disconnected. By doing this your system will try to download enough work to keep the system busy for the period of time between connections.

There is an issue related to the loading of large queues of work beyond 7 days. In some cases the project may require processed data in a short time frame. When this happens the reporting deadlines for the work units may be less than 10 days in length. If you time between connections to the internet, is longer than the reporting deadlines for the work units on your system, you will not be able to return the results before the deadline and you will not receive credit for the processing you have done. Moreover this will have an adverse effect on the science project itself.

Back to Top

Q. How do I set Rosetta@Home to stay in memory?

A. To change your preferences to leave Rosetta@Home in memory, General Preferences Log in (if your not already) -> Edit Preferences (down the bottom) -> Leave applications in memory while preempted? Check yes and click the update preferences button, also remember to update BOINC. BOINC Manager and select "Projects"(tab) , select "Rosetta@home", and click "Update"

Back to Top

Thanks to hugothehermit for his work on this FAQ.

Why should I set BOINC to keep application in Memory?

This is less of a problem now that "Checkpointing" is more frequent for the Rosetta application.

However, If the application is removed from memory during an application swap, it will loose the work performed since the last checkpoint. In the case of Rosetta the checkpoints occur each time the percentage advances. If you do not keep the application in memory, and you set the swap interval to less than the time it takes your machine to reach a checkpoint, the work units can appear to be 'hung".

This is why the recommended configuration is to set "Keep applications in memory" to "YES". As an added protection, it is also recommended to set a value of nominally 120 min between application swaps. Either of these settings alone has been shown to reduce the problem, but they can be used togeather for better results

It should be noted that ALL BOINC projects suffer from loss of CPU cycles if the applications are not kept in memory. Any work that is not saved at a checkpoint before a swap, is lost when a swap occurs. On applications like Rosetta and Climate prediction this loss is significant (15 to 30 min). On projects like Predictor, SETI and Einstein, the loss is less but it is still there (usually 60 seconds using the default setting for writing to disk). People who wish to squeeze every cycle out of their machine, usually keep applications in memory for this reason.

It is important to note that the memory we are talking about is not actual RAM but in fact is virtual memory (on disk), so the actual impact of this is not that significant. In addition you can adjust how much memory is used by the application in this regard.


Question submitted by:
Dimitris Hatzopoulos
Team:
Greece United

How do I set the adjustable Work Unit time parameter in my Preferences ? What should I set it to ?

This parameter is adjusted by going to your "Account Page". On the Account page, there is a link to "View or edit Rosetta@home preferences". If you clink on the link to "Edit Rosetta@home preferences", you will find a Pull Down menu called "Target CPU run time". If you do not change this setting, all of your Rosetta@home Work Units will run in approximately 8 hours. This time will vary slightly but should be fairly consistent for a particular machine.

If you pull the menu down, you will be presented with options for times ranging from 2 hours to 4 days. Select the option that best meets the needs of your system. The project would prefer you select times from 8 hours and up to reduce the load on the servers, but this setting is totally up to you. If you have bandwidth concerns a longer setting will help reduce the bandwidth required to run Rosetta. It is best to allow your work queue to drain completely before making the adjustment and then allow Rosetta to resume work and download fresh work units under the new setting. This will allow the BOINC client to accommodate the new setting for project time management purposes.

Once you have made the change you must either update the project from the BOINC manager manually or wait for the system to contact the server in the regular course of processing before the change will take effect.

While the Rosetta application will attempt to respect this setting and process work units within the time selected, there will be some variation. This is because the software must adjust in increments of one complete model run. For some work units one model may represent a relatively short amount of processing time, on the order of a few minuets. For other Work unit types a single model can take a significant amount of time, on the order of a few hours. Each work unit will always complete at least one model before reporting results. In practical terms this means that if you have selected a short time setting, some work units may take significantly more time to process than your setting.

{EDIT: The following combines the information from a number of FAQs to present a more complete picture of how the "Time" setting works overall}

All of the new format WUs are generally physically (number of bits) the same size. The time factor tells the system how long you would "like" your system to work on a single WU creating different models as it goes. Based on the benchmarks done for that class of WU when they were created, the server knows how many models can be run for that WU in the time you asked for. In every case the WU will run at least one model no matter what you set the time to be. In any case your computer will be told how many models to run before returning the result as a part of the data that comes with the work unit. For small proteins this could be 30 models in 4 hours, for large proteins it might only be 1. In some cases it might take 9 hours to run a single model, and your system will spent 9 hours on the WU no matter what your time setting is, because all WUs run at least 1 model.

You can judge for your self if the protein you are working on is large or small by looking at the graphic. If there are a lot of "joints' in the protein, long strings, and it looks complex, it is large. Obviously small would be the opposite of that.

From a user stats point of view each WU represents a single result when it is turned in. The longer it runs the more credit it will claim. But from a science point of view each "model" represents a single result so each of your turned in results can represent anywhere from 1 - 100+ science results. That is why the default time is set to 8 hours (more science per WU). In most cases this will return between 1 and about 100 results depending on protein size. The faster the system the more models it can run in the alloted time. Because the models differ in size there is no way to calculate the number of credits per model. It is possible to make an estimate of credits per hour per system. The work unit itself has no bearing on this at all.

All of this means simply this. The project used to be based on having each WU produce a specified number of models for each protein run, no matter how long that took. say 60 models per WU. Now the system is set up to run for a certain length of time, no matter how many protein models that might produce per Work Unit, but it will always complete at least one model for each WU no matter how long that takes.

Now this can lead people to think they have a WU stuck when they don't. Depending on how the Wu is configured, some may have over 1,750,000 steps in the first model and still not reach 1%. This can take over 5 hours of CPU time. There are a few even larger ones.

Between checkpoints (Saves to disk, which occur when the percent complete changes) the time to completion in the BOINC work tab, will increase instead of decreasing. This is because BOINC calculates the time to completion based on the number of CPU seconds that have passed and the percent complete. So if the CPU time rises and the percent remains the same, the time to completion will increase. When the running Wu checkpoints, the percent complete will suddenly jump up, and the time to completion will suddenly drop. Then the entire process will repeat until the next checkpoint, or the WUs finishes.

The time settings in your preferences have a lot to do with what the jumps in percent complete will be as the WU progresses. If you have your time set to say 2 hours, and one of the large WUs comes along, it is possible for it to run for well over five hours showing 1%, and suddenly jump all at once to 100% and finish. If the Wu is one of the smaller ones, running with the same settings, it might only run 5 min or less, doing about 35,000 steps for each model, and the percent will jump to something like 5% and keep rising until it hits about 1 hour and 55 mins and finishes. By the way, that first 1% is the set up at the begining of the WU run. You can see that in the grafic display if you have it up when a WU first starts.

As a result of this behavior a number of people have asked how many checkpoint occur during the processing of a Work Unit?

There is no set number of checkpoints for a Rosetta Work Unit. All Rosetta Work Units will checkpoint when ever they complete a model. This will advance the percent complete counter in the BOINC manager. There is no connection between any particular percent complete and a checkpoint event because the length of a single model is variable. The persent complete is calculated using the length of time it takes to run a single model, divided into the run time set in the user preferences. So if you have a Work Unit set to run for 2 hours, and a single model will take 1 hour, the first checkpoint will occur at 50% complete. If the same Work Unit is set to run for 4 hours, the first checkpoint will occur at 25% complete. It is possible to have a Work Unit that only has sufficient time to run a single model, in which case the first checkpoint will occur at 100% complete, and the Work Unit will be ready to report.

So look at the graphic display and see what is going on every so often on these longer ones.

The project has said they are working on "leveling" all of this out so there is not so much variation. Those WUs should start appearing soon.

So now we get to the problem of forcing the system into a work deficit when you use the new Rosetta time feature.

BOINC does not know anything about any of what I just described. A lot of people who are used to the normal way BOINC controls the loading of the work Queue still have their systems set to a long connect time to get more WUs. But for the new Rosetta system this can cause you trouble, and it is unnecessary.

BOINC will ask for a certain amount of work (number of seconds of work) based on how much time you have left in your work queue. But it does not know that you can download what seems like a very small number of rosetta WUs, that in fact are large in terms of time because you have set the time for rosetta to a large number.

BOINC just downloads the WUs and suddenly they are taking a lot longer than BOINC expected. Now to be fair BOINC will adjust a little for this as it runs. And for short connection times (small work queues) it will adjust fairly well over a day or so, because it will figure out that the WUs are all about the same size and it will adjust the DCF to make things work But this does take a period of time where you should not make adjustments to the system so it can stabilize.

So, For Rosetta it might be best for farmers and people on low bandwidth, or modems who run only rosetta to readjust the system for a small queue. Say .1 days. Then set the time factor for a long runtime say 2-4 days. This will allow BOINC to think it should just get a few seconds of work to keep your system going, but it is really getting one or two WUs that will run for 2-4 days each. BOINC of course will try to connect about every 2 hours or so all day long, but if you are not connected (turn off network activity) or turn off your modem, it will just hold the results until you do connect. BOINC will take care of holding the results until then.

Now if you are on a constant internet connection with these same settings, BOINC will be connecting nominally the same 10 times a day, but it will just keep crunching rosetta for the same 2-4 days per WU until they are done. If you are running other projects under these conditions, they will be feeding and reporting all day long on the shorter queue using the standard BOINC reporting and queueing system.

So basically you have to play with the two parameters of Times to connect per day (queue size) and run length of the WU (Rosetta time setting) until you find the balance that fits your particular system requirements.

One caution of people who pay connection time by the packet is that if your connect time is set to a short length, it will send a few packet every time it tries to connect, but this should not be a large number. For people interested in local credit monitoring with the BOINC GUI stats tab, the stats will be more current.

Back to Top

A. I want to change my association with a team but how will this affect my credits?

Teams are part of the competitive aspect of running BOINC projects. All users of Rosetta@Home are free to create teams, joins teams, move from team to team, or run Rosetta as individuals. While the project may recognize the efforts of teams and their contributions to the proejct, Rosetta does not endorse any particular teem. Association with a team will not affect your individual credit count or score in any way, but you should be aware of the following factors related to teams.

1) When a member joins a team, he will show up under "team management" to the founder, but will not show up on the "active members" list until they are granted credit for a result.
2) Previous user credits are not applied to the teams total when he joins a team, except for CPDN sponsored projects (see wiki definition).
3) When a member leaves a team voluntarily, the credit he earned for the team stays with the team.
4) User credit is not affected by either joining or leaving a team.
5) If the founder removes a member then the members credit will be removed from the team score.
6) When a user quits a team, he's immediately removed from the founders "management functions screen". This means he'll no longer have access to your email addy, and can't kick you from the team.
7) Team founders have access to all team members email addresses
8) It can take up to a day for the username to be removed from the "active members" list after he leaves a team.
9) The line "Members(with and without credit" didn't add members who had no credit when I tested this.
10) The team founder shows on the "Active Members" list whether he has returned results or not while on the team.
11) The credit shown on the team statistics view https://boinc.bakerlab.org/rosetta/team_display.php?teamid=xxx is a members overall credit score, not necesseraly what they have contributed towards the team.

BOINC-wiki says the following about "team credit":

"The accumulation of Credit in your own account will never change regardless of membership on a Team. You will always accumulate the appropriate Granted Credit if you are on a team, you will accumulate the same Credit as if you are not on a Team.

When you join a Team, you join it with a zero balance. After you have joined a Team, the Granted Credit is added to your Total Credit balance and to the Team's Total Credit balance.

When you leave the Team, the Credit you earned while a member of that Team will stay with that Team. You do not take it with you to add to another Team's Total Credit balance; except for Climateprediction.net which uses the old SETI@Home Classic rule where the Team's Total Credit is a simple summation of the Total Credit earned by the Participants that are a member of that Team.

There is a special "Team Recruitment Thread" located in the Rosetta Cafe where teams may post information about their team and how you can reach them.


Information for this FAQ was provided by-
mmciastro - BOINC Synergy
Rollo
FluffyChicken - mauisun.org

Back to Top

How do I set the adjustable Work Unit time parameter in my Preferences ? What should I set it to ?

This parameter is adjusted by going to your "Account Page". On the Account page, there is a link to "View or edit Rosetta@home preferences". If you clink on the link to "Edit Rosetta@home preferences", you will find a Pull Down menu called "Target CPU run time". If you do not change this setting, all of your Rosetta@home Work Units will run in approximately 8 hours. This time will vary slightly but should be fairly consistent for a particular machine.

If you pull the menu down, you will be presented with options for times ranging from 2 hours to 4 days. Select the option that best meets the needs of your system. The project would prefer you select times from 8 hours and up to reduce the load on the servers, but this setting is totally up to you. If you have bandwidth concerns a longer setting will help reduce the bandwidth required to run Rosetta. It is best to allow your work queue to drain completely before making the adjustment and then allow Rosetta to resume work and download fresh work units under the new setting. This will allow the BOINC client to accommodate the new setting for project time management purposes.

Once you have made the change you must either update the project from the BOINC manager manually or wait for the system to contact the server in the regular course of processing before the change will take effect.

While the Rosetta application will attempt to respect this setting and process work units within the time selected, there will be some variation. This is because the software must adjust in increments of one complete model run. For some work units one model may represent a relatively short amount of processing time, on the order of a few minuets. For other Work unit types a single model can take a significant amount of time, on the order of a few hours. Each work unit will always complete at least one model before reporting results. In practical terms this means that if you have selected a short time setting, some work units may take significantly more time to process than your setting.

{EDIT: The following combines the information from a number of FAQs to present a more complete picture of how the "Time" setting works overall}

All of the new format WUs are generally physically (number of bits) the same size. The time factor tells the system how long you would "like" your system to work on a single WU creating different models as it goes. Based on the benchmarks done for that class of WU when they were created, the server knows how many models can be run for that WU in the time you asked for. In every case the WU will run at least one model no matter what you set the time to be. In any case your computer will be told how many models to run before returning the result as a part of the data that comes with the work unit. For small proteins this could be 30 models in 4 hours, for large proteins it might only be 1. In some cases it might take 9 hours to run a single model, and your system will spent 9 hours on the WU no matter what your time setting is, because all WUs run at least 1 model.

You can judge for your self if the protein you are working on is large or small by looking at the graphic. If there are a lot of "joints' in the protein, long strings, and it looks complex, it is large. Obviously small would be the opposite of that.

From a user stats point of view each WU represents a single result when it is turned in. The longer it runs the more credit it will claim. But from a science point of view each "model" represents a single result so each of your turned in results can represent anywhere from 1 - 100+ science results. That is why the default time is set to 8 hours (more science per WU). In most cases this will return between 1 and about 100 results depending on protein size. The faster the system the more models it can run in the alloted time. Because the models differ in size there is no way to calculate the number of credits per model. It is possible to make an estimate of credits per hour per system. The work unit itself has no bearing on this at all.

All of this means simply this. The project used to be based on having each WU produce a specified number of models for each protein run, no matter how long that took. say 60 models per WU. Now the system is set up to run for a certain length of time, no matter how many protein models that might produce per Work Unit, but it will always complete at least one model for each WU no matter how long that takes.

Now this can lead people to think they have a WU stuck when they don't. Depending on how the Wu is configured, some may have over 1,750,000 steps in the first model and still not reach 1%. This can take over 5 hours of CPU time. There are a few even larger ones.

Between checkpoints (Saves to disk, which occur when the percent complete changes) the time to completion in the BOINC work tab, will increase instead of decreasing. This is because BOINC calculates the time to completion based on the number of CPU seconds that have passed and the percent complete. So if the CPU time rises and the percent remains the same, the time to completion will increase. When the running Wu checkpoints, the percent complete will suddenly jump up, and the time to completion will suddenly drop. Then the entire process will repeat until the next checkpoint, or the WUs finishes.

The time settings in your preferences have a lot to do with what the jumps in percent complete will be as the WU progresses. If you have your time set to say 2 hours, and one of the large WUs comes along, it is possible for it to run for well over five hours showing 1%, and suddenly jump all at once to 100% and finish. If the Wu is one of the smaller ones, running with the same settings, it might only run 5 min or less, doing about 35,000 steps for each model, and the percent will jump to something like 5% and keep rising until it hits about 1 hour and 55 mins and finishes. By the way, that first 1% is the set up at the begining of the WU run. You can see that in the grafic display if you have it up when a WU first starts.

As a result of this behavior a number of people have asked how many checkpoint occur during the processing of a Work Unit?

There is no set number of checkpoints for a Rosetta Work Unit. All Rosetta Work Units will checkpoint when ever they complete a model. This will advance the percent complete counter in the BOINC manager. There is no connection between any particular percent complete and a checkpoint event because the length of a single model is variable. The persent complete is calculated using the length of time it takes to run a single model, divided into the run time set in the user preferences. So if you have a Work Unit set to run for 2 hours, and a single model will take 1 hour, the first checkpoint will occur at 50% complete. If the same Work Unit is set to run for 4 hours, the first checkpoint will occur at 25% complete. It is possible to have a Work Unit that only has sufficient time to run a single model, in which case the first checkpoint will occur at 100% complete, and the Work Unit will be ready to report.

So look at the graphic display and see what is going on every so often on these longer ones.

The project has said they are working on "leveling" all of this out so there is not so much variation. Those WUs should start appearing soon.

So now we get to the problem of forcing the system into a work deficit when you use the new Rosetta time feature.

BOINC does not know anything about any of what I just described. A lot of people who are used to the normal way BOINC controls the loading of the work Queue still have their systems set to a long connect time to get more WUs. But for the new Rosetta system this can cause you trouble, and it is unnecessary.

BOINC will ask for a certain amount of work (number of seconds of work) based on how much time you have left in your work queue. But it does not know that you can download what seems like a very small number of rosetta WUs, that in fact are large in terms of time because you have set the time for rosetta to a large number.

BOINC just downloads the WUs and suddenly they are taking a lot longer than BOINC expected. Now to be fair BOINC will adjust a little for this as it runs. And for short connection times (small work queues) it will adjust fairly well over a day or so, because it will figure out that the WUs are all about the same size and it will adjust the DCF to make things work But this does take a period of time where you should not make adjustments to the system so it can stabilize.

So, For Rosetta it might be best for farmers and people on low bandwidth, or modems who run only rosetta to readjust the system for a small queue. Say .1 days. Then set the time factor for a long runtime say 2-4 days. This will allow BOINC to think it should just get a few seconds of work to keep your system going, but it is really getting one or two WUs that will run for 2-4 days each. BOINC of course will try to connect about every 2 hours or so all day long, but if you are not connected (turn off network activity) or turn off your modem, it will just hold the results until you do connect. BOINC will take care of holding the results until then.

Now if you are on a constant internet connection with these same settings, BOINC will be connecting nominally the same 10 times a day, but it will just keep crunching rosetta for the same 2-4 days per WU until they are done. If you are running other projects under these conditions, they will be feeding and reporting all day long on the shorter queue using the standard BOINC reporting and queueing system.

So basically you have to play with the two parameters of Times to connect per day (queue size) and run length of the WU (Rosetta time setting) until you find the balance that fits your particular system requirements.

One caution of people who pay connection time by the packet is that if your connect time is set to a short length, it will send a few packet every time it tries to connect, but this should not be a large number. For people interested in local credit monitoring with the BOINC GUI stats tab, the stats will be more current.

Back to Top

I lost my password and can't log back into my BOINC account?

Your Rosetta account information will only work for the Rosetta project. If you wish to attach to another project, you must use the account information for that project.

There is no way to recover passwords.

You can reattach to an existing Rosetta project account using your project key. You can obtain the project key from the original e-mail sent to you when you set up your Rosetta account. If you have lost this e-mail you can recover the account key from your system in the following way -

1) Inside the BOINC directory on your system you will find a file named "account_boinc.bakerlab.org_rosetta.xml"

2) Using a text editor such as wordpad open the file named "account_boinc.bakerlab.org_rosetta.xml"

3) On about the third line of the file you will see something like "<authenticator>56Ca362e06cafffc701fg7s1fxxxxxxx</authenticator>"

4) Highlight the portion of this line that I have highlighted in color above.

5) Using the copy function (Windows = control-C, Mac = apple-C) copy that text, and close the text editor.

6) Using your browser navigate back to the login page of the project and instead of using the password login, use the account key login and "Paste" (Windows = Control-V, Mac = apple-V) the account key in the account key field.

7) Click ok and that should log you back into the project.

This will work for any project assuming you have been attached to that project with your system and have simply logged out. Simply use the account file for that project in the instructions above instead of the Rosetta account file.

Back to Top

---

Moderator9
ROSETTA@home FAQ
Moderator Contact

Q. I don't receive an E-mail? / My ISP is blocking my E-mail from Rosetta@Home?

A. This is usually caused by your ISP blocking the E-mail as spam, Even though you can join up without it I would suggest that you get a free E-mail account and use that, remembering that if you don't log on to these free E-mail accounts every so often then some of them will delete your account. I also as a general suggestion that I give to everybody (no inference that Rosetta@home could or would contribute to this should be taken) that you never use you ISP E-mail account for anything else than talking to your ISP as it's not funny being spammed on an account that you actually need.

Back to Top

Thanks to hugothehermit for his work on this FAQ.

---

Moderator9
ROSETTA@home FAQ
Moderator Contact

Q. Which ports does Rosetta@Home need open?


A. Port 80 (http) is used for most communications with the project servers. Port 443 (https) is used if the password is being exchanged . Ports 1043 and 31416 are used for local control as well as for remote control of a BOINC client. 1043 is preferred and 31416 is a fall back. Unless you are RPC'ing over the Internet don't open 1043 and 31416 in your non-local firewall specifically for BOINC.

Back to Top

---

Moderator9
ROSETTA@home FAQ
Moderator Contact

I am getting errors on some of my Work Units, What should I do ?

If ALL of your work units are getting errors, there may be something wrong with your BOINC set up. Read all the FAQs in this list to see if you can determine and fix the cause.

If you are only having a few errors during the normal course of running Rosetta, then you should look up the type of error under the BOINC "Message" tab, and report it on one of the following links in the Forum;

For errors related to Rosetta Version 5.16 - Go Here (Part II)

Retired threads
For errors related to Rosetta Version 5.16 (part I)- Go Here
For Errors related to Rosetta Version 5.13 - Go Here
For Errors related to Rosetta Version 5.12 - Go Here
For Errors related to Rosetta Version 5.07 - Go Here
For Errors related to Rosetta Version 5.06 - Go Here
For Errors related to Rosetta Version 5.01 or earlier- Go here

Back to Top

---

Moderator9
ROSETTA@home FAQ
Moderator Contact

Q. What is the URL of Rosetta@Home?

A. https://boinc.bakerlab.org/rosetta

Back to Top

Thanks to hugothehermit for his work on this FAQ.

gothehermit for his work on this FAQ.

---

Moderator9
ROSETTA@home FAQ
Moderator Contact

Q. Where can I find statistical information about Rosetta@home?

There are many sources of statistics for BOINC projects. One of the most widely used is BOINCStats..

The information for Rosetta can be found at the following links -

1) Overall Rosetta@home Project statistics
2) Host operating system statistics
3) Team statistics
4) Country statistics
5) Host Overview Statistics
6) BOINC Combined Statistics

You can also obtain your own user statistics from this site.

Back to Top

---

Moderator9
ROSETTA@home FAQ
Moderator Contact

Q. What is RALPH@home?

RALPH is an acronym which stands for Rosetta ALPHa test project. RALPH@home is the official alpha test project for Rosetta@home. New application versions, work units, and updates in general will be tested here before being used for production. The goal for RALPH@home is to improve Rosetta@home.

Please consider the following before deciding to join:

1) Since this project is a testing environment, applications and work units may be unstable at times.
2) Credits and other competitive statistics do not mean anything in this test project. Credits may be lost due to instabilities and may be reset at any time for testing.
3) There will not be a continual flow of work units. Work units will be issued only when necessary for testing.
4) We urge participants to not abort work units during testing.
5) Please set the resource share low for this project compared to other production projects in your RALPH@home preferences.

Please join us in our efforts over at RALPH@Home!

Back to Top

---

Moderator9
ROSETTA@home FAQ
Moderator Contact

Q. Is Rosetta@Home concentrating on a particular disease?

A. Dr David Baker "My research group is involved both in fundamental methods development research and in trying to fight disease more directly...

Malaria: We are part of a collaborative project headed by Austin Burt at Imperial College in London that is one of the Gates Foundation "Grand Challenge Projects in Global Health". Malaria is caused by a parasite that spends part of its life cycle inside the mosquito, and is passed along to humans by mosquito bites. The idea behind the project is to make mosquitos resistant to the parasite by eliminating genes required in the mosquito for the parasite to live. Our part of the project is to use our computer based design methods (rosetta) to engineer new enzymes that will specifically target and inactivate these genes.

Anthrax: We are helping a research group at Harvard build models of anthrax toxin that should contribute to the development of treatments. You can read the abstract of a paper describing some of this work at this link

HIV: One of the reasons that HIV is such a deadly virus is that it has evolved to trick the immune system. We are collaborating with researchers in Seattle and at the NIH to try to develop a vaccine for HIV. Our role in this project is central--we are using rosetta to design small proteins that display the small number of critical regions of the HIV coat protein in a way that the immune system can easily recognize and generate antibodies to. Our goal is to create small stable protein vaccines that can be made very cheaply and shipped all over the world "

Back to Top

Thanks to hugothehermit for his work on this FAQ.

---

Moderator9
ROSETTA@home FAQ
Moderator Contact

Q. Where can I learn more about Rosetta@home from the point of view of the project leaders ?


A. Dr David Baker has established a "Rosetta@home journal" Where he will add regular commentary about the project, its progress and many other "insider" aspects of Rosetta@home.

While it is the intent that the journal thread itself be kept clear of posts from users, there is a second thread for Comments and Questions related to the postings in the journal. If you are interested in the researchers perspective on the progress of Rosetta, and asking a question, please take a look as this unique feature of Rosetta@home.

Back to Top

---

Moderator9
ROSETTA@home FAQ
Moderator Contact

Q. What is the difference between Rosetta@Home and Folding@Home or Predictor@home ?

A. Dr David Baker "The goal of Folding@home is to determine how proteins fold given the sequence of the protein, and to apply this knowledge to study protein folding related diseases."

David Kim "Our project is similar to Predictor@home, in that we are trying to improve our methods by conducting research that is only possible with the computing power that a grid computing project can provide."

Back to Top

---

Moderator9
ROSETTA@home FAQ
Moderator Contact

Q. Is there a list of information links for Rosetta@home all in one place?

Please explore our website freely, but the following links will provide a detailed understanding of Rosetta@home and make your time here more enjoyable.

1) Dr. David Bakers Rosetta@home Journal, a running log of thoughts and commentary from the project Chief investigator.*
2) Comments / Questions on Rosetta@home Journal, where users can chat with Dr. Baker about his log entries and other science related concepts.
3) Rosetta@home Active Work Unit(s) Log, provides descriptions of the Work Units and proteins currently being examined by the project on your computer(s).*
4) Discussion- Proteins and Work Units, where users can discuss the work units described in the work unit log.
5) Rosetta Application Version Release Log, Announcements of new software versions and updates.*

6) Project Announcement Thread, Where the project provides announcements to the user community that may require user action.*
7) Improvements to Rosetta@home based on user feedback, a place for users to make and discuss general suggestions to the project team.
8) Discuss Rosetta Application Errors and Fixes (all Versions), a place to discuss application specific issues.
9) Rosetta@home FAQ, a collection of "Frequently Asked Questions" with answers about running Rosetta@home on your computer.*
10) Team Thread, a thread where teams can post contact information and recruit new members.

11) Personal Milestones, a place for users to report individual milestones in credit accumulations and competitions.
12) Moderators Contact Point, a place where users can contact forum Moderators for help or to report problems.
13) A letter to Rosetta@home users, a letter prepared by Rosetta@home users inviting increased participation and explaining why additional help is important.
14) RALPH Home page, the doorway to the Rosetta@home ALPHa test project, where new concepts in protein modeling are tested prior to production use.**

* NOTE: Threads listed above with an "*" are reserved for posting by project team members only. All other threads are open to topical user posts.
** NOTE: RALPH@home is NOT a production environment. Software testing is not for everyone. Please read the information provided here and here BEFORE attaching.

Back to Top

---

Moderator9
ROSETTA@home FAQ
Moderator Contact