After a recent crash of BOINC, when I lost six weeks and 85% of my sulpher run, I noticed on these boards that a lot of volunteers are a little frustrated and discouraged by crashes. I wonder if it would be possible for the software to automatically make a periodic backup of the critical files, so the program could restart and pickup where it left off after a crash. I would think that only the parameters for a recent state would need to be saved, so there should be little drain on disk space.

Thanks,
Steve

---

It\'s not the backup that\'s the problem, but the restore.

BOINC is a \'universal\' program, used by a lot of people to run multiple projects.
Some of the info for ALL projects appears, intermingled, in a single file, so when you restore for one project, you restore for all of them.
The same thing applies for people with a single project, but running a hyperthreaded processor, or a dual core processor.

As far as I know, ALL the other projects are of short duration, only lasting hours to a few days, so there isn\'t the need for a backup.
As BOINC is written and supported by the University of California, Berkeley, the home of the biggest project SETI, they aren\'t very interested in building it in.

The files that need to be backed up are scattered through several folders, and it\'s best to simply stop and exit from BOINC, then copy the entire BOINC folder to somewhere else.
Some people on the BBC project use Suitcase for backups.

For those with stable computers, a crash can often be automatically recovered from without problems. My computer has done this several times during power problems without my even being at home.

It\'s a wee bit more complicated that you think, Steve. Many files are involved and the process is dynamic. It cannot be allowed to get out of sync. It\'s true that this is a CPU-heavy Project but it is also, despite Carl\'s efforts to reduce I/O, a heavy-hitter on the hard disk.

Manual backups are tried and true and are the safest bet.

That said, if you\'re running the BBC flavor of the Project, it\'s long been done -- and documented: BBC auto-backup:
http://bbc.cpdn.org/forum_thread.php?id=2748&PHPSESSID=6e4825ae7d7f83b1fad45b755f0ad6ec#11915
http://bbc.cpdn.org/forum_thread.php?id=2748

[Edit: Oops, you beat me to it, again, Les. My \"typing\" scores again (something like the US Soccer team).]

---

"We have met the enemy and he is us." -- Pogo
Greetings from coastal Washington state, the scenic US Pacific Northwest.

Thanks Astro and Les,

At least I understand now why it might not be easy to write an autobackup that will work well. I read the post from Richard Rodway about his autobackup for the BBC version (I think I am running that flavor, but I\'m not entirely sure); but, it seems like it might be more trouble than it is worth, and I don\'t think I want to do a beta test.

While I\'ve got you here, I have a related question. I completed one sulpher run and two runs crashed. My question: is there any reason why I can\'t delete the three sulpher folders and any file in the containing folder with the name \"sulpher ...\" (my current project is \"hadcm ...\")? It looks like that would save me two or three gigs of hard disk space.

Thanks,
Steve

It\'s a wee bit more complicated that you think, Steve. Many files are involved and the process is dynamic. It cannot be allowed to get out of sync. It\'s true that this is a CPU-heavy Project but it is also, despite Carl\'s efforts to reduce I/O, a heavy-hitter on the hard disk.

Manual backups are tried and true and are the safest bet.

That said, if you\'re running the BBC flavor of the Project, it\'s long been done -- and documented: BBC auto-backup:
http://bbc.cpdn.org/forum_thread.php?id=2748&PHPSESSID=6e4825ae7d7f83b1fad45b755f0ad6ec#11915
http://bbc.cpdn.org/forum_thread.php?id=2748

[Edit: Oops, you beat me to it, again, Les. My \"typing\" scores again (something like the US Soccer team).]

---

Hi Steve.

There\'s no problem with deleting folders of models that have failed or finished.
The new TCMs will clean up after themselves, provided that they don\'t crash, so that will be a bit easier.

Careful, though, not to delete anything with \'SULPC\'. (All those Sulphur Runs were to generate input files for the Coupled Models we\'re running now...)

Best of luck, Steve.

---

"We have met the enemy and he is us." -- Pogo
Greetings from coastal Washington state, the scenic US Pacific Northwest.

After my first posting of this issue 10 days ago, I have been running a hadcm model. When I checked this morning the project had vanished from BOINC Manager and a new hadcm model had started running.

Sorry guys, of the four work units (three Sulphur and one Hadcm) I have attempted since I joined March 2 only one finished successfully. Until you can get a more robust way to run ClimatePrediction I\'ll have to bow out; I am afraid that my CPU is burning more BTUs than the information I can provide is worth!

I know the problems you face are immensely difficult, and I believe the ClimatePrediction enterprise is very important. Best of luck to you. I\'ll keep my eye on these message boards and try again in a few months if it seems things might have improved.

Kind regards,
Steve

---