I remember that in the previous version of the model, there was a graph showing the progress up to the current point in the computation process. You could also view regional temperatures :):

http://climateapps2.oucs.ox.ac.uk/cpdnboinc/result.php?resultid=5110258

(This was my previous model, which gave a deterministic error very late because the output has diverged, and one way you could tell was by looking at the graph.)

However, with the latest version, it no longer shows :(

http://climateapps2.oucs.ox.ac.uk/cpdnboinc/result.php?resultid=6041361

I personally liked this feature. I wonder why it was removed... :(

Best wishes,
Stefan.

---

Rumour has it that it\'ll be worked on this coming week, I\'d guess that the reason the results page wasn\'t updated originally was that at the time of issuing the new version, Carl + Tolu were rushed off their feet ...

---

I'm a volunteer and my views are my own.
News and Announcements and FAQ

Wish granted.

Carl has fixed things.

Many thanks and congratulations to the entire CPDN technical team for managing to keep the project up and running even when the project is, as far as I\'ve heard, quite understaffed! Keep up the good work! ;)

Cheers,
Stefan.

Wish granted.

Carl has fixed things.

---

Another question to bug you guys (low priority of course, since I believe that there are users with more painful problems than this):

Strangely, on the graph of my data set, there is a missing time period: the years 1921-1931 (see below)

http://climateapps2.oucs.ox.ac.uk/cpdnboinc/result.php?resultid=6041361

I know the project periodically uploads data to the server (this happens once every 10 model years, apart from the data in the trickles). The files being uploaded are called (in my case) \"hadcm3ohc_1jzn_05620922_0_<xx>.zip\" where <xx>=1,2,...

Does this mean that somehow my file \"hadcm3ohc_1jzn_05620922_0_1.zip\" did not upload properly? (and that\'s why it doesn\'t show on the graph?).

As a side-note: apart from the periodic backup of the entire project directory, I also keep all these uploaded .zip files, so I have the missing file in case this was the problem and you guys would need it.

Cheers,
Stefan.

Wish granted.

Carl has fixed things.

---

Sometimes the graph server runs behind the trickle server, so you get temporary gaps.

---

I'm a volunteer and my views are my own.
News and Announcements and FAQ

I hope that when you say you\'re backing up \"the project directory\", that you mean BOINC and all folders/files under it.
Just backing up the c:\\program files\\boinc\\projects folder is useless.

In this new type of model, ALL trickles upload some actual data, which is where the graph data comes from. At least I think so, because you get graphs after the 1st trickle. But it does seem strange that you\'ve missed so much.

If you got the message Succeeded for the zip transfer, then the data should be at Oxford. But hang on to the zip just in case.

Hi Les,

I hope that when you say you\'re backing up \"the project directory\", that you mean BOINC and all folders/files under it.
Just backing up the c:\\program files\\boinc\\projects folder is useless.

Oh, of course, I mean the entire BOINC directory, not just the \'projects\' subdirectory (BOINC client state + CPDN state). Actually, I wrote a small java program that does this automatically and additionally, makes sure that I keep the last 3 most recent backups (it names them based on the timestamp of the backup). It has saved my models a few times from demise (once I ran out of disk space, etc.).

I was thinking to extend this program to do other things too:
* also make the backup of the uploaded .zip files automatic
* take care of the \"send trickle only if model is alive\" cycle (enable network access, send trickle, disable network access) - this could be accomplised by the boinccmd command
* take care of the \"restore from backup if model has died\" case (but this should only be done with care, maybe a limited number of failures and depending on the output error code, because the model might deterministically fail due to divergent temperatures for example, in which case you shouldn\'t keep restoring the backup)

The simple backup program I have now does not run all the time, only periodically (I use Scheduled tasks unded Windows, crontab under Linux), so it takes up no resources.

Maybe, if I have time in this winter vacation, it would be a nice idea to extend it and maybe share it with some users to see if it helps. I probably would need to rewrite it in C then, because not everybody has Java installed on their system.

In this new type of model, ALL trickles upload some actual data, which is where the graph data comes from. At least I think so, because you get graphs after the 1st trickle. But it does seem strange that you\'ve missed so much.

If you got the message Succeeded for the zip transfer, then the data should be at Oxford. But hang on to the zip just in case.

Yes, indeed, the upload has succeeded for sure (below is an excerpt from my stdoutdae.log):

2006-10-27 17:22:13 [climateprediction.net] Restarting task hadcm3ohc_1jzn_05620922_0 using hadcm3 version 515
2006-10-28 03:28:30 [---] Resuming network activity
2006-10-28 03:28:31 [climateprediction.net] Sending scheduler request to http://climateapps2.oucs.ox.ac.uk/cpdnboinc_cgi/cgi
2006-10-28 03:28:31 [climateprediction.net] Reason: To send trickle-up message
2006-10-28 03:28:31 [climateprediction.net] (not requesting new work or reporting completed tasks)
2006-10-28 03:28:31 [climateprediction.net] Started upload of file hadcm3ohc_1jzn_05620922_0_1.zip
2006-10-28 03:28:40 [climateprediction.net] Scheduler request succeeded
2006-10-28 03:31:12 [climateprediction.net] Finished upload of file hadcm3ohc_1jzn_05620922_0_1.zip
2006-10-28 03:31:12 [climateprediction.net] Throughput 34637 bytes/sec
2006-10-28 03:33:33 [---] Suspending network activity - user request

But if the server missed some trickles, I should have got a partial graph, not exactly the first 10 years missing... Hmmm, it seems kind of confusing, isn\'t it?

Warm regards,
Stefan.

---

I\'m missing the same years on the resurrected graphs so the problem is more generic, methinks.

---

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