A slower machine can still do useful climate modelling work :

* Try running the \'slab\' model rather than the \'coupled\' model. The slab model has much smaller requirements for CPU time and memory. You can control which you run (via Your Account / Project Preferences / Set HadSM3 to \'ticked\', and HadCM3 to \'unticked\').

Alternatively, you could run the http://www.apsathome.org/ project, which is doing localised atmospheric physics work which will be used to improve climate models in the future. The work units only take a few hours even on older PCs.

For us who are crunching CPDN 24/7 and nothing else, is it better for the project if we do the longer models? My PC will run for a long time anyway and maybe its better if I run 4 long models then?

In principle, the project can arrange how models are given out from the queue - and I take that to be an indication of their priorities. I\'m certainly not aware of any other indication of their priorities. However, I do also use the preferences to force downloading of slab models onto machines with only short-term availability.

Hi Steinar

The way our preferences are implemented by the server (see the second post here) means we can\'t choose between 80 and 160-year models. But both are pretty long! The HADSM slabs seem to be extremely popular, so anyone who chooses to run the HADCM 80 or 160 yr coupled models is doing a very useful job.

The 80 and 160-year models are in the server queue and ready for download to members in batches ie large groups created at the same time. So if you receive one 160-year model and then download a second model, the second will probably also be 160 years.

If you want some variety, the HADAM models are still available from the Seasonal Attribution Project.

---

Cpdn news

On cpdn, the slab models are being re-run for a project in Germany, so the Oxford researchers are more interested in the long, Coupled Ocean models.

On SAP, the shorter models are part of a PhD or some such, of the person running that project.

But all of the climate models are of value to some group of people.

---

Backups: Here

I hate opening new topics and this thread covers at least part of my question:

So far I\'ve crunched one BBC model to completion and a second which went negative pressure around year 2050 and crashed. Then I took it easy doing a bit of Rosetta or resting the screaming fan during the warmer weather; just over a week back (happy now for the waste heat to warm the room) I attached to CPDN and poked around with my global preferences - one effect being to kick start my second CPU core (which I didn\'t entirely realise was there to use separately) so it\'s now crunching two tasks at a time.

I was slightly surprised to get an hadsm3 slab model which I thought was superseded now (noting also Les\'s point in the previous message), however a small WU is actually quite good to get in the swing of things again. I\'ve let the pc run 24hrs a day since then to get a flying start and this task is now over a quarter done and is close to the end of phase 1 - although the graphic claims it is a 1810 to 2050 task which doesn\'t make too much sense for a 45yr model. Any thoughts?

Then, a couple of evenings ago, I was reading some of these threads and wondered weather to set cpdn to \'won\'t get new tasks\'; but by morning it had downloaded an 80yr coupled hadcm3i model and started crunching it in the second core. This had the effect of entirely kicking out tasks both on Rosetta and LHC (the latter miraculously having few days work just as I was getting going again myself) with a message saying computer over-committed and switching to earliest due scheduling as others have mentioned above.

This coupled model very oddly has a deadline of 1901 no doubt a reason for the changed priorities!! When I had to restart the local BOINC manager after a glitch I got the following message in RED in the log:
\"Task hadcm3iozn_cpdf_2000_80_95898652_0 is 133038.36 days overdue.
You may not get credit for it. Consider aborting it.\"

Meanwhile I\'ve suspended the task and set cpdn to no new tasks; does everyone agree that to abort is the best action to take on this one? I\'d only done 10hours work before pausing it.
I won\'t replace it until the slab model is nearly finished (or turns iceworld blue!), I\'ve set the cpdn prefs to get TCM models only ready in advance for this.

Also despite trying to give cpdn slightly over half the resource share, I find occasionally the other two tasks preempt the cpdn model and either a pair of Rosettas or a Rosetta and LHC run for a short while. Since climate models are so long they can never catch up the lost time - it\'s a sort of reverse hogging to the other situation mentioned. Now LHC is out of work again the cpdn and rosetta tasks seem to be coexisting happily.

I upgraded the manager once last year but I\'m still using boinc v.5.4.11, as it ain\'t broke I didn\'t think I\'d risk disturbing the merry crunching - at least not until the slab model is finished and without any work to lose. I did see comments in another thread about a v.5.10.xx giving teething troubles, is there any advantage moving to either 5.8.16 or 5.10.20?

I also saw advice for former BBC modellers to move the working hard disk folder from the BBC CCE one to the default BOINC program files folder but there were no instructions on how to tell it to do this. Again I\'ve left well alone as it also ain\'t broke - unless anyone has clear specific instructions otherwise.

TIA for any help. Here is a relevant extract of the message log with info on my system; I\'m no hard-core techie just a ordinary long-standing pc user:

16/10/2007 18:32:37||Starting BOINC client version 5.4.11 for windows_intelx86
16/10/2007 18:32:37||Data directory: C:\\Program Files\\Climate Change Experiment
16/10/2007 18:32:38||Processor: 2 GenuineIntel Intel(R) Pentium(R) 4 CPU 3.40GHz
16/10/2007 18:32:38||Memory: 1023.50 MB physical, 2.40 GB virtual
16/10/2007 18:32:38|BBC Climate Change Experiment|URL: http://bbc.cpdn.org/; Computer ID: 98608; location: ; project prefs: default
16/10/2007 18:32:38|rosetta@home|URL: http://boinc.bakerlab.org/rosetta/; Computer ID: 330602; location: home; project prefs: default
16/10/2007 18:32:38|climateprediction.net|URL: http://climateprediction.net/; Computer ID: 781257; location: ; project prefs: default
16/10/2007 18:32:38|lhcathome|URL: http://lhcathome.cern.ch/lhcathome/; Computer ID: 7790039; location: ; project prefs: default
16/10/2007 18:32:38||General prefs: using your defaults
16/10/2007 18:32:38|climateprediction.net|Task hadcm3iozn_cpdf_2000_80_95898652_0 is 133038.36 days overdue.
16/10/2007 18:32:38|climateprediction.net|You may not get credit for it. Consider aborting it.
16/10/2007 18:32:38|climateprediction.net|Deferring task hadsm3fub_e002_005906460_8
16/10/2007 18:32:38|lhcathome|Resuming task wme1cocts_me1cocts__11__64.28_59.31__10_12__5__10_1_sixvf_boinc325765_2 using sixtrack version 467
16/10/2007 18:32:38|rosetta@home|Started download of file 1ubi_.fasta
:
:

/Pete

---

The deadline changing to 1901 is done by BOINC and is a side-effect of a large change in the system clock time Pete. It can either be due to a faulty CMOS battery or a large jump in the PC clock. Did you change the clock forward or back by more than a couple of weeks when BOINC was running?

You can fix it by stopping BOINC and editing the file client_state.xml as described here (you\'ll need to search for the string hadcm3iozn_cpdf_2000_80_95898652_0 and change the deadline value to 1342515406 to reset to the July 2012 deadline shown on the result\'s page.

As far as the hadsm3 model goes there\'s no need to worry about the extended time period. The model actually runs as 3 separate phases with discontinuous dates. The original hadsm3 models were indeed superceded, but the new ones are part of a new experiment that\'s attempting to test the predictability of what\'s going to happen to the climate based on the parameters.

---

"The ultimate test of a moral society is the kind of world that it leaves to its children." - Dietrich Bonhoeffer

Thyme, does one really need to change a deadline that\'s set itself to 1901? This happened to one of my models; I just ignored the crazy deadline and the model ran happily to the end.

In any case, CPDN ignores the deadline so results will be gratefully received by the server even if you\'ve gone past it. And past the deadline you still get your CPDN credits.

When I upgraded boinc from the old BBC CCE version I also wondered whether I would have to move the entire folder to a different place, but I found that this wasn\'t necessary.

You\'ll need to discover where the BBC CCE folder is. Open up My Computer from the desktop, then double-click on the C drive, then on Program Files. I expect you\'ll find BBC CCE in the list of Program files. If this is the case, you have no problem because Program files is where boinc prefers to be. (If you have Vista please tell us because I think that in this case, boinc may prefer to be somewhere else.)

Before upgrading, the best thing is to rename BBC CCE and start calling it Boinc or BOINC. Right-click on the BBC CCE folder name and select Rename. Change the name.

The BBC people didn\'t want their members to see the word boinc anywhere; they must have thought this word would give members of the public a terrible fright. That\'s why CCE members didn\'t receive the boinc download under its own name.

Boinc 5.10.20 works very well for me. Before you upgrade boinc it\'s always a good idea to back up the entire contents of the boinc folder, just in case something goes wrong during the upgrade. I use Les\'s easy manual backup instructions (get to them through my sig). File - Exit from boinc before upgrading and make sure the boinc icon has disappeared from the system tray bottom right of screen.

When the boinc installation wizard asks you where to put boinc, say C - Program files - Boinc ie onto your renamed CCE folder.

No need to uninstall your current version of boinc before upgrading; the old and new bits of boinc know how to sort themselves out.

Anyone who still has version 4 of boinc WILL need to uninstall it before upgrading. This of course doesn\'t include you, Pete.

The current slab models are also being used for research at the Freie Universität in Berlin by Falk Niehörster and his team. He was in Oxford in May, so it\'s a collaborative effort.

---

Cpdn news

thanks friends for the various advice. I hadn\'t reset the pc clock though I have clicked on the status bar icon to check a couple of calendar dates in December without OK-ing any changes - afaik.

I let the Rosetta jobs run down and waited till this afternoon when the slab model finished phase 1 and report back; I tried poking the client_state file as instructed but, although I can get the date to move to 1926, 1930 or 1931, it won\'t shift any later following any of the suggestions.

I\'m now minded to abort it; yes, mo.v, it will carry on processing but it messes things up with earliest-deadline-first scheduling and getting red messages threatening no credits for the task will get seriously on my nerves in 6 months time while it\'s still crunching! I reckon something fishy is going on.

I\'ll come back and upgrade the boinc manager when other things have settled down, probably when the slab model finishes next month.

/pg

The red messages are apparently a mistake at the boinc end - the red should have been withdrawn, but this hasn\'t happened. They will be changing this.

---

Cpdn news

thanks again - I meant to add that I can see there are few problems that haven\'t been encountered before, although finding previous discussion is rather needle in a haystack if you\'re not guessing the right search words. (having dual forums is a bit confusing)

Thyme, there\'s a beer waiting on the bar for you next time I\'m down your way - which is regularly...
and Mo, it\'s probably a bit off topic to point to my \'06 pix of the Spinnaker Tower except I just discovered Yahoo have killed off their photo album system and there is no direct access to them; I need to go and rescue them before the plug is finally pulled on the server!

If you do get your photos back, maybe you could post a few in the Cafe?

---

Cpdn news

Thyme, does one really need to change a deadline that\'s set itself to 1901? This happened to one of my models; I just ignored the crazy deadline and the model ran happily to the end.

It depends on whether you\'re happy to have BOINC running CPDN all the time or not.

When the deadline has been wound back to 1901 it forces the BOINC scheduler to run the CPDN task exclusively on one CPU, preventing work download for other projects until the CPDN task finishes unless you have a multiple CPU system and BOINC is configured to run on more than one CPU.

Regardless of how your resource sharing is set up BOINC will eventually even out the CPU time allocated to all the projects you run, but it could be months before your system is back to switching between your projects at the required interval.

---

"The ultimate test of a moral society is the kind of world that it leaves to its children." - Dietrich Bonhoeffer

Thanks for that. At the time the model that changed to the 1901 deadline wasn\'t competing for CPU time with any other workunits, which explains why the 1901 didn\'t cause a problem.

---

Cpdn news

\"Thanks for that. At the time the model that changed to the 1901 deadline wasn\'t competing for CPU time with any other workunits, which explains why the 1901 didn\'t cause a problem.\"

that was exactly the problem I found, as I first mentioned.
I did finally hit the abort button. As the slab model is still under half done, I haven\'t let the server send down another model to replace the aborted coupled one; let\'s hope when I do the deadline doesn\'t get scrambled second time around.

and, yes, I did manage to rescue the Spinnaker Tower photos using the automated transfer system that Yahoo has put in place for an unspecified time to run. see this thread in Cafe CPDN

sigh... ...back to the original question!

my slab model will complete within the hour (Wey hey!) so I let the manager allow new tasks and it has given me yet another CM model with a 1901 deadline. actually it tried to give me two but I aborted the download on the second before it could complete.

I thought this would also be a good time to upgrade my (5.4.11) BOINC version as well when there was nothing of accumulated crunched value to lose. I\'ve cleared out any remaining Rosetta tasks and done a backup both today and yesterday as I\'d heard of model crashes on 99% just prior to final upload. I have install files for 5.8.16 and 5.10.20 plus the latest 5.10.28 on my hd in case of strong opinions on the version number.

I\'d quite like to get everything into the default /boinc/ folder rather than the /BBC_CCE/ one - I think creating a fresh folder and copying all the contents across may be a better way than just renaming the old folder - a belt & braces back-up.

Perhaps the old version of BOINC is part of my completion date problem...
either way, any more thoughts on fixing the date question?

Do I kill off this further 13dec1901 CM 80yr model before doing the upgrade and hope for the best I get a normal one afterwards? It\'s yet to crunch for even an hour.

thanks again /pg

sigh... ...back to the original question!

my slab model will complete within the hour (Wey hey!) so I let the manager allow new tasks and it has given me yet another CM model with a 1901 deadline. actually it tried to give me two but I aborted the download on the second before it could complete.

I thought this would also be a good time to upgrade my (5.4.11) BOINC version as well when there was nothing of accumulated crunched value to lose. I\'ve cleared out any remaining Rosetta tasks and done a backup both today and yesterday as I\'d heard of model crashes on 99% just prior to final upload. I have install files for 5.8.16 and 5.10.20 plus the latest 5.10.28 on my hd in case of strong opinions on the version number.

I\'d quite like to get everything into the default /boinc/ folder rather than the /BBC_CCE/ one - I think creating a fresh folder and copying all the contents across may be a better way than just renaming the old folder - a belt & braces back-up.

Perhaps the old version of BOINC is part of my completion date problem...
either way, any more thoughts on fixing the date question?

Do I kill off this further 13dec1901 CM 80yr model before doing the upgrade and hope for the best I get a normal one afterwards? It\'s yet to crunch for even an hour.

thanks again /pg

I\'m running the same setup as you: ClimatePrediction, Rosetta, and SETI. I set resource shares at 200, 100, and 100, respectively. I have a dual Opteron system with BOINC 5.8.16. I set no-new-work on ClimatePrediction once I have one model. BOINC behaves properly crunches Climate on 1 CPU, balancing Rosetta & SETI on the other CPU.

I personally like 5.8.16 better than the 5.10.21 because the 5.10.x code was built with GTK1. GTK2 looks better in Fedora linux than GTK1. Also, 5.10.x has a lot more \"new\" features, meaning more things to break or get confused by setting. (I gave serious thought to compiling my own GTK2 version of BOINC 5.10.21, but that will have to wait until school is done.)

Hi Pete

You got 2 climate models because you have your prefs setting for number of processors set to 2. And you probably didn\'t have any other work units on hand.

1901 deadlines are most likely due to a faulty cmos backup battery.
To check:
Shut down BOINC.
Shut down the computer.
Disconnect the net cable.
Turn on the computer.

The computer will not be able to resync the internal clock with an internet timeclock, so it will say whatever the default time is, if the battery is flat and the computer has forgotten the current time. Most likely around the early 1980s, when the first \"PCs\" were built.
The 1901 part is a BOINC bug, fixed in the latest versions.

There\'s no need to bother with the old BBC folders. They can just be left there for future reference. (Perhaps Uninstall BOINC first.)

Because of more severe restrictions in Vista about where programs can be installed, it\'s recommended to NOT put BOINC in the program files folder, but in C:\\BOINC.
You could also start doing this with 5.8.* / 5.10.* versions on XP if you like, and \'get in early\'.

---

Backups: Here

thanks to all above: so, we\'re now running 5.10.28 installed in /program files/BOINC/ and I did Les\'s clock test disconnecting from the net. things are back crunching with CPDN status now saying \"running, high priority\", but the deadline remained 1901, probably not surprising as the client state file already had the faulty date code in it.
at least the manager\'s log doesn\'t shout back in red text which I guess is a small step forward. :-)

so I returned to Thyme Lawn\'s instructions above:

You can fix it by stopping BOINC and editing the file client_state.xml as described here - you\'ll need to search for the string hadcm3iozn_cpdf_2000_80_95898652_0 and change the deadline value to 1342515406 to reset to the July 2012 deadline shown on the result\'s page.
(ed. actually searching on the word \"deadline\" is easier. /pg)

but this only shifted the date to 1927. even using the advice in Dagorath\'s help page on the 1901 issue it only shifted to 1930. I found reducing rather than increasing the number in fact helped and it\'s currently on 18/12/1936 with date code \"1042515406.000000\". I wondered if there might have been a typo error in Thyme\'s post - is the formula behind the number in the public domain? The model itself is of course now a different one with a true deadline on the results page of 8 Aug 2012 3:30:15 UTC.

/pg

is the formula behind the number in the public domain?

Yup.

http://krijnen.com/time.php

That page should do it for you.

If it\'s 3:30 AM (I\'m assuming it is) then the Unix time stamp works out to be 1344411015.

---

Kathryn :o)
The BOINC FAQ Service
The Unofficial BOINC Wiki
The Trac System
More BOINC information than you can shake a stick of RAM at.

is the formula behind the number in the public domain?

Yup.
http://krijnen.com/time.php

If it\'s 3:30 AM (I\'m assuming it is) then the Unix time stamp works out to be 1344411015.

you\'re all going to have laugh at this:

I checked your conversion page - \'human to unix time\' and back - what a nice expression!
but got that 1927 date yet again in my BOINC manager, aaargh...
poked around a bit, putting one of my Rosetta end dates in to convert in the opposite direction which looked ok apart from an exact 5hour offset.
final inspiration was to put the weird 26-05-1927 date into the unix date converter and out popped \"-1344393015\" it had gone negative!!
I\'d read the dash as a hyphen not a minus sign! I\'ve no idea whether I inserted the dash myself or whether this was the effect of the bug, either way the problem is fixed. There is that 5hr offset again something unlikely to be of consequence. (This also explains why reducing the number, in fact making less negative i.e. increasing it, made a small improvement when I was experimenting.)

If one halves the 80yr difference between 2007 and 1927, you get 1967 although the zero point for the Unix timestamp seems to be a five hours before the turn of 1970. I suspect this recurrent 5yr offset is something to do with the difference between GMT and EST.

matter closed, the new model is now past its first 1% \'milepebble\', thanks all.
hope the narrative helps any others. /Pete