Mark Wakefield, Eclipse development manager, Schlumberger, with help from Fortran complier developers at Polyhedron Software, described tests with graphics processing units (GPUs) for fluid flow simulation. Schlumberger’s Eclipse flagship already has an established Fortran/MPI code base while the new Chevron-backed Intersect simulator leverages C++/MPI, targeting scalability and very large models. Schlumberger has been evaluating GPUs 10 megacell models. Nvidia’s Cuda code library gives promising scalability for up to 500 threads. But overall, the GPU-based solver showed a 2-3 x speedup for up to a million grid blocks, with a ‘modest’ effort. Schlumberger is now working on ‘massively parallel recursive’ algorithms that are hoped to provide scalability on larger datasets. Wakefield noted that scientific code has a long life time and that working with non-proprietary standards has enabled Eclipse to adapt to operating system, hardware and interconnect evolution. Along with Cuda, Schlumberger is investigating solutions such as Intel ArBB1, the Oxford Parallel Library2 and Nvidia’s Thrust3.
Kathy Yelick of the Lawrence Berkeley National Laboratory looked ahead to the ‘new world order’ of ‘exascale’ computing. Exascale is the projected compute power that will be available over the next 5 to 10 years. But the path to exascale will likely be a rough road as pure compute horsepower is limited by power considerations and performance will increasingly come from parallelism and ‘heterogeneity,’ i.e. many small, energy efficient cores running under control from (at least) one fat core for the operating system. Such systems may be efficient but they are getting harder and harder to program. In part this is because we like to use general purpose hardware. One answer may be to co-design hardware along with software à la Green Flash/Tensilica4 or the FPGA Verilog/ASIC emulator. Early intervention in hardware design means optimizing for what is important—energy, data movement etc. The approach allows for the use of languages that support machine abstractions. Code generators and autotuners will optimize communications.
Henri Calandra (Total), John Etgen (BP) and Scott Morton (Hess) made a valiant attempt to answer the question, ‘What can we do with an exaflop system?’ It seems like seismic depth imaging has already entered something of a nirvana realm of full wave equation migration on complex geology at (quite) high resolution. The speedup from Petaflop (2010) to Exaflop (2020) will see more of the same trends and the introduction of full elastic WEM by circa 2015 (50hz and 100hz by 2020). Seismics is lucky in that it is ‘naturally’ parallel. While the goal of a single compute node per shot is desirable, seismics does not present the same scalability ‘gotchas’ as other Department of Energy simulations. More of a concern is programmability and reliability/fault-tolerance. There is also a desire to continue to leverage ‘commodity’ components.
The debate5 on Exascale computing highlighted the shortcomings of current systems. For seismics, one node per shot is desirable but as the notion of a ‘core’ is shrinking, this objective is receding. In fact, parallelism is still under-utilized as most routines are still ‘compute bound.’ Elsewhere, I/O is the bottleneck—today’s GB/s disk bandwidth is totally inadequate for some tasks—Etgen wants terabyte storage bandwidth. Seismics is still ‘all about resorting, shuffling data.’ Presentations available on www.oilit.com/links/1104_7.
© Oil IT Journal - all rights reserved.