Looking forward to it. Which app would that be?

Weather at Home Windows tasks.

About how much RAM per task will be required?

I can't remember exactly how much they use but 2GB/core is plenty.

Weather at Home Windows tasks.

Other people's mileage may vary but I found previously that WaH tasks didn't like being cold restarted (machine on/off) on my Win11 box. They would often abort on restart for reasons I couldn't see in the logs.

Weather at Home Windows tasks.

Other people's mileage may vary but I found previously that WaH tasks didn't like being cold restarted (machine on/off) on my Win11 box. They would often abort on restart for reasons I couldn't see in the logs.

I would second that, though my impression is they fall over on restart slightly less often than the linux Hadley model tasks. Worst were the hadcm3 tasks when these were still available for Linux.

I remember that, many years ago, the hadcm3 tasks were supplied with a BOINC graphics app (certainly for Windows, I wasn't running Linux then). The graphics app gave a detailed live display of the precise computational stage reached - and users were advised to avoid stopping or in any way interrupting a task during a checkpoint, or even close to it.

CPDN checkpoint files are large, and on the hardware of the day (mechanical disks) took a significant time to write to disk. Some at least of the failures were put down to incomplete checkpoint files.

I remember the graphics too. You could choose whether they were showing precipitation, temperature, air pressure or precipitation on the globe and you could see if your model went off track and had produced an ice world.

Edit: At least one of the 32bit libraries was needed in order to display the graphics.

I remember that, many years ago, the hadcm3 tasks were supplied with a BOINC graphics app (certainly for Windows, I wasn't running Linux then). The graphics app gave a detailed live display of the precise computational stage reached - and users were advised to avoid stopping or in any way interrupting a task during a checkpoint, or even close to it.

Yes, the graphics code is one of the reasons why the change to 64bit is an issue, because it's done via shared memory (and not via files).

If I remember right, it was created with the help of the MetO using an application called pv-wave (I could be wrong, was along time ago). I've been toying with the idea of using a python executable to do a graphics tool for the OpenIFS app but using files rather than via shared memory. It would mean more I/O on the disk though as the output would have to be rearranged to get a nice time display.

I've been toying with the idea of using a python executable to do a graphics tool for the OpenIFS app but using files rather than via shared memory. It would mean more I/O on the disk though as the output would have to be rearranged to get a nice time display.

I am not interested in graphics displays. Some projects offer them, and some do not. IIRC,. I can specify the number of images per second or some such. But after looking at a few, I do not really care to run them. I prefer to use all my spare processor cycles on working on the projects, not projecting movies. If I want to run a movie, I can get them from a local DVD or YouTube or some such.

So, IMAO, go ahead and develop these if you must, but I sure will not be running them.

---

I remember that, many years ago, the hadcm3 tasks were supplied with a BOINC graphics app (certainly for Windows, I wasn't running Linux then). The graphics app gave a detailed live display of the precise computational stage reached - and users were advised to avoid stopping or in any way interrupting a task during a checkpoint, or even close to it.

CPDN checkpoint files are large, and on the hardware of the day (mechanical disks) took a significant time to write to disk. Some at least of the failures were put down to incomplete checkpoint files.

Shouldn't Boinc allow full writing of checkpoints before closing? Just like a video editor doesn't give up saving a massive video file just because I'm shutting the machine down. So many schoolboy errors!

I remember the graphics too. You could choose whether they were showing precipitation, temperature, air pressure or precipitation on the globe and you could see if your model went off track and had produced an ice world.

But ice ages do exist.

I am not interested in graphics displays. Some projects offer them, and some do not. IIRC,. I can specify the number of images per second or some such. But after looking at a few, I do not really care to run them. I prefer to use all my spare processor cycles on working on the projects, not projecting movies. If I want to run a movie, I can get them from a local DVD or YouTube or some such.

So, IMAO, go ahead and develop these if you must, but I sure will not be running them.

I'm the same, I may look now and again out of interest then get bored and leave it to it. But if it attracts people to run them, it's a good idea. Having said that we're not short of users here, we're short of work!

But ice ages do exist.

In this context, an Ice world refers to a simulation where the whole earth is approaching or has reached 0 degrees K indicating that the model has gone rogue.

But ice ages do exist.

In this context, an Ice world refers to a simulation where the whole earth is approaching or has reached 0 degrees K indicating that the model has gone rogue.

Or the sun went wrong. Crops would be difficult to grow, but we'd manage ;-)

CPDN checkpoint files are large, and on the hardware of the day (mechanical disks) took a significant time to write to disk. Some at least of the failures were put down to incomplete checkpoint files.

Shouldn't Boinc allow full writing of checkpoints before closing? Just like a video editor doesn't give up saving a massive video file just because I'm shutting the machine down. So many schoolboy errors!

Boinc doesn't know about checkpointing for cpdn's models. The models do it themselves and ignore whatever the client tells them because there is a risk someone may set the checkpoint frequency too high and cause excessive I/O.

The checkpoint files (or any output file really) can be interrupted by boinc killing the process. For example, opening a file and writing to it are separate steps in the code. We might write temperature, then pressure, then close the file. Each is a separate line of code. If the model process is killed between the open/close then the checkpoint file will be incomplete. There's also buffering to consider before the file is written to a hard device.

I've been toying with the idea of using a python executable to do a graphics tool for the OpenIFS app but using files rather than via shared memory.

I am not interested in graphics displays. Some projects offer them, and some do not. ... I prefer to use all my spare processor cycles on working on the projects, not projecting movies.

So, IMAO, go ahead and develop these if you must, but I sure will not be running them.

Obviously I'm not interested in developing any code for people not planning on using it, but I am for those that are - I'm not sure why it was necessary to tell me you won't be. There are meteorologists like myself, climate scientists, etc though who may well be interested.

I will do the graphics slightly differently. Rather than 1 display for 1 task, it would be 1 display for all tasks. As most people probably know, modern forecasts are all run as forecast ensembles, each starting from a slightly different initial state. We could have a graphics window displaying the same field but from each of the, say, OpenIFS tasks running on the client. Personally I'd find it interesting to see how the forecasts are different and watch those differences develop.

---

---
CPDN Visiting Scientist

The checkpoint files (or any output file really) can be interrupted by boinc killing the process. For example, opening a file and writing to it are separate steps in the code. We might write temperature, then pressure, then close the file. Each is a separate line of code. If the model process is killed between the open/close then the checkpoint file will be incomplete. There's also buffering to consider before the file is written to a hard device.

What should happen is:
1) User gives command to shut down computer.
2) Boinc commands all running tasks to come to a halt.
3) Boinc waits for all tasks to report they have finished noting things down.
4) Boinc closes.
5) The OS closes.
If 3) isn't happening, somebody made a very stupid decision when coding Boinc. It would be like a foreman not giving a workman 2 minutes to put his tools away.

Obviously I'm not interested in developing any code for people not planning on using it, but I am for those that are - I'm not sure why it was necessary to tell me you won't be. There are meteorologists like myself, climate scientists, etc though who may well be interested.

I will do the graphics slightly differently. Rather than 1 display for 1 task, it would be 1 display for all tasks. As most people probably know, modern forecasts are all run as forecast ensembles, each starting from a slightly different initial state. We could have a graphics window displaying the same field but from each of the, say, OpenIFS tasks running on the client. Personally I'd find it interesting to see how the forecasts are different and watch those differences develop.

Sounds like you're going to make something useful in the graphics. Perhaps Jean-David was referring to some projects that just make a pretty picture with no useful information.

Perhaps Jean-David was referring to some projects that just make a pretty picture with no useful information.

Exactly.

---

2) Boinc commands all running tasks to come to a halt.

BOINC doesn't 'command', BOINC 'requests'.

There are two cases to consider:

a) A planned shutdown under user control, such as for maintenance or upgrading.
b) A forced shutdown by the operating system, such as Windows 11's unfortunate habit of installing updates 'outside working hours'.

For me, a computer outside it's working hours is switched off. A computer running BOINC has working hours of 24/7. So, no automatic updates for me.

The difference between the two cases is that, if the user has initiated the shutdown, it is assumed they are still watching the screen - so dialogs can be displayed, and questions asked and answered. That delays the shutdown for ever if the user has wandered off.

An operating system shutdown is silent - no messages are shown, no operator input is allowed. BOINC still 'requests' science applications to close in an orderly fashion, but if the request is ignored (possibly a programming error by the project), BOINC does indeed 'command' the closedown after a delay - or "terminate with extreme prejudice", in the words of one senior project administrator/programmer.

Totally agree no point in graphics that are not useful or informative in some way. Of course when the original graphics program was written I don't think any crunchers had multi-core machines so there would have been no point in doing it the way you are Glen!

2) Boinc commands all running tasks to come to a halt.

BOINC doesn't 'command', BOINC 'requests'.

There are two cases to consider:

a) A planned shutdown under user control, such as for maintenance or upgrading.
b) A forced shutdown by the operating system, such as Windows 11's unfortunate habit of installing updates 'outside working hours'.

For me, a computer outside it's working hours is switched off. A computer running BOINC has working hours of 24/7. So, no automatic updates for me.

The difference between the two cases is that, if the user has initiated the shutdown, it is assumed they are still watching the screen - so dialogs can be displayed, and questions asked and answered. That delays the shutdown for ever if the user has wandered off.

An operating system shutdown is silent - no messages are shown, no operator input is allowed. BOINC still 'requests' science applications to close in an orderly fashion, but if the request is ignored (possibly a programming error by the project), BOINC does indeed 'command' the closedown after a delay - or "terminate with extreme prejudice", in the words of one senior project administrator/programmer.

If you're right then the fault is with Windows. But I believe people have had problems with CPDN tasks with manual shutdowns.

If it's Windows doing it, Windows should allow all programs including Boinc a decent amount of time to close down. There's no hurry to install an update, it could wait 10 minutes! And it should be able to see things are happening, like disk activity. In fact it does know when things are busy, when I shutdown I get things like "Gridcoin has not safely closed yet". I can then wait and not press "shutdown anyway".

If the problem is with manual shutdowns, why on earth is Boinc allowing the shutdown? I tell the computer to shut down. Boinc tells the projects to shut down. Messages must come back from the projects to Boinc, then Boinc to Windows to say shutting down is completed. Try this: run some VB tasks in Boinc. Now shutdown windows. You'll get the infamous VB message about VB still has open connections. Ignore it, press nothing, eventually you will go back to the desktop and the shutdown will be aborted. So we can see it's possible for programs to prevent the shutdown unless the user overrides it.

The current situation is like me getting a lift in your car, telling you to stop, then immediately getting out of the car before you've told me the car has stopped.

Have you never seen the Windows message "waiting for background programs to close" during a shutdown?