Comments on: Wild guess that noisy chips won’t lead to better weather simulations http://insidehpc.com/2009/04/20/scientists-speculate-that-cheap-and-noisy-chips-could-lead-to-better-weather-simulations/ HPC News Without the Noise for Supercomputing Professionals | insideHPC Sun, 19 May 2013 10:46:54 +0000 hourly 1 http://wordpress.org/?v=3.1.1 By: rpl http://insidehpc.com/2009/04/20/scientists-speculate-that-cheap-and-noisy-chips-could-lead-to-better-weather-simulations/#comment-162281 rpl Mon, 20 Apr 2009 22:06:10 +0000 http://insidehpc.com/?p=4514#comment-162281 Rick, There is an important role for ensembles of model runs to play in climate modeling. Ensembles allow you to study the sensitivity of your outputs to variations in initial conditions, changes in the physics parameterizations, and so on. In this case you wouldn't be too worried about producing bit-for-bit identical results from run to run; you would be more interested in the distribution of the outputs. This is not inconsistent with validation because typically the low-order moments of those distributions are all you can reasonably measure anyhow. People who think that every bit in every cell of their double-precision data set is significant are deluding themselves. The problem with the "noisy chip" idea is that you can't just throw any old randomness into the mix and call it an ensemble. You really only want it in the initial conditions; the solvers should be as accurate as possible. You also need the right amount of randomness. An error in the last bit of the mantissa won't even be noticeable; an error in any bit of the exponent will probably crash the calculation. (That is what I was trying to get at on twitter, but these concepts don't translate well into 140 character packages.) Furthermore, on rereading the article, it sounds as if the ECMWF researchers want to use errors in the calculation as a substitute for higher resolution. The idea seems to be that although you don't know the effects of small-scale processes, you can approximate them with random perturbations to the solvers. Even assuming you can get the "right" amount of randomness, it's not clear that this procedure would produce better results (in the sense of a better approximation to a high-resolution calculation) than a microphysics parameterization. To make an analogy, the former represents throwing darts blindly at a target, while the latter represents a thrower of middling ability taking aim as best he can. The aiming thrower probably won't throw a perfect round, but he's sure to have better success than the thrower that makes no attempt to aim at all. Rick,

There is an important role for ensembles of model runs to play in climate modeling. Ensembles allow you to study the sensitivity of your outputs to variations in initial conditions, changes in the physics parameterizations, and so on. In this case you wouldn’t be too worried about producing bit-for-bit identical results from run to run; you would be more interested in the distribution of the outputs. This is not inconsistent with validation because typically the low-order moments of those distributions are all you can reasonably measure anyhow. People who think that every bit in every cell of their double-precision data set is significant are deluding themselves.

The problem with the “noisy chip” idea is that you can’t just throw any old randomness into the mix and call it an ensemble. You really only want it in the initial conditions; the solvers should be as accurate as possible. You also need the right amount of randomness. An error in the last bit of the mantissa won’t even be noticeable; an error in any bit of the exponent will probably crash the calculation. (That is what I was trying to get at on twitter, but these concepts don’t translate well into 140 character packages.)

Furthermore, on rereading the article, it sounds as if the ECMWF researchers want to use errors in the calculation as a substitute for higher resolution. The idea seems to be that although you don’t know the effects of small-scale processes, you can approximate them with random perturbations to the solvers. Even assuming you can get the “right” amount of randomness, it’s not clear that this procedure would produce better results (in the sense of a better approximation to a high-resolution calculation) than a microphysics parameterization. To make an analogy, the former represents throwing darts blindly at a target, while the latter represents a thrower of middling ability taking aim as best he can. The aiming thrower probably won’t throw a perfect round, but he’s sure to have better success than the thrower that makes no attempt to aim at all.

]]> By: Rick Friedman http://insidehpc.com/2009/04/20/scientists-speculate-that-cheap-and-noisy-chips-could-lead-to-better-weather-simulations/#comment-162247 Rick Friedman Mon, 20 Apr 2009 14:20:36 +0000 http://insidehpc.com/?p=4514#comment-162247 This does seem like a bit of a crazy idea. The whole point of simulations is produce reproducible results that you can validate against actual reality. This implies you can run the simulation a second time and get the same results. This kind of system would generate random results that you can't controllably reproduce. Seems like this would invalidate much of the results since it would be difficult or impossible to reproduce them. I worked for a simulation company for a number of years and we got beaten up by customers when results were inconsistent due to small software race conditions. I can't see this approach working in the real world This does seem like a bit of a crazy idea. The whole point of simulations is produce reproducible results that you can validate against actual reality. This implies you can run the simulation a second time and get the same results. This kind of system would generate random results that you can’t controllably reproduce. Seems like this would invalidate much of the results since it would be difficult or impossible to reproduce them.

I worked for a simulation company for a number of years and we got beaten up by customers when results were inconsistent due to small software race conditions. I can’t see this approach working in the real world

]]>