(Erk, what? First posting??! (:-))

From the log:
0008_000024993 - PH 1 TS 001441 - 01/01/1811 00:30 - H:M:S=0001:50:12 AVG= 4.59 DLT= 3.52
0008_000024993 - PH 1 TS 001442 - 01/01/1811 01:00 - H:M:S=0001:50:29 AVG= 4.60 DLT=17.29

So... Is this preparing/simulating for 1811 (200-ish years ago)?

And what are the other numbers for curiosity?

Regards,
Martin

Mandrake 10.0.1 GNU/Linux

> From the log:
> 0008_000024993 - PH 1 TS 001441 - 01/01/1811 00:30 - H:M:S=0001:50:12 AVG=
> 4.59 DLT= 3.52
> 0008_000024993 - PH 1 TS 001442 - 01/01/1811 01:00 - H:M:S=0001:50:29 AVG=

Hi, the dates aren't "absolute historical" -- basically this simulation is in three phases -- the first is a spin-up phase to get the model to equilibrium and get heat fluxes from the "slab" ocean to the atmosphere. The second phase is a "control" of "pre-industrial" CO2 levels "dated" 1825-1840, and the third phase is a "post-industrial" experiment of a doubling of CO2 in the atmosphere dated 2050-2065.

There should be more info at the main cpdn website: http://climateprediction.net

Hi, Martin,

Note, too, that all months are 30 days in length. So, no panic when you soon see Feb 30th.

As Carl noted, there is a lot of good background info on the http://www.climateprediction.net pages and more on the User Pages Forum link (on that Home Page) -- many topics.

The first block of numbers is the run ID,
PH is Phase (1,2,or 3),
TS is Time Step # (259248 TS per Phase, with a Trickle every ~10802 TS),
Date and time are of the model (a TS every 30 minutes of Model time),
H:M:S= is CPU (or wall?) time since run began in hrs/min/sec,
AVG= average time per TS in seconds,
DLT= delta/average over time steps (I don't really understand the source of this one [I thought it had to do with TS not logged on the Console, but now that all are being logged again...?]).

HTH.
________________________________________________
Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral.
-- Paulo Freire (1921-1997), educator, author.

the dlt is just a sort of running average of the last few timesteps, so if they get too high (I think the threshhold is 3 minutes) I can safely assume the model is unstable and either rewind a day/month/year to recalc, or it that's already been done get a new model.

Edit: Wrong, see later posts........

Testing for 'fast processing iceballs' & re-winding without a model.exe crash, nice one Carl - that should improve the 'completed full run' rate a bit. :-)

Do you also test for those slow processing iceballs with 2 metre hailstones..? ;-)

> Testing for 'fast processing iceballs' & re-winding without a model.exe
> crash, nice one Carl - that should improve the 'completed full run' rate a
> bit. :-)

But it looks like he is testing for the slow processing iceballs if it rewinds on a greater than 3 minute timestep. What about fast processing iceballs, the only kind I've had? Or am I misunderstanding something?

Wouldn't the best way to test for model instability be to check all or selected grid points for some surface temperature less than, say, -200C. No stable model should have surface temperatures that low, and it would catch it soon after it went unstable. Of course I don't know how difficult that would be to code?

> > Testing for 'fast processing iceballs' & re-winding without a
> model.exe
> > crash, nice one Carl - that should improve the 'completed full run' rate
> a
> > bit. :-)
>
> But it looks like he is testing for the slow processing iceballs if it rewinds
> on a greater than 3 minute timestep. What about fast processing iceballs, the
> only kind I've had? Or am I misunderstanding something?
>
> Wouldn't the best way to test for model instability be to check all or
> selected grid points for some surface temperature less than, say, -200C. No
> stable model should have surface temperatures that low, and it would catch it
> soon after it went unstable. Of course I don't know how difficult that would
> be to code?

Nope, you're correct geophi, looks like Carl is testing against the 'AVG' s/ts figure for slow processing - I must have had my thinking cap on backwards last night. :lol: I agree that fast processing iceballs (FPIs) seem far more likely than slow processing iceballs (SPIs) - I've had quite a bunch of FPIs over the 11 months that I've been running CPDN on my home farm but nil SPIs, I've only read reports of them on the main CPDN messageboards.

I agree that some form of 'impossibly low' or 'impossibly high' temperature test would be a good idea to trap & force a rewind of unstable models that don't actually crash CP-boinc's 'model.exe' equivalent - Martin Sykes' CPFarmView reads the shared memory & calculates averages for classic CPDN, so it could be done methinks...

well I didn't want to stop all models going unstable because those are the more interesting/fun ones (for the scientists if not the participants). So the only really "bad" condition is when it's minutes per timestep, since that hurts users stats & hogs up the CPU etc.

I don't mind running <i>any</i> models that are still running okay Carl but 'fast processing iceballs' <i>ought</i> to have crashed with the whole surface at -273C - they <i>do</i> crash if you restart them but they <i>do not</i> crash on their own... :-(

When you restart a 'fast processing iceball' manually that <i>hasn't</i> processed past all of it's three rewind save points, then it will just rewind to one of them and resume processing normally <i>but</i>, if it has already processed past all of those three save points in 'fast processing iceball' mode (Which takes very few hours on a fast machine.) then SPLAT, instant short run results upload. The whole run to date is then a complete waste of CPU cycles because, without any rewinds at all, it is impossible to determine if that particular short run was caused by inherent instability of the parameter set or a machine error - the only way to be sure is to re-run it from scratch - thus 'data' from that run cannot be of <i>any</i> possible use to the team's scientists.......!?!? :-(

Note: I have restarted one 'fast processing iceball' model from backup that completed a full run - that particular 'fast processing iceball' <i>must</i> have been caused by a machine error...

I would like to know wheather also geographical preassumptions like vegetation, mountains, something like the Gulf Stream and maybe vulcanos,... are considerd.

My second question is, whether somebody could explain to me how it is possible (possible is all) to have a region with -14°C surrounded with a region of +20°C.
(Phase 1; 1811)
<a href="http://www.adastrawithseti.de"><img src="http://adastrawithseti.de/pic/logo.jpg"></a>

Greetings from Berlin(Germany)
Basti

Well baby steps first...


then further refinements to walking, running, and then dancing and acrobatics.


It's going to take alot of seemingly 'bad' data probably to be able to come up with good models. This is a long haul project for sure.
<a href="http://usa.duane-n-lisa.net"><img src="http://usa.duane-n-lisa.net/signature.php?id=1918"></a>

&gt; Well baby steps first...
&gt;
&gt;
&gt; then further refinements to walking, running, and then dancing and
&gt; acrobatics.
&gt;
&gt;
&gt; It's going to take alot of seemingly 'bad' data probably to be able to come up
&gt; with good models. This is a long haul project for sure.

Sure CP-boinc is new but we've been running CPDN classic for 11 months already - I haven't seen any problems with fast processing iceballs under CP-boinc as yet, I haven't run it long enough, but, if it's basically the same hadsm3 model &amp; AFAIK, it is, then they <i>will</i> occur and they're a significant waste of resources methinks...

&gt; I don't mind running <i>any</i> models that are still running okay Carl but
&gt; 'fast processing iceballs' <i>ought</i> to have crashed with the whole surface
&gt; at -273C - they <i>do</i> crash if you restart them but they <i>do not</i>
&gt; crash on their own... :-(
&gt;
&gt; When you restart a 'fast processing iceball' manually that <i>hasn't</i>
&gt; processed past all of it's three rewind save points, then it will just rewind
&gt; to one of them and resume processing normally <i>but</i>, if it has already
&gt; processed past all of those three save points in 'fast processing iceball'
&gt; mode (Which takes very few hours on a fast machine.) then SPLAT, instant short
&gt; run results upload. The whole run to date is then a complete waste of CPU
&gt; cycles because, without any rewinds at all, it is impossible to determine if
&gt; that particular short run was caused by inherent instability of the parameter
&gt; set or a machine error - the only way to be sure is to re-run it from scratch
&gt; - thus 'data' from that run cannot be of <i>any</i> possible use to the
&gt; team's scientists.......!?!? :-(
&gt;
&gt; Note: I have restarted one 'fast processing iceball' model from backup that
&gt; completed a full run - that particular 'fast processing iceball' <i>must</i>
&gt; have been caused by a machine error...
&gt;
Right. Exactly as UK_Nick states. Going frozen earth for years on end in a fast processing iceball is not a result that helps the scientists. One would hope that a rewind to catch a model error (hardware or otherwise) would go back to a "stable" point instead of rewinding to a saved -273 earth. In other words, no month/year restart point should have an earth at -273C, which may well happen in fast processing iceballs. Something needs to catch the model before a restart month/year is saved with a -273C earth.

&gt; My second question is, whether somebody could explain to me how it is possible
&gt; (possible is all) to have a region with -14°C surrounded with a region of
&gt; +20°C.

It's almost certainly a colour mapping problem at the top end of the scale. Have a look at the thread <a href="http://climateapps2.oucs.ox.ac.uk/cpdnboinc/forum_thread.php?id=32">here</a>

<a href="http://climateapps2.oucs.ox.ac.uk/cpdnboinc/team_display.php?teamid=3"><img src="http://www.teampicard.net/templates/fisubice/images/phpbb2_logo.jpg"></a>

&gt; well I didn't want to stop all models going unstable because those are the
&gt; more interesting/fun ones (for the scientists if not the participants). So
&gt; the only really "bad" condition is when it's minutes per timestep, since that
&gt; hurts users stats &amp; hogs up the CPU etc.
&gt;

Can anyone please explain why a timestep should take longer - apart from the radiation timesteps when we do some extra processing. I've never heard a reasonable explanation of what the computer is actually doing which is taking so long.

&gt; Can anyone please explain why a timestep should take longer - apart from the
&gt; radiation timesteps when we do some extra processing. I've never heard a
&gt; reasonable explanation of what the computer is actually doing which is taking
&gt; so long.
I was intrigued as to what was the rational behind the HadSM3 model and how it works, so I’m not so sure that any of these are exactly what you require, but here goes:

http://www.meto.gov.uk/research/hadleycentre/pubs/HCTN/HCTN_45.pdf (1.4 MB)
http://www-atm.atm.ox.ac.uk/user/gillett/um/index.html
http://www.climateprediction.net/board/viewtopic.php?t=2146

I’m still wondering about the computation side of things, maybe you’ll have better luck than I!
UK4CP @ www.uk4cp.co.uk (United Kingdom Group) Celeron 2.6GHz XP Pro SP1 768MB RAM