Non-steady relaxation and critical exponents at the depinning transition . Supplemental Material : GPU-based numerical implementation

The acronym GPGPU stands for “General Purpouse Graphics Processing Unit”. GPGPU Computing is a common denomination for the practice of using GPUs (Graphics Processing Units) as a hardware facility to run general-purpouse progarms, apart from rendering graphics (or not). The fact that the GPU is used as an accelerator collaborating with the CPU is only one example of heterogeneous computing. Heterogeneous architectures came to mitigate the technical barriers emerged in the development of faster and faster processors [1]. From a decade on, the gain of GFlops in modern computers is given more by their ability of processing applications in parallel and providing different hardware profits (as cached memory flow) than by their increase in processor clock frequency. As a consequence, software in general was pushed to be programed for parallel performance. The improvement of compilers relieves in some cases the lack of parallel implementations, but in many others, applications have to be re-formulated to fit new architectures. In this sense scientific-computing software is not an exception and we should rethink our usual codes and numerical simulation techniques. Independently of their manufacturer, generation or model, all GPUs share the same Single Instruction Multiple Thread (SIMT) concurrency paradigm in order to exploit their high parallelism and high memory bandwidth[2]. Basically, the programming framework using SIMT paradigm consists in coding for an unlimited number of parallel threads for all practical purposes [3] (typically one thread per component of our system). A remarkable point is that, from the programmer perspective the actual number of cores in our GPU is not important at first glance. Memory issues, on the other hand, arise as the main problem to work out. We code as we were given an unlimited number of parallel processing units, the compiler and a smart thread scheduler do the rest for us [4]. By knowing better our GPU’s characteristics (memory levels and sizes, number of cores, compute capabilities, etc.) we can improve the code, orientate the compiler and take real advantage of the hardware potential. In short, the parallel simulation framework work as follows. The main stream of the program runs in a single core of the CPU (the “Host”). The GPU (or “Device”) is connected to the host through a high speed IO bus slot PCI-Express. The GPU has its own device memory, up to several gigabytes. The Host runs the program’s serial parts, manage data transfers between Host and Device, modifies device memory, and launch kernels that are executed concurrently by hundreds of cores on the Device. These kernels are functions that run on the Device acting exclusively on device memory. We work with NVIDIA GPUs, as it is our available hardware. Simulations for the present work have been run on Fermi architecture (GF100) GPUs, in particular GeForce GTX 470, GeForce GTX 480 and Tesla C2075. In the manuscript we have shown how useful can be the massive parallelism of GPUs in the framework of statistical mechanics simulations, in particular in the study of the Quenched Edwards-Wilkinson elastic line. In this Supplemental Material we present with some detail our GPU implementations of the model wich, even without being developped as a highly optimized codes, have shown to be modest powerful tools.