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.

]]>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

]]>