More HADCM3s tasks in testing. Now October is here, I am checking daily for when the OpenIFS start testing but suspect it won't be before mid month.

I don't think these are coming to the main site. The scientist running these experiments appears to be using the "testers" (mainly me) to run his experiment/experiments.

More HADCM3s tasks in testing. Now October is here, I am checking daily for when the OpenIFS start testing but suspect it won't be before mid month.

I don't think these are coming to the main site. The scientist running these experiments appears to be using the "testers" (mainly me) to run his experiment/experiments.

If they don't need the large numbers I guess it makes sense to not have tasks wasted on machines that can't run them due to too new a version of MacOS etc and stick to machines that are known to be reliable.

More HADCM3s tasks in testing. Now October is here, I am checking daily for when the OpenIFS start testing but suspect it won't be before mid month.

Dave, unfortunately Andy & I have both had to deal with covid, plus teaching requirements for Oxford so testings are delayed. Andy has just now deployed the updated multi-threaded OpenIFS app and as soon as I'm back on my feet I can progress the testing.

More HADCM3s tasks in testing. Now October is here, I am checking daily for when the OpenIFS start testing but suspect it won't be before mid month.

Dave, unfortunately Andy & I have both had to deal with covid, plus teaching requirements for Oxford so testings are delayed. Andy has just now deployed the updated multi-threaded OpenIFS app and as soon as I'm back on my feet I can progress the testing.

Thanks for the update, Hope you are both back to full strength soon.

Looks like a batch of HADSM4'S are being prepared.

Looks like a batch of HADSM4'S are being prepared.

That's very good news!!

Any news on how Glenn and Andy are going with the OpenIFS application?

(Hoping they are both clear of Covid now of course.)

I would like to give it a go.

Thanks
Conan

---

Nothing since Glen's post. The multicore tasks haven't made it to the testing site yet. I will unless away from my computer post when they reach that stage.

Nothing since Glen's post. The multicore tasks haven't made it to the testing site yet. I will unless away from my computer post when they reach that stage.

As soon as I can talk though a video call with Andy without coughing, we'll go over the last remaining server side issues (2 weeks and still testing positive!).

People might have noticed a new OpenIFS application has appeared on the CPDN list of applications. This is OpenIFS 'baroclinic lifecycle' which comes from a collaboration with researchers at the university of Helsinki.

It's a special configuration of OpenIFS where all the land is removed from the planet, to make it an 'aqua-planet'. It's used to create simple starting conditions and generate idealised storms that can be modelled to see how they behave when forced in different ways. So for example, if we double the carbon dioxide in the model, does it make these storms more intense, last longer etc? I hope the scientist involved will write something on the forums or website about the project, if not I'll ask.

The plan I believe is to run these experiments end Oct/start Nov. Which is when I hope I'll have some tests for the multi-core, high-resolution models ready to go too.

Thanks Glenn for the update.
Hope you get well soon, plenty of fluids and rest.

Conan

---

Looks like a batch of HADSM4'S are being prepared.

I just picked up a couple, and they are _0.

I got a couple too, but the first has just crashed after six minutes with negative theta.

Edit - and the second, same error.

I got a couple too, but the first has just crashed after six minutes with negative theta.

Edit - and the second, same error.

Fortunately, that is not a crash that needs fixing. Just "unfortunate" choice initial conditions.

---

How big was that Batch 937 release? I didn't get any tasks and wasn't even sure that there was a release until seeing it on the homepage scroll.

There was 150 tasks.

There was 150 tasks.

My Boinc-client is discouraged. I enabled new ClimatePrediction tasks a week or so ago and have received no work units. My client only tries about once every 24 hours or so to get ClimatePrediction work units. Since my machine is Linux, and I do not even know if those work units are for Linux, I am not likely to get any of 150 work units. Sigh.

---

There was 150 tasks.

My Boinc-client is discouraged. I enabled new ClimatePrediction tasks a week or so ago and have received no work units. My client only tries about once every 24 hours or so to get ClimatePrediction work units. Since my machine is Linux, and I do not even know if those work units are for Linux, I am not likely to get any of 150 work units. Sigh.

I would love to see the CPDN server logs. There were 25 linux tasks in the 'dev' queue yesterday, but despite suspending all my projects/tasks except cpdn on my linux box and pinging the server every minute, it refused to give me any. User geophi seemed the only one getting them. Then I booted up my WSL boinc instance which only has cpdn & cpdn-dev as projects and it sent me one. So I can't help but wonder if the server gets jealous of other projects :) Maybe someone who understands the server scheduling algorithm might know what's going on.

Anyway, there are 3 separate OpenIFS (linux) projects in development & testing. I will be sending out multiple batches of ~200-300 each for my project once the tests are done.

MY Linux machine has
WCG at 61.5% Resource share.
ClimatePrediction at 33% Resource share.
Rosetta at 4.75% Resource share.
MilkyWay at 0.5% Resource share, and
Universe at 0.25% Resource share.

These shares used to get about 1/2 my Boinc work devoted to ClimatePrediction,
1/4 my work to WCG, and 1/8 to Rosetta. I did not run the other two in those days. I did run Seti@home and some other things, but they are gone now.

I poked my Boinc client just now and got this:

Fri 21 Oct 2022 07:33:48 AM EDT | climateprediction.net | update requested by user
Fri 21 Oct 2022 07:33:51 AM EDT | climateprediction.net | Sending scheduler request: Requested by user.
Fri 21 Oct 2022 07:33:51 AM EDT | climateprediction.net | Requesting new tasks for CPU
Fri 21 Oct 2022 07:33:52 AM EDT | climateprediction.net | Scheduler request completed: got 0 new tasks
Fri 21 Oct 2022 07:33:52 AM EDT | climateprediction.net | Project has no tasks available
Fri 21 Oct 2022 07:33:52 AM EDT | climateprediction.net | Project requested delay of 3636 seconds

Note that it did not complain that it did not need work as it does if my local queue of work to be done is too full.
Furthermore, it will not try again in 3636 seconds or anywhere near that.

---

... pinging the server every minute,

That's your problem. If it was the main CPDN project (not the dev site), the server asks you to wait for 1 hour plus 1% - 3636 seconds - between updates.

Most client-server updates can be done at any time, despite the request to back off for a period of time. You can report completed work, load any preference changes made on the server, see your updated statistics - all those are fine.

But the exception is requesting new work. That one (only) is enforced by the server as well:

21/10/2022 12:58:42 | Einstein@Home | Sending scheduler request: Requested by user.
21/10/2022 12:58:42 | Einstein@Home | Reporting 2 completed tasks
21/10/2022 12:58:42 | Einstein@Home | Not requesting tasks: don't need (CPU: ; NVIDIA GPU: not highest priority project)
21/10/2022 12:58:43 | Einstein@Home | Project requested delay of 60 seconds
21/10/2022 12:59:10 | Einstein@Home | Sending scheduler request: Requested by user.
21/10/2022 12:59:10 | Einstein@Home | [sched_op] NVIDIA GPU work request: 4313.88 seconds; 0.00 devices
21/10/2022 12:59:11 | Einstein@Home | Scheduler request completed: got 0 new tasks
21/10/2022 12:59:11 | Einstein@Home | Not sending work - last request too recent: 28 sec

I didn't get that last line ('last request too recent') in a request to CPDN: I suspect possibly "project has no work available" is processed first, and it doesn't even look at the datestamp for "last request" unless there's work available to consider for sending.

Note the semantics: "last request" is any request for an update - it's not limited to updates that include a request for work. As the first request above shows.

... pinging the server every minute,

That's your problem. If it was the main CPDN project (not the dev site), the server asks you to wait for 1 hour plus 1% - 3636 seconds - between updates.

Yes, sorry I was talking about the dev site for which the client sends a request every 7 secs. I'd manually update every so often as well. Despite suspending all projects & tasks for 30mins it never sent any tasks even though I could see some were available. I suspect there is some kind of 'decay' logic which causes the server to wait for a while until it's sure a machine really is free.