This is an easy fix on our end of course.

The database issue that I mention on the news is also being dealt with in this update. In the current update we added a new database file that would allow us to automatically generate protein fragments on the fly which would significantly reduce the turnaround time for many targets we process on our automated server Robetta. We decided to remove this file since it increased the size of the database over 2x and the file would not be used for a majority of the our BOINC jobs, and some users have reported issues that might be related to this (issues of possibly hitting disk space limits, etc.) There are other options we can pursue that will not require adding this file to the R@h application package.

To avoid problems with disk space please find way to use only one instance of main database for all R@H WUs running at one BOINC client instead unpack it every once in a working folder(slot) for each run of each WU!
I discribed this issue in details in other thread some time ago: https://boinc.bakerlab.org/rosetta/forum_thread.php?id=5701&nowrap=true#73650
If you find way to use one instance of database then its size will not be a problem. But now it could definitely - on a computer with standart Core i7 CPU running R@H only to store 9 copies(8 - in slots folders +1 in project folder) of current database(minirosetta_database_rev50262.zip) use ~ 1400 Mb of disk space(+ LOT of disk access to unpack and delete ~1500 files per each WU start/end). With new database (minirosetta_database_rev52076.zip) it will be ~ 2100 Mb.
This numbers for database copies only - without counting size of all other R@H work files and WUs queue(or files from other projects if computers run few).
So due many DB copies you can easily reach the limits on the use of disk space set in the BOINC by default (if I remember correctly 3 GB or 5 GB depending on the version).
Second issue with disk space (hitting BOINC space limits set per individual Wus) can be fixed by usung only one intance of DB too.

P.S.
I d'nt know is BOINC allow this in standart way or need same workaround to do it, but it possible. For exaple Einstain@Home project use only one copy of database files and even a one copy of executables! - No matter how many WUs are calculated in parallel.

I need to say thanks to David.
The issue started today and it is solved today. We even got a quick response from the admins (David) early in the process. Very nice of you.

---

Greetings,
TJ.

Well, now the servers are getting slammed, I was 3/4 of the way downloading what I needed to get going again and it slowed to a trickle and then stopped all together. Oh well, guess this is going to take a while.

BTW, thanks David fo such a quick response and fix, way to go buddy!

It should be safe now with the new app update. If you have any 3.43 jobs cached or running, please cancel them and update your client to get the new app update.

confirmed working fine here with win7 x64 - Rosetta 3.45
Boinc 7.0.28 x64

Thanks again, that was fast.

/Mike

---

I finished my download and everything is working okay, no problems yet.

Windows XP Pro x64
BOINC v7.0.28

now all my comp worked norm
Thanks to David

In case it helps the findings, I've checked what I have currently running and found the following varied results on 3 PCs:-

1) 64bit AMD 4-core running up to date Windows7.
Had to abort three 3.43 jobs after noticing and minimising the screensaver pop-ups (always reappeared after closing these windows)
A days worth of cpu gone, all with 0.000% progress on them, after 11:37, 10:14 & 0:59 elapsed hrs.

2) 64bit AMD single-core PC (dual booted)
a) running up to date Windows XP Home SP3 (32bit).
The 3.43 job currently running appears to be normal (no pop-ups) so far, at 68.79% progress, 7:21 hrs elapsed hrs.
b) running Linux Mint 12 (64bit), KDE desktop.
One 3.41 job running normal at 45% progress 1:58 elapsed hrs.

3) 64bit AMD 4-core running Linux Mint 11 (64bit), Gnome desktop.
Two 3.45 jobs appear to be running normal at 52% & 60% progress, 1:18 & 1:39 elapsed hrs.
+ One 3.43 job ready to report at 100% after 3:43 hrs elapsed.

---

It should be safe now with the new app update. If you have any 3.43 jobs cached or running, please cancel them and update your client to get the new app update.

I can confirm 3.45 works without issues. Thanks for the quick response and update David. Rick

---

Can't get new WUs since I killed the ones I had for verion 3.43.

May I have been added to some kind of blacklist for because of dumping the bad WUs?

Can't get new WUs since I killed the ones I had for verion 3.43.

May I have been added to some kind of blacklist for because of dumping the bad WUs?

You have to be patient I think. There is a lot of network traffic at the moment as everyone needs the new app, zip files and WU's. Mine are still uploading. Some did but and are ready to report but will not leave the BOINC manager queue at the moment.

---

Greetings,
TJ.

Chris Miles, a graduate student in the lab, has been doing our application updates. He's the one to thank for getting a fix up as soon as we identified the issues (with help from everyone here!).

Thanks!


Yes, you have to be patient and ideally let the boinc client take care of getting new jobs. However, you should manually kill and abort 3.43 jobs on Windows 64 bit platforms.

For the last 2 or 3 days I have started getting what appears to be a 640x480 version of the mini-rosetta screensaver popping into view on the desktop.
I can't tell you what causes it or whether it synchronises with a boinc event, but will continue to monitor.

I am running boinc 6.10.36 widgets 2.8.10 under windos 7 ultimate 64-bit.

NickB

For the last 2 or 3 days I have started getting what appears to be a 640x480 version of the mini-rosetta screensaver popping into view on the desktop.
I can't tell you what causes it or whether it synchronises with a boinc event, but will continue to monitor.

I am running boinc 6.10.36 widgets 2.8.10 under windos 7 ultimate 64-bit.

NickB

Don't continue to monitor. Abort all the tasks that are using rosetta version 3.43 as said above multiple times.

---

This is an easy fix on our end of course.

The database issue that I mention on the news is also being dealt with in this update. In the current update we added a new database file that would allow us to automatically generate protein fragments on the fly which would significantly reduce the turnaround time for many targets we process on our automated server Robetta. We decided to remove this file since it increased the size of the database over 2x and the file would not be used for a majority of the our BOINC jobs, and some users have reported issues that might be related to this (issues of possibly hitting disk space limits, etc.) There are other options we can pursue that will not require adding this file to the R@h application package.

To avoid problems with disk space please find way to use only one instance of main database for all R@H WUs running at one BOINC client instead unpack it every once in a working folder(slot) for each run of each WU!
I discribed this issue in details in other thread some time ago: https://boinc.bakerlab.org/rosetta/forum_thread.php?id=5701&nowrap=true#73650
If you find way to use one instance of database then its size will not be a problem. But now it could definitely - on a computer with standart Core i7 CPU running R@H only to store 9 copies(8 - in slots folders +1 in project folder) of current database(minirosetta_database_rev50262.zip) use ~ 1400 Mb of disk space(+ LOT of disk access to unpack and delete ~1500 files per each WU start/end). With new database (minirosetta_database_rev52076.zip) it will be ~ 2100 Mb.
This numbers for database copies only - without counting size of all other R@H work files and WUs queue(or files from other projects if computers run few).
So due many DB copies you can easily reach the limits on the use of disk space set in the BOINC by default (if I remember correctly 3 GB or 5 GB depending on the version).
Second issue with disk space (hitting BOINC space limits set per individual Wus) can be fixed by usung only one intance of DB too.

P.S.
I d'nt know is BOINC allow this in standart way or need same workaround to do it, but it possible. For exaple Einstain@Home project use only one copy of database files and even a one copy of executables! - No matter how many WUs are calculated in parallel.

This would definitely save disk space. I don't know if it's an option with standard BOINC but I'll look into it and I'll also see if we might be able to implement this somehow.

thanks for pointing this out!

Could you guys possibly send abort commands, from the server, for 3.43 jobs? There are many computers that aren't monitored 24x7 by people.

Chris Miles, a graduate student in the lab, has been doing our application updates. He's the one to thank for getting a fix up as soon as we identified the issues (with help from everyone here!).

Thanks!


Yes, you have to be patient and ideally let the boinc client take care of getting new jobs. However, you should manually kill and abort 3.43 jobs on Windows 64 bit platforms.

Hi, (sorry I am a bit of a techno-moron)
Is someone up to doing a button by button guide on how to end this.
Thanks

Could you guys possibly send abort commands, from the server, for 3.43 jobs? There are many computers that aren't monitored 24x7 by people.

Chris Miles, a graduate student in the lab, has been doing our application updates. He's the one to thank for getting a fix up as soon as we identified the issues (with help from everyone here!).

Thanks!


Yes, you have to be patient and ideally let the boinc client take care of getting new jobs. However, you should manually kill and abort 3.43 jobs on Windows 64 bit platforms.

The run time limit on one of our test machines was less than 3 days (depends on the client benchmarks) so these jobs should flush out eventually.

So far, I have seen the problem only under 64-bit Windows 7 with BOINC 7.0.28.

Same here -- BOINC 7.0.28, 64-bit Windows 7 (SP1), Minirosetta 3.43. Pops up 12 windows (Core i7-3930K CPU, 12 virtual cores) each of which looks like what you'd see if you had the screen-saver running, none of which are doing anything other than taking a core away from other BOINC projects.

It seems to have started with the Minirosetta 3.43 update...

L.

- Fixed :-) Thank you ever so much!

So far, I have seen the problem only under 64-bit Windows 7 with BOINC 7.0.28.

Same here -- BOINC 7.0.28, 64-bit Windows 7 (SP1), Minirosetta 3.43. Pops up 12 windows (Core i7-3930K CPU, 12 virtual cores) each of which looks like what you'd see if you had the screen-saver running, none of which are doing anything other than taking a core away from other BOINC projects.

It seems to have started with the Minirosetta 3.43 update...

L.

Why not abort these tasks as has been reported as the fix on the front page and all over these forums?

---