An operator points at a cluster it already owns and asks whether the model you are proposing can be trained on it. The thing being pointed at is a petaflop figure from a public list. Answering that question honestly means first asking which of the machine's ceilings that figure describes, because the two workloads under discussion, depth imaging and transformer training, sit on opposite sides of the same plot, and only one of them can spend the difference.
The majors already own the machines, and they publish the numbers
This is not a hypothetical about future procurement. Eni's HPC7 entered the June 2026 TOP500 at rank 6 with 571 PFlop/s sustained and 861 PFlop/s peak, on 13,920 AMD Instinct MI300A accelerators across 3,480 nodes, and was 11th on the Green500 at 65.426 GFlops/W [1]. The previous generation, HPC6, sat at rank 8 in the same list with 477 sustained and 606 peak [1], built from 13,888 AMD Instinct MI250X GPUs across 3,472 nodes with 64-core AMD EPYC CPUs, installed at Eni's Green Data Center at Ferrera Erbognone near Milan [2]. Taken together Eni quotes the pair at 1,048 PFlop/s sustained [1].
TotalEnergies announced Pangea III on 18 June 2019 at 31.7 petaflops with 76 petabytes of storage, built by IBM, ranked first in the energy industry and 11th globally, and listed its applications as seismic imaging, reservoir simulation, asset valuation, molecular modelling and AI algorithm development [3]. Saudi Aramco's Dammam-7 entered the list at rank 10 in November 2020 with 22.40 PFlop/s Rmax against 55.42 PFlop/s Rpeak on 672,520 cores with NVIDIA Tesla V100 SXM2 accelerators, and by June 2026 it had drifted to rank 96 [4]. Petrobras bought Pegaso at almost 21 petaflops of peak on 2,016 GPU accelerators with 678 terabytes of memory and a 400 Gb/s network, following Fenix at 5.37 petaflops, Atlas at 8.85 and Dragao at 14.01, all of them bought to accelerate geophysical and geological data processing [5].
Four operators, eight named machines, a dozen public petaflop figures. All of them are the same kind of number.
The list is an FP64 list, by rule
The TOP500 ranking is HPL, and the project's own benchmark rules are specific about what that means. The operation count for the algorithm must be 2/3 n^3 + O(n^2) double precision floating point operations, and the rules explicitly exclude algorithms that compute a solution in a precision lower than full 64-bit floating point arithmetic and then refine it iteratively, along with methods that emulate floating point arithmetic in software using integer arithmetic [6].
So Rmax and Rpeak are FP64 ceilings. Nothing else. A machine whose datasheet promises an order of magnitude more throughput in 16-bit formats gets no credit for it on this list, and correctly so, because the list is measuring one specific thing.
It is worth reading those two columns against each other before going further. Eni's HPC6 achieved 78.7% of its own theoretical peak on HPL, HPC7 achieved 66.3%, and Dammam-7 achieved 40.4%. Even inside FP64, the compute roof is an upper bound the machine does not reach.
Two workloads, one plot, opposite sides
The model that makes this legible is thirty years old in spirit and 17 in its canonical form. Williams, Waterman and Patterson set out the roofline as a way of reading attainable performance as the smaller of two ceilings: the peak flop rate of the arithmetic units, and the peak memory bandwidth multiplied by the kernel's arithmetic intensity [7]. Written out,
where I is arithmetic intensity in FLOP per byte of DRAM traffic, B is memory bandwidth in bytes per second and Pi_peak is the peak flop rate for the precision in use. The two roofs meet at the ridge point,
Everything to the left of I* is bandwidth bound. Read the left branch again: attainable performance is B times I. The precision of the arithmetic does not appear in it. Not as a small term, not as a second-order correction. It is not in the expression.
Everything to the right of I* is compute bound, attainable performance is Pi_peak, and precision is the only thing in the expression.
Where the wave equation sits
Reverse-time migration and full-waveform inversion both spend their budget in the same inner loop: a finite-difference stencil applied to a wavefield grid, forward and adjoint, for every shot and every iteration. The Devito authors state the character of that kernel plainly. Intel VTune confirmed that, unsurprisingly, isotropic is a memory-bound kernel, and the aggressive optimisation mode has no impact on isotropic due to the memory-bound nature of the code [8].
That paper gives no FLOP-per-byte figure, so here is the derivation rather than an attribution. Take the second-order-in-time, eighth-order-in-space isotropic acoustic update, which is the common default. A three-dimensional star stencil of space order 2N touches 6N + 1 distinct grid points, which is 25 taps at N = 4. Counted the way a stencil compiler emits it, the Laplacian costs one add and one coefficient multiply per symmetric pair u[i+k] + u[i-k], so 2N per axis and 6N across three axes, plus one multiply for the centre tap, whose coefficient is the sum of the three axial centre terms. That leaves 3N + 1 products to be summed, and summing 3N + 1 values takes 3N adds. The Laplacian is 6N + 1 + 3N, so 9N + 1, or 37 FLOPs: at N = 4, twelve pair adds, 13 multiplies and twelve accumulations. The time update adds five more, one to double the current field, one to subtract the previous field, one to scale the Laplacian by the squared timestep, one to divide by the model parameter, one to sum. 42 FLOPs per updated grid point.
The compulsory traffic is four eight-byte streams: read the current wavefield, read the previous wavefield, read the model parameter, write the next wavefield. 32 bytes. So
Count it as generously as anyone would defend, two FLOPs per tap with one fused away plus the same five, and you get 54 over 32, or 1.69. Both numbers sit far to the left of every ridge point in this fleet: the closest approach in the whole set, the generous 1.69 against the V100's 8.67, is still a factor of five.
Where the transformer sits
A dense square GEMM of order n performs 2n^3 FLOPs and moves 3n^2 operands, so its intensity is
for a b-byte operand. At n = 4096 with eight-byte operands that is 341 FLOP per byte; halve the operand width and it doubles. Transformer training is a stack of these, and it lives far to the right of the ridge, hard against the compute roof, where the width of the arithmetic is the whole story.
The shear, on one datasheet line
Now put the two facts together on a single part. AMD's datasheet for the MI250X, the accelerator in Eni HPC6, gives peak FP64/FP32 vector at 47.9 TFLOPS, peak FP64/FP32 matrix at 95.7 TFLOPS, peak FP16/BF16 at 383.0 TFLOPS, and memory bandwidth up to 3.2 TB/s [9]. That is a ridge point of 47.9 / 3.2 = 14.97 FLOP per byte for the FP64 vector roof, and a ceiling ratio of 383.0 / 47.9 = 7.996, which the readouts in the exhibit below print as 8.00x.
The MI300A in HPC7 reads 61.3 TFLOPS FP64 vector, 122.6 FP64 matrix, 490.3 TF32 matrix, 980.6 FP16 and BF16, against 5.3 TB/s, with the sparsity column left unused [10]. Ridge point 61.3 / 5.3 = 11.57. Ceiling ratio 980.6 / 61.3 = 15.997, printed as 16.00x. The NVIDIA V100 SXM2 in Dammam-7 reads 7.8 TFLOPS double precision, 15.7 single, 125 tensor, against 900 GB/s [11], for a ridge point of 8.67 and a ratio of 16.03.
Across one generation of the same Eni fleet, three ceilings moved by three different factors. The low-precision ceiling grew by 2.56 times, the bandwidth that governs the stencil grew by 1.66, and the FP64 ceiling grew by 1.28. Three different numbers for the sentence "the machine got faster", and a single headline petaflop figure tells a buyer which of the three it is only if the buyer asks.
The exhibit is the argument in one control. Start where it opens, on the MI300A at FP16 with the lever at 341 FLOP per byte: the amber GEMM marker sits on the low-precision roof and the hero readout says 16.00x. Now walk the precision pills back to FP64 vector. The GEMM marker falls by a factor of 16 and the hollow stencil marker at 1.31 FLOP per byte does not move at all, because it sits inside the shaded band to the left of the amber ridge line where both roofs are the same bandwidth diagonal. The stencil gain readout says 1.00x for every pill on every accelerator, and it says so by cancellation rather than by rounding: both the numerator and the denominator are B times I. Switch to the MI250X and the same walk is worth 8.00x on one marker and still nothing on the other, and the amber ridge line moves from 11.57 to 14.97.
A peer will object at this point, and the objection is correct. Storing the wavefield in 32 bits rather than 64 halves the traffic term and doubles the stencil's arithmetic intensity to 2.625 FLOP per byte, and that genuinely does buy roughly a factor of two. But look at where the gain comes from on the plot: the marker slides to the right along the same bandwidth diagonal. It is a traffic reduction cashed against the bandwidth roof, and it stops at whatever the field can tolerate numerically. It is not the low-precision compute ceiling. Drag the lever from 1.31 to 2.63 with FP16 selected and watch the hero readout, precision gain at the GEMM marker, hold at 1.00x the whole way. Two different levers, two different roofs, and only one of them is what the FP16 headline is selling.
What to ask when someone points at an owned machine
The practical version is short. When a proposal leans on an operator's existing HPC, ask which roof the proposed workload runs against, then ask for the kernel's arithmetic intensity and the part's memory bandwidth, and compute the ridge point yourself. If the workload lands left of it, the machine's low-precision headline is not a resource that workload can spend, and a generational upgrade will deliver the bandwidth ratio and not the flop ratio. If it lands right of it, the FP64 figure on the public list understates the machine by the ceiling ratio, and the relevant question becomes numerical stability rather than throughput.
The same test cuts both ways, which is what makes it useful. It is a reason to be sceptical of an AI proposal that quotes an FP64 petaflop figure as its capacity argument, and equally a reason to be sceptical of a seismic proposal that quotes an FP16 one.
Our own bench is on the right-hand side, and we should say so
We have never run production RTM or FWI. Every number above about the wave equation is either a published statement from the Devito authors or arithmetic on the stencil itself, not a measurement from our own cluster.
What we have run, from our own delivery experience, is the other side of the plot. The research bench for a confidential subsurface programme was an on-prem DGX A100 stack, forced on-prem by an NDA clause and MIG-partitioned so that one fleet carried 60 to 90 concurrent training runs at 80 to 90% sustained utilisation (MIG-Partitioning an A100 to Run 60 Experiments at Once). On that bench, mixed precision paid. Storing activations at two bytes per value instead of four is what let the worst-case scanned log, 12,800 pixels wide by up to 640 tall, fit at batch size 1 (Half the Bits, Twice the Headroom).
That work paid precisely because it lived to the right of the ridge point, where precision is allowed to matter. Reporting it as evidence that half precision speeds up seismic imaging would be reading a result off the wrong side of the plot, and the exhibit above exists so that nobody on either side of a proposal has to take that on trust.
Limitations
The roofline is a ceiling model and it is deliberately crude. It assumes perfect overlap of compute and memory traffic, ignores cache hierarchy and NUMA effects, ignores the interconnect entirely, and says nothing about I/O, which on a real seismic cluster is frequently the binding constraint rather than either roof. The stencil intensity of 1.3125 FLOP per byte is a compulsory-traffic figure for one specific kernel, second order in time and eighth order in space, isotropic acoustic, with the wavefield in FP64 and no temporal blocking; anisotropic TTI kernels carry more arithmetic per point, and cache blocking schemes that reuse the wavefield across timesteps raise the effective intensity, though not by anything close to the order of magnitude that would move the marker across the ridge. Peak rates in the exhibit are vendor theoretical peaks, not measured throughput, and the gap between the two is exactly the gap between Rpeak and Rmax on the public list. The three accelerators are the parts fitted to the named machines, not a claim about what any of those operators runs on them.
References
[1] Eni. Eni ranks as world's leading company in TOP500 global ranking. Eni press release, June 2026. HPC7 at rank 6 with 571 PFlop/s sustained and 861 PFlop/s peak on 13,920 AMD Instinct MI300A across 3,480 nodes; HPC6 at rank 8 with 477 and 606; combined 1,048 PFlop/s sustained; HPC7 11th on the Green500 at 65.426 GFlops/W. https://www.eni.com/en-IT/media/press-release/2026/06/eni-ranks-as-world-s-leading-company-top500-global-ranking.html
[2] Eni. Eni launches the supercomputer HPC6, on the TOP500 list. Eni press release, 18 November 2024. Peak 606 PFlop/s, sustained 477 PFlops, rank 5 on the list released that day, 13,888 AMD Instinct MI250X GPUs across 3,472 nodes with 64-core AMD EPYC CPUs, at the Green Data Center in Ferrera Erbognone. https://www.eni.com/en-IT/media/press-release/2024/11/eni-launches-supercomputer-hpc6-top500-list.html
[3] TotalEnergies. Total's Pangea III supercomputer ranked first in the industry worldwide. Press release, 18 June 2019. 31.7 petaflops, 76 petabytes of storage, built by IBM, 11th globally. https://totalenergies.com/media/news/press-releases/totals-pangea-iii-supercomputer-ranked-first-industry-worldwide
[4] TOP500. Dammam-7, Saudi Aramco. System 179885. Rmax 22.40 PFlop/s, Rpeak 55.42 PFlop/s, 672,520 total cores, NVIDIA Tesla V100 SXM2, rank 10 in November 2020 and rank 96 in June 2026. https://top500.org/system/179885/
[5] Morgan, T. P. Atos notches up another win with Pegaso supercomputer at Petrobras. The Next Platform, 27 July 2022. Pegaso at almost 21 petaflops peak on 2,016 GPU accelerators, 678 terabytes of memory, 400 Gb/s network; Fenix 5.37 petaflops at rank 161, Atlas 8.85 at rank 116, Dragao 14.01 at rank 60. https://www.nextplatform.com/2022/07/27/atos-notches-up-another-win-with-pegaso-supercomputer-at-petrobras/
[6] TOP500. The Linpack Benchmark. Benchmark rules: the operation count must be 2/3 n^3 + O(n^2) double precision floating point operations, and algorithms computing a solution in a precision lower than full 64-bit floating point arithmetic are excluded. https://top500.org/project/linpack/
[7] Williams, S., Waterman, A., and Patterson, D. A. Roofline: an insightful visual performance model for multicore architectures. Communications of the ACM 52(4), 65 to 76 (2009). DOI 10.1145/1498765.1498785. https://dblp.org/rec/journals/cacm/WilliamsWP09.html
[8] Luporini, F., Louboutin, M., Lange, M., Kukreja, N., Witte, P., Huckelheim, J., Yount, C., Kelly, P. H. J., Herrmann, F. J., and Gorman, G. J. Architecture and performance of Devito, a system for automated stencil computation. arXiv:1807.03032. https://ar5iv.labs.arxiv.org/html/1807.03032
[9] AMD. AMD Instinct MI200 series accelerators data sheet. MI250X column: 220 compute units, 14,080 stream processors, peak FP64/FP32 vector 47.9 TFLOPS, peak FP64/FP32 matrix 95.7 TFLOPS, peak FP16/BF16 383.0 TFLOPS, 128GB HBM2e on an 8,192-bit interface, memory bandwidth up to 3.2 TB/sec. https://www.amd.com/content/dam/amd/en/documents/instinct-tech-docs/instinct-mi200-datasheet.pdf
[10] AMD. AMD Instinct MI300A APU data sheet. 24 Zen 4 cores and 228 CDNA 3 compute units, FP64 vector 61.3 TFLOPS, FP64 matrix 122.6, FP32 vector 122.6, TF32 matrix 490.3, FP16 980.6, BFLOAT16 980.6, 128 GB HBM3, memory bandwidth 5.3 TB/s maximum peak theoretical. https://www.amd.com/content/dam/amd/en/documents/instinct-tech-docs/data-sheets/amd-instinct-mi300a-data-sheet.pdf
[11] NVIDIA. NVIDIA V100 Tensor Core GPU data sheet. SXM2 column: double precision 7.8 TFLOPS, single precision 15.7 TFLOPS, tensor performance 125 TFLOPS, memory bandwidth 900 GB/sec. https://images.nvidia.com/content/technologies/volta/pdf/volta-v100-datasheet-update-us-1165301-r5.pdf
