I think it\'s the newest; 5.2.7

Oh and one last thing, I really did think that your asinine behaviour toward the person originally posting this query was right out of line. Perhaps you can save your self righteous and caustic sarcasm for the real world where at least your targets will have the opportunity to smack your jaw lose for the tacit insult.

Something to ponder perhaps?

Are you stable in prime95 for at least 24hours?

How are your temperatures at load?

Some people have driver/anti-virus conflicts.

Remember CPDN is harder on hardware than most other applications.

Sulphur Cycle

The Sulphur Cycle experiment is one of the Climateprediction.net Models. It was launched on 26th August 2005.

This will model sulphur in several different compound forms including sulphates, sulphuric acid, DMS and others.

For more about the science invovled see Sulphur Cycle page.
[edit]
More about running the model

CPDN places heavy demands on personal computers. This was demonstrated in Classic CPDN and in HadSM3 on BOINC. Sulphur Cycle continues the demand and adds significant new considerations.
Sulphur Cycle Time Steps require around 70% more CPU time as compared with HadSM3 Time Steps.
Sulphur Cycle adds two Phases to the Run -- so, longer Time Steps and five Phases -- totals as much as 2.8 times longer than a HadSM3 Run on the same machine.
For CPDN-dedicated machines:
On an Athlon 64 3200+, in WinXP, running stand-alone, one Sulphur Cycle Model requires approximately 53 days (@24/7).
On an Athlon 64 3400+, in WinXP, running stand-alone, one Sulphur Cycle Model requires approximately 47 days (@24/7).
On an Athlon 64 3800+, in WinXP, running stand-alone, one Sulphur Cycle Model requires approximately 42 days (@24/7).
On a P4 3.0 in WinXP, running stand-alone, one Sulphur Cycle Model requires approximately 45 days (@24/7).
On a P4 3.0 in Linux, running stand-alone, one Sulphur Cycle Model requires approximately 39 days (@24/7).
On a P4 3.0 in Linux, running two Sulphur Cycle Models in parallel require approximately 65 days (@24/7).
On a P4 3.0 in Win2K, 1 Sulphur Cycle + 1 HADSM3, Sulphur Cycle requires approx 79 days (28 for HADSM3, which makes S-Cycle 2.8 times as long). [~25&65 days in Linux]
On a P4 3.4 in Linux, running stand-alone, one Sulphur Cycle Model requires approximately 34 days (@24/7).
Sulphur Cycle requires much more disk space than HadSM3 version. SC requires about than 2.7 Gigabytes of Hard Disk Storage (about 5.4 Gigabytes for two concurrent Runs) in Phase 5 prior to the end.
At the end of a successful Run, there are 2,327 zipped files consuming 1GB of Disk space. Unless off-loaded, this 1GB per finished Model is added to the Hard Disk requirement for the next Run; a failed Run could leave considerably more than 1GB.
Post-Phase processing is more extensive than in HadSM3 and the results upload at the end of each Phase, rather than all at Run\'s end.
Given the length of the WU, backups are more important in Sulphur Cycle than in HadSM3. The BOINC directory should be backed-up periodically, near the end of each Phase as a minimum.
Note: backups take longer because of increased Folder size.
The application files consume +/- 35MB of download bandwidth. Modem users be aware...
The deadline has been set to be rather short - 5 months. This is because getting some results is a requirement for the coupled model hindcast which is planned for February 2006.

This is likely to cause a lot of computers to show as overcommitted and start crunching only the sulphur cycle model until it is finished. Results returned after the deadline should not be rejected.

If you have one computer and a few projects you may want to consider whether you want to put this much resources into CPDN or not.

If you have several computers and a few projects you may want to consider putting the Sulphur Cycle on one (or a few) of the faster computers with little other work while setting other computers not to download CPDN work.

Many thanks to AstroWX for starting this information on the Beta site.

I would like to contribute to the model experiment, but I can\'t use a defective code.

It could be a number of things Yannis:

• you\'ve lost write access to the BOINC directory.
  
• there\'s a read-only client_state_next.xml file in your BOINC directory.
  
• you\'ve run out of disk space.
  

Thank you for your reply. I have discovered that I could not access the BOINC folder. After a quick reboot the project was up and running again with no glitch. Despite the unusual error message as described in my original posting, the computations were actually running ( I run the \"Show graphics\" option and it was registering timesteps every 2 seconds).

Thank you once again for your reply.

And we have a new version 5.2.7 available from the same download location

I gave it a whirl at home last night, and I\'m not impressed.

I use a modem for connectivity there and even with n/w access suspended, it continually tries to send trickles and can\'t resolve the cpdn hostname. Also with n/w access suspended, it was popping up a box asking if \"it\'s OK to connect\". The network options weren\'t being remembered. Regardless of what I set, it just went back to \"Automatically detect\". Then after I\'d connected and allowed network connectivity, the daemon (installed as a service) just died with no explanation in the middle of my uploads and left the manager connectionless.

I remember the days when n/w access disabled meant exactly that. It included trickles, master file fetches, scheduler requests and any other client/server communication, not just uploads and downloads. Disabled means DISABLED damnit! :(

Needless to say, I went back to 4.45 !

...

Did that behaviour start with 5.2.7 or any 5.2.x version?

2) Viz 3 for 5 phase sulphur was / is faulty, and a new version was supposed to be written.

Still can\'t get the advanced visulisation to work either.

I\'m wondering if the \'remove from memory\' causes temperary & intermediate results to be lost, so the next time it comes in to memory, it has to begin at the beginning of the last \'checkpoint\'.

Hi, I had accidentally turned off trickles as I was switching from the old (Python) trickle code to the new (C++) trickle code. Hopefully things are OK now, other than some duplicates (which won\'t affect overall credit but will bump up the RAC).