There should be a CPDN client for glibc2.2 or the option to compile the client for different paltforms, as for seti_boinc.

I have several maschines idle for long times, but it\'s impossible to upgrade to glibc2.3. Because some software, we are using, depend\'s on the glibc2.2.

Rainer

As a parallel question: Are there any plans on publishing the source code for the application so that users can compile for their own weird systems (Playstation 2, my DVD player etc...) and with their own crazy CPU specific optimizations...or?

There are a couple of caveats to be made. One is that it is quite a large program (around a million lines of code) so it is a lot more daunting a task than S@H, for example.

The other is the sensitive subject of validation. Remember that this is publicly funded scientific research. Whilst someone may have perfect confidence that their compilation for, say, XBox is just wonderful, it may be difficult to convince others that the results can be trusted without independent corroboration. SETI gets around this by sending the same WU to at least three different machines, and rejects any results that are out of line. CPDN cannot afford to do this, and so has to rely on the integrity of the software, though there are of course ways of trapping anomalous results.

also, other than the complexity/size of the climate model is the issue that CPDN has an arrangement to use this (at no charge) from the UK Met Office -- it is proprietary code and not freely available; although the results will be (when we get the grid stuff working for scientists to use!)

I will look into the hadsm3 compilation, as I had thought everything was statically linked as they are in the model (hadsm3um) and small executables (hadsm3se) and maybe the viz (which is not "mandatory" but nice to see your "world" running!)

Howdy!

I've just ran into the same brick as Rainer did.

I checked all 3 binaries that seem to really matter (hadsm3, hadsm3se and hadsm3um; does hadsm3viz really matter?) and I found out that two of them are already statically linked. Why not statically link also the first one (hadsm3)?

It further seems to me, that the hadsm3 binary is only some kind of wrapper binary which takes care of running the actual scientific model. Or am I wrong?

For sure this will enlarge the download file set, but as these seem to get downloaded only once, I don't think people will complain a lot.

A side note: while trying to get things working, I detached and attached to the project a couple of times. Every time I attached to the project a 'result' got assigned and had been discarded by client when I detached from the project. How an be such results returned to the pool of work available to other participants?

Howdy!

I'm glad to see that the version 4.04 now runs on my ancient GLIBC 2.2 linux. Thanks a lot!

The question about returning the 'ghost' model runs still remains: how to delete the model runs allocated to a client but the client never managed to run because of old GLIBC?

> Howdy!
>
> I'm glad to see that the version 4.04 now runs on my ancient GLIBC 2.2 linux.
> Thanks a lot!
>
> The question about returning the 'ghost' model runs still remains: how to
> delete the model runs allocated to a client but the client never managed to
> run because of old GLIBC?
>
>
cool, you're the first I've heard from "ancient" boxes -- I discovered from another user around here that I wasn't statically compiling everything, so now I am so there are no dependencies (except on vis, but I distribute a few libGL's that should help).

I wouldn't worry about the old/crashed model runs, BOINC detects the crash and reallocates new results for that workunit.

Back to my problem ... this time for sulphur ...

Here\'s output from ldd:

ldd sulphur_4.21_i686-pc-linux-gnu
./sulphur_4.21_i686-pc-linux-gnu: /lib/i686/libc.so.6: version `GLIBC_2.3\' not found (required by ./sulphur_4.21_i686-pc-linux-gnu)
libm.so.6 => /lib/i686/libm.so.6 (0xb7fb5000)
libdl.so.2 => /lib/libdl.so.2 (0xb7fb1000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0xb7f9d000)
libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fed000)

Any hope for statical build?

OTOH: is it possible to define a box not to fetch sulphur experiment? The problematic one is a 2-way P3@1GHz which will take forever to complete sulphur experiment...

---

Metod ...

I get the same on my linux cluster:

[climateprediction.net]# ldd sulphur_4.21_i686-pc-linux-gnu
./sulphur_4.21_i686-pc-linux-gnu: /lib/i686/libc.so.6: version `GLIBC_2.3\' not found (required by ./sulphur_4.21_i686-pc-linux-gnu)
libm.so.6 => /lib/i686/libm.so.6 (0x40018000)
libdl.so.2 => /lib/libdl.so.2 (0x4003b000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4003e000)
libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

these are RH7.3 ish boxes...

Any way to disable the sulphur models?
Seb

---

Slab has been shut down, at least for the moment, and a large number of sulphur data sets generated, because the researchers want more sulphur.

(Carl\'s post <a href=\"http://www.climateprediction.net/board/viewtopic.php?t=3352\"> here.</a>)

You\'ll just have to shoot those computers. :(

Well, the only problem I have is that with the longer run times of Sulfur models and shorter deadlines, there is a tension here. The run times I see are 4 to 5 times slab, yet the deadline is 50% ...

I still don\'t see the point of increasing the work by a factor of 4 but decreasing the deadline by factor of 2 ... especially when we should now have SOME \"slack\" with some models created. One of my fears would be an entry into EDF on too many of my computers.

So, just my 2 cents, but, I see this is a little unrealistic ...

---

My sulphur was started on 10-10-2005, and the deadline says 22-9-2006, so I think the deadlines have been relaxed.

Hmm,

Looking at mine, I have 2 with 6 month deadlines and 2 with what looks like a year. So, you may be correct.

---

You\'ll just have to shoot those computers. :(

ack! looks like new OS in the new year - hmm Debian?

Seb

---

You\'ll just have to shoot those computers. :(

ack! looks like new OS in the new year - hmm Debian?

I\'m heading for the ultimate solution - replace those old ones (which are too slow to finnish sulphur runs in decent time anyway) with new ones - installing Debian.

I\'ll replace one this month, but I don\'t know about the other one. I can\'t afford down time to re-install it from scratch. I might be forced to detach it from CPDN :(

---

Metod ...

New version of sulpher client works now though on the glib2.2 machines - at least some work will get done over Christmas :)

---

New version of sulpher client works now though on the glib2.2 machines - at least some work will get done over Christmas :)

Glad to hear that Seb. You might have lost your #1 spot otherwise :)

---

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