 |
|
|
41)
Message boards :
Number crunching :
Batch List
(Message 63817)
Posted 8 Apr 2021 by  Iain Inglis
Post: [mikey wrote:] Can we get a note somewhere on the website that the tasks only run on this or that kind of OS or device please. I keep asking for tasks on my Windows10 pc's but keep getting the At the moment the most reliable method for my list is the applications page, as linked by Sergey Kovalchuk. The BOINC message board formatting changed a while ago to force line-wrapping, which makes the list look awful on small devices, but I'll add an operating system field at the end of each batch line which should be visible on a "proper computer". |
|
42)
Message boards :
Number crunching :
Batch List
(Message 63810)
Posted 7 Apr 2021 by Iain Inglis
Post: Batches 901-901 (current) Batch Date App. Region Res. Period Name (1st) Size 901 07-Apr-21 HADAM4 8.52 N216 5 month hadam4h_h000_200605_5_901_012075259 2100 Comment Batch 901: CDDHDD historical NH summer experiment: Cooling and heating degree days experiment for NH summer using OSTIA SST and Sea Ice. |
|
43)
Message boards :
Number crunching :
Little work, yet the most "important" thing in the world?
(Message 63761)
Posted 1 Apr 2021 by Iain Inglis
Post: The trajectory of increasing model complexity seems quite natural to me. There were global models and then regional ones; slab oceans and then stratified ones; low resolution and then higher resolution; and who knows what internal changes in the science and the parameters.Really? I just built a Ryzen 9 3900XT. I put 64GB into it and it will take 128GB. Boinc needs nothing like that. My point was intended to concern the failure of the speed of PCs to increase "as expected", though I concede that Moore's Law isn't really about speed. The number of processors has indeed increased and that means fewer users are needed for a fixed ensemble size, or if the same number of users carry on with the project then the ensemble sizes could be increased (if that is scientifically interesting). However, ensemble completion times won't have improved proportionally. Here's a normalised estimate of the speed of the machines on which I have run CPDN models plotted against date of purchase, based on 653 models benchmarked across eight machines. The linear fit has a gradient of ~10%, which is a long way short of a speed version of Moore's Law. That's all I meant to say. 
|
|
44)
Message boards :
Number crunching :
Little work, yet the most "important" thing in the world?
(Message 63708)
Posted 17 Mar 2021 by Iain Inglis
Post: The trajectory of increasing model complexity seems quite natural to me. There were global models and then regional ones; slab oceans and then stratified ones; low resolution and then higher resolution; and who knows what internal changes in the science and the parameters. On the computer side there has not been a compensating application of Moore’s Law. Computers are faster but not fast enough; disks are certainly larger and I would guess large enough; memory is cheaper but oddly constrained by operating system and supplier (for Windows on my Dell, at least); the number of cores has increased but the applications have not exploited that because multi-processor implementations don’t necessarily reduce the time for an ensemble of models to complete even if individual models would finish quicker. (PS And it does make me laugh when climate-change deniers say that climate scientists are in it for the money when there isn’t any money!) |
|
45)
Questions and Answers :
Macintosh :
Computer types.
(Message 63707)
Posted 17 Mar 2021 by Iain Inglis
Post: My Mac mini no longer upgrades properly and lots of standard operating system functions don’t work (which it complains about), so I thought of getting a new one. However, the new ones have the M1 chip rather than Intel and that does raise questions about CPDN compatibility, Rosetta conversions notwithstanding. The present state of Mac support isn’t great but the future might be worse unless the project ports the code to a native M1 compiler. |
|
46)
Message boards :
Number crunching :
New work Discussion
(Message 63698)
Posted 14 Mar 2021 by Iain Inglis
Post: [Peter Hucker wrote:]Getting way off topic. The title of this particular topic is "new work discussion". Batches of new work do sometimes produce errors if the parameter boundaries are being pushed and it might be appropriate to discuss those as errors. There are people here who know more than might be expected about the science of climate but most of us don't, so such a discussion might be better located in a separate thread since people concerned about new work will learn little about new work and may indeed find the information they do want obscured. The "invalid theta" error, if I remember correctly, relates to a variable called "potential temperature". There's a helpful Wikipedia article at Potential temperature. |
|
47)
Message boards :
Number crunching :
New work Discussion
(Message 63628)
Posted 8 Mar 2021 by Iain Inglis
Post: [Alan K wrote:]I've picked up 2 of these. One is a168 month model, the other is 240 months. Looks like one trickle per year. Running alongside some N216s. There does seem to be a variety of lengths in that batch. To add to your list I've just got a 360 month version, which will take a long time to run on my ancient Mac. (I had better check the upload limit as, if the Zips are the same size as the 240 month version, then 36 x 95 MB plus restarts is quite large ...) |
|
48)
Message boards :
Number crunching :
New work Discussion
(Message 63583)
Posted 1 Mar 2021 by Iain Inglis
Post: ... got two from batch #837 on my Mac: it looks like a couple of weeks per model on an old Mac mini. |
|
49)
Message boards :
Number crunching :
New work Discussion
(Message 63572)
Posted 1 Mar 2021 by Iain Inglis
Post: Ok: I'll fire up my steam-powered Mac and try to get one. Reissuing an existing WU makes sense but I still don't understand the increase in the total number of WUs in a batch without those additional WUs being visible unless, as I think Les is suggesting, the increase is being done in chunks: there were 5555 in the original batch #837, which now claims to be 7470 (likewise batch #835, which was previously 1689 WUs). |
|
50)
Message boards :
Number crunching :
New work Discussion
(Message 63568)
Posted 1 Mar 2021 by Iain Inglis
Post: Does anyone have a work unit number for one of these additional HADCM3S models? Because I can't see them! (I can see on an internal system that the number of work units in batch #837 has been bumped, but don't understand how that can be if the work units aren't visible, and if they aren't visible then how do users get them?) |
|
51)
Message boards :
Number crunching :
New work Discussion
(Message 63558)
Posted 28 Feb 2021 by Iain Inglis
Post: There are more UK Met Office HadCM3 shorts available.Well that didn't last, I just told 6 machines to grab some, and none are left. ... I'm not sure there were any, as there haven't been any additions to the work unit list. |
|
52)
Message boards :
Number crunching :
Upload failures
(Message 63527)
Posted 9 Feb 2021 by Iain Inglis
Post: And this thread is not about weather.If a conversation drifts (perfectly normal for the English language), where is the button I click to create a link to continue it over there? Make one and I'll use it. The moderators can move posts, but only do that in extremis. If another thread were to be created then any comments in this thread could be easily shifted if requested, but it's more of a meandering conversation here at the moment. Upload failures is the topic of this thread, though, and people looking at the thread might well expect the conversation to be principally about that. |
|
53)
Message boards :
Number crunching :
New work Discussion
(Message 63394)
Posted 23 Jan 2021 by Iain Inglis
Post: [Peter Hucker wrote:]... Different programming? The SAFR region is larger than the EU one and the recent SAFR models 24 months instead of 13 months for the EU models. A factor going the other way is that the resolution of the recent EU models is double that of the SAFR models. The resulting estimated Gflops difference is listed below with a correction factor based on my machines. SAFR50/24 = 7,694,788 Gflops (/ 2.39)  EU25/13 = 2,061,502 Gflops (/ 0.67)  Thus, for example, the SAFR/EU ratio for CPU time on my machines is expected to be (7,694,788 / 2.39) / (2,061,502 / 0.67) = 1.05. The ratio for two models that finished on one of my machines from batch #890 (SAFR/24) and batch #894 (EU25/13) was 345,907.20 / 319,405.60 = 1.08 - i.e. about as expected. |
|
54)
Message boards :
Number crunching :
New work Discussion
(Message 63363)
Posted 21 Jan 2021 by Iain Inglis
Post: Each of the three most recent Windows batches have one success so far. Two on I5 machines, one on an I7 the last being one of Ian's machines. Yes! Painfully reconstructing new Windows 10 machine that finished one from batch #894 — and that was without the SSD that’s finally arrived (after being delayed by you-know-what). |
|
55)
Message boards :
Number crunching :
New Work Announcements
(Message 63346)
Posted 19 Jan 2021 by Iain Inglis
Post: An additional 3024 HADAM4 units have now been added as batch #895 (batch list). |
|
56)
Message boards :
Number crunching :
New work Discussion
(Message 63198)
Posted 28 Dec 2020 by Iain Inglis
Post: ... having said what I did about "Signal 11" I am now a bit surprised that a reissue that previously failed with a "Signal 11" on someone else's machine has now completed on my machine. If it was a parameter error then that shouldn't happen. [Oops - engaged brain: the other machine was AMD and mine is Intel: butterfly flaps its wings in the Amazon etc. - so the model development would have been different on the two machines even if the parameters are the same.] |
|
57)
Message boards :
Number crunching :
New work Discussion
(Message 63181)
Posted 25 Dec 2020 by Iain Inglis
Post: If I may ask, what does "Signal 11" mean? A segmentation fault is a memory error (Wikipedia). This might come from a computation that leads to an array index that isn't checked by the software itself before trying to access the indexed data (for understandable performance reasons). In other words, the temptation is to suppose a hardware memory error but if lots of models are failing, as for this batch, then it looks more like a programming/parameter problem. However, there have also been error messages reported by BOINC applications in which an error number is generated by, say, FORTRAN but is then reported by the BOINC application as if the error number was from the BOINC error world (C, Linux etc.). In such a case the error number is valid but the text reported by the BOINC Manager is not. It's a long time since I systematically investigated this kind of thing - because, happily, my models almost never crash any more - but maybe some BOINC people might have a better answer or the project developers themselves. |
|
58)
Message boards :
Number crunching :
New work Discussion
(Message 63168)
Posted 23 Dec 2020 by Iain Inglis
Post: I managed to snag four WUs of the new SAFR50s from HAPPI, but sadly two of them so far got computational errors (signal 11, segment stuff yet again). I would really like to help with this project given its importance, but I think the other two will eventually fail, too. My computer isn't overtaxed with processes, but it is old. Not sure what you would advise. Hopefully the people who take over my WUs have success. This batch, 890, has a very high error rate, so I wouldn’t worry about the machine. Some models in the batch have finished, so please persist with any model that is still running — but don’t be surprised if the model doesn’t finish. Mine all crashed on all my machines. |
|
59)
Message boards :
Number crunching :
New work Discussion
(Message 62919)
Posted 9 Nov 2020 by Iain Inglis
Post: I was considering putting up with the horrid Linux interface on some machines I only use for Boinc to get more Boinc processing done, but it turns out only a small handful of apps in Boinc are faster in Linux, it just depends on who coded it. Most projects always have Windows work when they have work, so I'm happy with that. And when I looked at the recent posts of sets in another thread, it looks like last year had as much Windows as Linux work. Generally people choose Linux if it suits them for their own reasons or if work is only available on that platform. Microsoft has also annoyed people — including me — because of its update system, which can crash models without a bit of preventive registry editing, I am not aware of any consistent performance bias. Windows doesn't seem to have problems with libraries - it certainly used to, I remember 20-30 years ago having to download dll files for programs, which are I assume the equivalent. I’ve never had a BOINC library problem with Windows. At the risk of going off topic and having an admin yell at me, what advantages do you get running Linux? I used to be told "it's more stable", but I can't remember the last Windows crash. And I'd replace your "bit of a faff" with "a lot of a faff". All I did was try to install Boinc and two projects, then I start having to use a command line to give permission to install?! Microsoft has withdrawn its advice to upgrade to Windows 10 from earlier versions, and that certainly reflects my experience — I had to downgrade from Windows 10 to avoid random blue screens of death. Now I get warnings about updates being withheld but no Windows crashes. I don’t remember ever getting a system crash on Linux. In my experience the only reliable way to get the mods to yell at you is to obsess about credits and even then their patience is admirable. The mods and other interested users are in it for the science and here to help. |
|
60)
Message boards :
Number crunching :
New Work Announcements
(Message 62841)
Posted 3 Nov 2020 by Iain Inglis
Post: There are 2 x 1000 new Southern America models in batches #884 and #885 for Windows, and two new HADAM4 batches for Linux (#882 x 1680, #883 x 1575) - batch list. |
©2024 climateprediction.net