## 2 Methodology
### Testing of Calculation with 3D Salt Model and Analysis of Efficiency of Multi-GPUs Computation  
The 3D salt model is a model usually used in calculation tests.The velocity model grid size was 901 (subline) \(\times\) 901 (crossline) \(\times\) 250 (depth), at the intervals of 15 \(\times\) 15 \(\times\) 10 m\({}^{3}\), respectively.For the forward calculation, a total of 3134 shots were collected, with the interval between shots was 120 m. There were 16,081 traces for each shot, and the interval between receivers was 30 m. The record of a single trace was 8m long, and the sampling interval was 4 ms. The RTM image calculation was in the shot domain, the imaging aperture was changed to test the efficiency of migration, and the imaging space grid for a single shot was changed from 96 \(\times\) 96 \(\times\) 250 to 450 \(\times\) 450 \(\times\) 250. The hardware used to run the KPSDM is GPU/CPU clusters that consists of 3.40 GHz Intel (R) Xeon (R) E3-1231 v3 CPUs, which had 16 GB of DDR3 memory, andNVIDIA Tesla K40 GPUs; the architecture is Kepler, and the global memory was 12 GB; in total, it had 2880 cores. Figure 10 shows a comparison between the computational efficiency of the CPU and the GPU, and the propagation steps of both were constantly 16,000. Figure 10a shows a comparison between the computing time of a single CPU and GPU, while Figure 10b shows a comparison between the computing time of a single GPU and dual GPUs. It was observed from this that the GPU had significantly higher computing efficiency than the CPU, and the dual GPU had about two-times higher computing efficiency than that of a single GPU, indicating that the application of a stream completely conceals the data transfer between GPUs. When the GPU number are more than two, the image space can be evenly distributed to each GPU nodes, and the source and receiver fields can be calculated parallelly, but because there is chaos between each two GPU, it may need some time for data transfer; the time for data transfer is less than the main space finite difference computation.Thus, in this paper, we have used steams andP2P feature of GPU to conceal this time. Figure 11 is a computation time comparison when the imaging space is 384 \(\times\) 384 \(\times\) 384; we can see that when more GPUs are used, the speedup can be nearly linear. Figure 12 shows a slice (d) of the migration results of the original single-shot record (a) in a 3D salt model, and the data (b,c) modulated with the two offset directions, respectively, as well as the results (e, f) from their migration. Figure 13 shows a profile and some SOGs of it from the image calculation with the 3D salt model. It was found that in the 3D calculation, because the velocity model used in the migration was the correct velocity, the events in the SOGs were flat, which is the ideal status. If the velocity is lower or higher than the correct velocity model, the events will bend up or down, and it will affect the image quality of the seismic profile, that can be achieved by summing up all of the g  
Figure 10: Comparison between the computing efficiency of (a) a single CPU and a single GPU; (b) comparison between computing time of a single GPU and dual GPU. Figure 11: Computation time comparison when use different number of GPUs for the imaging space size is \(384\times 384\times 384\) and time steps is 16,000. Figure 12: Part of single-shot records, modulated results, and imaged depth slices in the calculation of 3D SOGs: **(a)** part of the original single-shot records; **(b)** part of the single-shot records modulated with transverse offset; **(c)** part of the single-shot records modulated with horizontal offset; **(d)** depth slice of the results from the migration of original single shots; **(e)** depth slice of the results from the migration of Figure 12b; **(f)** depth slice of the results from the migration of Figure 12c. Figure 13: Imaging profile of a subline and three SOGs from the 3D salt model RTM migration.