Message boards : Number crunching : HadCM3n release
Message board moderation
Previous · 1 · 2 · 3 · 4
Author | Message |
---|---|
Send message Joined: 31 Aug 04 Posts: 391 Credit: 219,896,461 RAC: 649 |
Uh -- thanks for posting, but -- "exact rounding" is a contradiction in terms, a nonsense. Not possible. Think again please. Provably, ANY FP algo that depends on "stable rounding" will break at some limit There's absolutely and mathematically and computationally no way to avoid the "rounding problems" There's standards like IEEE 754. Which most CPU chips, and compute libs and compilers try to meet, more or less. But no compute system can avoid the "rounding problem" Maybe that's why these models are testing the limits-- not of the theory -- but of how near to the theory computers might get (with their inexact rounding)-- eh? I think that it's mostly the FPU maths, and how Intel and AMD e.g. use different algorithms. And even slight overclocking might change the results of these, because they are so close to the edge of stability. |
Send message Joined: 16 Jan 10 Posts: 1084 Credit: 7,827,799 RAC: 5,038 |
Uh -- thanks for posting, but -- "exact rounding" is a contradiction in terms, a nonsense. Not possible. Think again please. Provably, ANY FP algo that depends on "stable rounding" will break at some limitA PC is a machine and, overclocking aside, the same output will be produced by the same PC for the same inputs. In that sense the micro-results are stable. As Eirik says, different platforms will tend to produce different micro-results because of chip differences, run-time library implementations of cos, sin, log etc.: is that instability or just repeatable difference? When all the micro-results are propagated over many time steps and accumulated into a simulated macro-result (i.e. a whole-world simulation) then there may be radical differences between different combinations of chip/run-time library: in that sense the algorithms are indeed "unstable". One test I have repeatedly run on my own simulations (of physical systems, not climate) is to abstract the real type and all the run-time functions from the software (i.e. float/double in C++) and compare simulation runs at each precision: the test neatly flushes out programming errors, which improves portability, but the physical system results are never significantly different: my prejudice is that, overclocking and hardware failure aside, the micro-instability issue is a distraction for non-chaotic simulations. For a chaotic climate simulation, the "INVALID THETA DETECTED" is a macro-level test and would be expected to behave differently on different platforms. Imagine simulating the dropping of a cannonball from the top of the Leaning Tower of Pisa. The simulated path of the cannonball won't be much affected by rounding errors or platform differences. Now imagine simulating the cloud of dust created when the cannonball hits the ground. A puff of wind, the type of dust, and all sorts of minor factors will tend to amplify small-scale differences between simulations of turbulent clouds of dust particles. What matters is whether the "instability" of the dust calculations departs systematically from reality. My understanding is that for climate models it is generally thought that the micro-instabilities do not introduce a systematic bias, they merely create chaotically different possible realities. |
Send message Joined: 7 Aug 04 Posts: 2187 Credit: 64,822,615 RAC: 5,275 |
This was a paper that was done by some project scientists on specific model runs where operating systems and processor types were assessed as to how they contributed to the variability of output for model simulations. Association of parameter, software and hardware variation with large scale behavior across 57,000 climate models |
©2024 cpdn.org