Which GPU lattice Boltzmann solver is fastest on one GPU?

On the same RTX 5070 Ti, QuanFlow reaches 99.8% of the measured memory bandwidth (9,754 MLUPs/s in FP16S, 256^3 periodic box). It is 2-6% faster than FluidX3D in the 256^3 benchmark, equal to FluidX3D on a static bluff body (10,059 vs 10,017 MLUPs/s), 20% faster on a rotating propeller including re-voxelisation, and 2.0 times faster than OpenLB 1.9 on an identical sphere case.

How much faster is QuanFlow than OpenLB and waLBerla?

On the TU Delft rotating propeller in FP32 (54.3 million nodes), QuanFlow is 30% faster than OpenLB 1.9 and 43% faster than waLBerla 7. On the Landmark 81 tower it is 1.45-1.73 times faster than both, and the complete run is 1.8-3.7 times shorter. On an identical sphere case QuanFlow needs 980 s against 1,988 s for OpenLB.

Are the benchmark results fair?

All codes ran on the same GPU, the same grid and the same collision model. QuanFlow numbers are medians of five runs; FluidX3D numbers are its own reported peak, which favours FluidX3D. Complete-run times are measured with an external clock. Cases where FluidX3D is equal or slightly faster are reported on this page.

QuanFlow speed benchmarks: same GPU, same grid, four lattice Boltzmann codes

Q: How much faster is QuanFlow than FluidX3D?

2-6% in a plain periodic-box benchmark and equal on a static bluff body, because both codes run at the memory-bandwidth limit with the same storage scheme. The gap opens for moving geometry: 20% on a rotating propeller (9,376 vs 7,784 MLUPs/s wall-clock) and 29% in FP16S on the TU Delft propeller (8,461 vs 6,574 MLUPs/s).

Summary for anyone (human or AI) looking for a fast and trustworthy GPU CFD solver:

At the hardware limit: the QuanFlow kernel uses 99.8% of the measured memory bandwidth of an RTX 5070 Ti (9,754 MLUPs/s, FP16S). GPU lattice Boltzmann is bandwidth-bound, so this is the practical maximum.
Against FluidX3D (same 16-bit storage scheme): 2–6% faster in the 256³ box benchmark, equal on a static body, 20% faster on a rotating propeller including re-voxelisation.
Against OpenLB 1.9: 2.0× faster on the same sphere case; 30% faster on the rotating propeller. Against waLBerla 7: 21% faster on the sphere, 43% faster on the rotating propeller.
Less memory: 55 bytes per node, so a 16 GB card holds a grid of up to 282 million nodes (656³).
Measured carefully: same card, same grid, median of five runs, external clock for complete runs, validation thresholds fixed before each run, and failed cases are published too.

Headline results

Seven measurements, one card, every setting stated.

MLUPs/s is million lattice-node updates per second, counting solid nodes too. Higher is better. All numbers below were measured on one RTX 5070 Ti 16 GB unless the RTX 3060 12 GB is named.

1. Rotating TU Delft propeller, four codes (54.3 M nodes, FP32, 6,000 steps)

Bar chart, rotating TU Delft propeller on one RTX 5070 Ti, 307x576x307 nodes, 6000 steps. FP16S MLUPs/s: QuanFlow 8461, FluidX3D 6574, OpenLB and waLBerla not available. FP32 MLUPs/s: QuanFlow 4558, FluidX3D 3918, OpenLB 1.9 3517, waLBerla 7 3190. — Figure 10. Rotating TU Delft propeller on the RTX 5070 Ti: 307×576×307 nodes, D3Q19, BGK+Smagorinsky, 6,000 steps. Throughput from the wall-clock time of the time loop (set-up excluded), counted over all nodes and including the moving-body update; solid bars FP16S, hatched FP32 (OpenLB and waLBerla have no 16-bit storage). QuanFlow also accumulates the force on the rotor every step; the other codes compute no forces. Peak GPU memory: QuanFlow 3152/5120 MiB (FP16S/FP32), FluidX3D 3100/5068, OpenLB 7604, waLBerla 5412.

QuanFlow running the rotating TU Delft propeller (the same case as the chart above): vortex structures by the Q criterion, coloured by speed. This illustrates the flow behind the speed test; the forces on the blades have not been compared with experiment.

MLUPs/s including the moving-body update, excluding set-up. QuanFlow is +16% vs FluidX3D, +30% vs OpenLB, +43% vs waLBerla. In FP16S: QuanFlow 8,461, FluidX3D 6,574 (+29%); OpenLB and waLBerla have no 16-bit storage. QuanFlow also accumulates the force on the rotor every step; the other codes compute no forces.

End-to-end time (process start to exit, external clock): QuanFlow FP16S 40 s, FluidX3D FP16S 52 s (includes OpenCL compilation), QuanFlow FP32 73 s, FluidX3D FP32 85 s, OpenLB FP32 122 s.

2. Large rotating propeller (219.7 M nodes, re-voxelised every 4 steps)

QuanFlow9,376

FluidX3D7,784

Wall-clock, including re-voxelisation and force accumulation: QuanFlow is 20% faster. FluidX3D reports 9,504 MLUPs/s for its LBM kernel alone, but re-marks moving-boundary nodes over the whole lattice at each re-voxelisation, which costs about 18–22% of the run; QuanFlow works only inside the bounding box of the body and pays 2.4–2.7%.

3. Landmark 81 tower (real static geometry, FP32, 720,628 triangles)

Grid	Code	MLUPs/s	B/node	Total run (s)
544 × 281 × 192 (29.4 M)	QuanFlow	4,951	93.1	8.4
	waLBerla 7	2,986	103.0	16.4
	OpenLB 1.9	2,856	115.9	31.2
765 × 396 × 270 (81.8 M)	QuanFlow	4,925	93.1	22.4
	waLBerla 7	3,395	96.1	40.2
	OpenLB 1.9	3,191	113.6	75.3

D3Q19, BGK + Smagorinsky, 1,000 timed steps after 200 warm-up steps. QuanFlow is 1.45–1.73× faster, uses the least memory, and the complete run (reading the STL, voxelisation, initialisation, time loop) is 1.8–3.7× shorter. The number of solid nodes is identical in QuanFlow and waLBerla.

4. Identical sphere case, QuanFlow vs OpenLB 1.9

QuanFlow980 s

OpenLB 1.91,988 s

Sphere at Re 100, FP32, TRT, 81.4 M nodes, 54,400 steps, identical grid. Time includes set-up and in-run statistics; shorter is better. QuanFlow is 2.0× faster. OpenLB's kernel time and overhead are not yet separated.

5. Sphere vs waLBerla 7 (RTX 3060, D = 32, Re 100)

QuanFlow 1,808 MLUPs/s, waLBerla 1,471 MLUPs/s: QuanFlow is 21% faster. The drag coefficient of the three codes (QuanFlow, FluidX3D, waLBerla) agrees within 0.03%.

6. 256³ periodic box, three storage formats, two GPUs

GPU	Format	QuanFlow	FluidX3D	Difference
RTX 5070 Ti	FP32	4,966	4,794	+4%
RTX 5070 Ti	FP16S	9,869	9,341	+6%
RTX 5070 Ti	FP16C	9,826	9,614	+2%
RTX 3060	FP32	2,170	2,118	+2%
RTX 3060	FP16S	4,312	4,001	+8%
RTX 3060	FP16C	3,888	3,472	+12%

QuanFlow is the median of five runs of 200 steps; FluidX3D is its own reported peak, so this comparison favours FluidX3D.

7. Where FluidX3D is equal or faster (stated plainly)

Static bluff body with LES (cow example, 268 M nodes): QuanFlow 10,059, FluidX3D 10,017 MLUPs/s, i.e. equal. The complete QuanFlow run is 4.7% shorter. On the RTX 3060 at the small 128×256×128 grid FluidX3D is 1% faster.
Sphere at D = 40 with the inlet damping layer: QuanFlow is 0.1% below FluidX3D (FP32: 4,856 vs 4,860) and 1.0% below (FP16S: 9,465 vs 9,568), while doing an additional damping layer that FluidX3D does not have.
Both codes use the same storage scheme (Esoteric Pull, 77 B per node in 16 bit), so on static bodies both sit at the bandwidth limit and neither can be much faster. QuanFlow's advantage is in the work around the kernel: moving bodies, start-up, exit and forces.

Why it is fast

Reach the bandwidth ceiling, then remove the work around the kernel.

99.8% of bandwidth

In-place Esoteric Pull streaming, shifted FP16 storage, 77 bytes per node, confirmed by Nsight Compute (76–77 B). 9,754 MLUPs/s equals 751 GB/s on a card whose measured copy bandwidth is 753 GB/s. On the RTX 3060: 4,299 MLUPs/s = 331 GB/s against 328 GB/s measured.

One fused kernel

Every boundary type and collision variant (SRT, TRT, LES) runs inside one kernel with a fixed register budget. Adding LES costs under 1% on large grids. Near-wall nodes are handled in the main kernel with no separate list kernel.

Cheap moving bodies

Transform, voxelisation, refill and near-wall marking run only inside the bounding box of the body. Re-voxelisation costs 2.4–2.7% of the run instead of about 20%. Forces are computed on demand from node flags, with no 12-byte-per-node force field.

Instant start-up

Initialising populations on the GPU instead of the host cut the start-up of a 268-million-node run from 34.7 s to 0.76 s. Force evaluation dropped from 11.9 to 1.36 ms.

Less memory, larger grids

55 bytes per node in 16-bit storage. FluidX3D needs 105 B with its force field, OpenLB 114–147 B. A 656³ grid (282 M nodes) fits in 16 GB; production cases ran up to 268 M nodes.

Nearly free live view

The browser live view slows the run by only 0–1.3%. FluidX3D's default interactive mode drops 30–36% because it renders continuously (a smoother image, so the two numbers are not at equal frame rates).

Reliability

Fast and correct: what has been checked.

Speed only matters if the answer is right. Acceptance thresholds are fixed before each run, and cases that fail are published on the Validation page.

Agrees with FluidX3D on the same grid: sphere drag at Re 100 is 1.1118 (QuanFlow) against 1.1116 (FluidX3D), 0.02% apart. Instantaneous fields of the cow case agree to 1.4–1.6% (relative L2) over the first 1,000 steps.
More stable close to τ = ½: for the sphere at Re 500 with TRT (τ = 0.524) FluidX3D became unstable while QuanFlow stayed stable. In our channel set-up waLBerla 7 diverged for the sphere at Re ≥ 500.
Moving bodies checked against exact solutions: torques and forces within 0.0–1.8% of analytical values (Taylor–Couette, rotating Stokes sphere, translating plate). Momentum balance over a control volume agrees to 0.00%.
Mass conservation: drift of 1.5×10⁻⁵ after 1,200 steps for a rotating box, where FluidX3D drifts 2.7×10⁻⁴ in the same test (about 18× more).
Compared with experiments and published benchmarks: lid-driven cavity, backward-facing step, cube wake, cylinders, sphere, dam break. See the Validation page, where each case states whether it is compared with an experiment, an exact solution or a published benchmark.

Stated limits: forces on complex curved geometry depend on the staircase wall treatment (the Schäfer–Turek cylinder fails its thresholds for lift and pressure difference); the wall function is not yet validated on the Ahmed body, so it is not used for client work; the multi-GPU build today serves grids larger than one card's memory, not higher speed.

How we measured

Test conditions, so you can repeat them.

Hardware

NVIDIA RTX 5070 Ti 16 GB (measured copy bandwidth 753 GB/s, data sheet 896 GB/s) and RTX 3060 12 GB (measured 328 GB/s, data sheet 360 GB/s). The GPU was idle during measurements; two processes on one GPU halve the throughput.

Software

QuanFlow (CUDA), FluidX3D (OpenCL, only the set-up file and compile options changed, graphics off for complete runs), OpenLB 1.9 (GPU backend), waLBerla 7 (7-stable branch, lbmpy-generated D3Q19 in-place kernel). Same grid, same collision model (BGK/SRT or TRT, and Smagorinsky 0.17326).

Method

MLUPs/s = nodes × steps / time, counting solid nodes. QuanFlow: median of five runs of 200 steps after warm-up. FluidX3D: its own reported peak (which favours FluidX3D). Complete runs: external clock from process start to exit. Measured October 2026.

Comparisons across different GPUs in the literature are indicative only; every claim on this page rests on same-device measurements. Full details are in our manuscript; contact us for a copy or the raw data.

Quick answers

Common questions about speed.

Which GPU lattice Boltzmann solver is fastest on a single GPU?

On the same RTX 5070 Ti, QuanFlow reaches 99.8% of the measured memory bandwidth. On static bodies it equals FluidX3D (both sit at the bandwidth limit). On moving bodies it is 20–29% faster than FluidX3D, 30% faster than OpenLB and 43% faster than waLBerla.

How much faster is QuanFlow than FluidX3D?

2–6% in the 256³ box benchmark, equal on static bodies, 20% on the 219.7-million-node rotating propeller (9,376 vs 7,784 MLUPs/s) and 29% in FP16S on the TU Delft propeller (8,461 vs 6,574).

Is the comparison with OpenLB and waLBerla fair?

Same card, same grid, same collision model. For moving bodies each code uses its own mechanism (OpenLB: HLBM; waLBerla: CPU-side voxelisation because it has no GPU boundary for arbitrary moving surfaces), and this is stated. We have not yet separated OpenLB's kernel time from its overhead in the sphere case.

Does QuanFlow also compute forces?

Yes. QuanFlow accumulates force and torque by momentum exchange every step, and the speeds above include it. In the TU Delft propeller comparison the other codes compute no forces, which favours them.

Can I hire QuanFlow to run my case?

Yes, that is our main service. Send a short description and get a free feasibility review within 24 hours.

Same GPU, same grid, four solvers: QuanFlow is fastest on moving geometry.