• Andrew Sheppard

    What do you mean by faster-than-real-time?

    Is it similar to what I do when backtesting HFT strategies, where I replay tick and level 2 data at a rate faster than that at which it was created and captured? Obviously when analyzing past data you want to process it in “faster-than-real-time” and GPUs are great for that.

    Or are you using the term in a predictive fashion? In the sense that you need to do complex calculations in a time-frame far shorter than the decision time. Obviously, a prediction is only useful if it precedes the decision point.

    I’m just trying to fully understand your blog interview.

  • http://babrodtk.at.ifi.uio.no André R. Brodtkorb

    Hello Andrew,

    For these simulations, the aim is (as you suggest) to predict the effect of a flood scenario as fast as possible. For CPU simulations of the shallow water equations, a real-world code can take 1-1.5 (wall clock) hours to simulate one hour of a typical flood scenario. The massively parallel processing of GPUs is (close to) perfectly suited for the type of calculations we do, and this enables us to simulate the same cases in a much smaller time frame.

    For an on-going flood event, speed is of course important to be able to predict what will happen. But it is equally important when planning for a possible flooding/dam break. As there are many different parameters that can affect the simulation results (type of dam break/flooding, water level in the reservoir, etc.), you want to simulate many versions of the same case. Using GPUs, you can simulate far more cases, giving you a better overview of the event which means you have better data to guide you in choosing which areas to evacuate, which levees to reinforce, etc.