Uploaded September 2022 | Updated September 2026, 2 weeks ago
FluidX3D source code: github.com/ProjectPhysX/FluidX3D
This is a 1 billion grid cell simulation of a d = 7 mm diameter terminal velocity (9.55 m/s) raindrop impact at 20° inclination, simulated for 3 milliseconds (17355 LBM time steps). The box is 5d x 5d x 4.25d and the pool height is 2d. For reproducibility: The dimensionless numbers for this setup are Re = 63618, We = 8864, Fr = 36.44, Ca = 0.1393, Bo = 6.674.
Velocity, density and fluid mass are solved at 1 billion lattice points (1060 x 1060 x 900) with D3Q19 SRT and FP16S memory compression. The simulation requires 64 GB video memory and was conducted on an AMD Instinct MI200 GPU at Jülich Supercomputing Centre (JSC) JURECA-DC-MI200. Compute time alone was 61 minutes, plus 64 minutes rendering time (raytracing at 4K60 resolution with 1-10 rays per pixel; 4x 446 frames (11.8GB) generated).
Find physical accuracy validation of the raindrop setup in this paper: doi.org/10.1186/s43591-021-00018-8
How is it possible to squeeze 1 billion grid points in only 64GB VRAM?
I'm using two techniques here, which together form the holy grail of lattice Boltzmann, cutting memory demand down to only 67 Bytes/node for D3Q19 LBM with the Volume-of-Fluid extension, or 1/3 of conventional codes:
1. In-place streaming with Esoteric-Pull. This almost cuts memory demand in half and slightly increases performance due to implicit bounce-back boundaries.
Paper: doi.org/10.3390/computation10060092
2. Decoupled arithmetic precision (FP32) and memory precision (FP16): all arithmetic is done in FP32, but LBM density distribution functions in memory are compressed to FP16. This almost cuts memory demand in half and almost doubles performance, without impacting overall accuracy for most setups.
Paper: researchgate.net/publication/362275548_Accuracy_and_performance_of_the_lattice_Boltzmann_method_with_64-bit_32-bit_and_customized_16-bit_number_formats
Graphics are done directly in FluidX3D with OpenCL, with the raw simulation data already residing in ultra-fast video memory. No volumetric data ever has to be copied to the CPU or hard drive, but only rendered frames instead. Once on the CPU side, a copy of the frame is made in memory and a thread is detached to handle the slow .png compression, all while the simulation is already continuing. At any time, about 16 frames are compressed in parallel on 16 CPU cores, while the simulation is running on GPU.
Paper: researchgate.net/publication/360501260_Combined_scientific_CFD_simulation_and_interactive_raytracing_with_OpenCL
Timestamps:
0:00 front view
0:07 side view
0:15 back view
0:22 top view
#CFD #GPU #FluidX3D #OpenCL
FluidX3D source code: github.com/ProjectPhysX/FluidX3D
This is a 1 billion grid cell simulation of a d = 7 mm diameter terminal velocity (9.55 m/s) raindrop impact at 20° inclination, simulated for 3 milliseconds (17355 LBM time steps). The box is 5d x 5d x 4.25d and the pool height is 2d. For reproducibility: The dimensionless numbers for this setup are Re = 63618, We = 8864, Fr = 36.44, Ca = 0.1393, Bo = 6.674.
Velocity, density and fluid mass are solved at 1 billion lattice points (1060 x 1060 x 900) with D3Q19 SRT and FP16S memory compression. The simulation requires 64 GB video memory and was conducted on an AMD Instinct MI200 GPU at Jülich Supercomputing Centre (JSC) JURECA-DC-MI200. Compute time alone was 61 minutes, plus 64 minutes rendering time (raytracing at 4K60 resolution with 1-10 rays per pixel; 4x 446 frames (11.8GB) generated).
Find physical accuracy validation of the raindrop setup in this paper: doi.org/10.1186/s43591-021-00018-8
How is it possible to squeeze 1 billion grid points in only 64GB VRAM?
I'm using two techniques here, which together form the holy grail of lattice Boltzmann, cutting memory demand down to only 67 Bytes/node for D3Q19 LBM with the Volume-of-Fluid extension, or 1/3 of conventional codes:
1. In-place streaming with Esoteric-Pull. This almost cuts memory demand in half and slightly increases performance due to implicit bounce-back boundaries.
Paper: doi.org/10.3390/computation10060092
2. Decoupled arithmetic precision (FP32) and memory precision (FP16): all arithmetic is done in FP32, but LBM density distribution functions in memory are compressed to FP16. This almost cuts memory demand in half and almost doubles performance, without impacting overall accuracy for most setups.
Paper: researchgate.net/publication/362275548_Accuracy_and_performance_of_the_lattice_Boltzmann_method_with_64-bit_32-bit_and_customized_16-bit_number_formats
Graphics are done directly in FluidX3D with OpenCL, with the raw simulation data already residing in ultra-fast video memory. No volumetric data ever has to be copied to the CPU or hard drive, but only rendered frames instead. Once on the CPU side, a copy of the frame is made in memory and a thread is detached to handle the slow .png compression, all while the simulation is already continuing. At any time, about 16 frames are compressed in parallel on 16 CPU cores, while the simulation is running on GPU.
Paper: researchgate.net/publication/360501260_Combined_scientific_CFD_simulation_and_interactive_raytracing_with_OpenCL
Timestamps:
0:00 front view
0:07 side view
0:15 back view
0:22 top view
#CFD #GPU #FluidX3D #OpenCL
![FluidX3D [FLUID SIMULATION] Real Time Prototype Demo](https://i.ytimg.com/vi/Vv-ZoJudJq0/mqdefault.jpg "FluidX3D [FLUID SIMULATION] Real Time Prototype Demo
Simulating a liquid is usually reserved for supercomputers. However, in the last few years, the amount of calculating power provided by consumer graphics cards skyrocketed to the point where well optimized code today can result in a successful real time simulation. As a rule of thumb, one GPU is about as fast as 100 multi-core CPUs for well parallelizable code.
This is an optimized OpenCL implementation of the barebones Lattice Boltzmann Method (LBM) in its simplest 3D form with the D3Q15 velocity set, optimized to run parallelized on the GPU.
All the shown demos run in real time on an old laptop GPU (GTX 960M with 640 CUDA cores @1200MHz).
The blue curves represent integrated streamlines through the velocity field, which itself is updated by the GPU approximately 50 times per second.
The maximum lattice size is limited by the amount of VRAM to 256x256x256, at which the program fills 2.6GB of graphics memory.
For more information about FluidX3D and my other projects, visit
http://www.projectphysx.de
Music: Death & Rebirth - Lotus Eater")
![PhysX3D [GRAVITY SIMULATION] Galaxy fly-through + Blooming Effekt demo](https://i.ytimg.com/vi/WbbjvGIfqdc/mqdefault.jpg "PhysX3D [GRAVITY SIMULATION] Galaxy fly-through + Blooming Effekt demo
Recently I have improved the blooming effect in terms of performance by about two magnutudes.
Blooming is a rendering effect which makes the otherwise black space between close pixels brighter. It is a post-processing effect, meaning the completely rendered frame is being edited as an image right before being drawn on the screen.
The improvement that I implemented was instead of going through the frame pixel by pixel and checking the surrounding of each pixel, at first to scan the frame for all non-black pixels and to save their positions, so the algorithm only has to iterate through the amount of drawn pixels instead of the whole frame.
More information at: http://www.projectphysx.de
Music: Puddle of Infinity - Open Sea Morning")
![Line3D [GRAPHICS ENGINE] Dynamische Beleuchtung](https://i.ytimg.com/vi/_9i8RSxTkjA/mqdefault.jpg "Line3D [GRAPHICS ENGINE] Dynamische Beleuchtung
Ich hab noch ein bisschen an der Java-Grafikausgabe aus meinem Projekt PhysX3D weiter geschrieben. Aus einfachen Linien sind Polygone geworden, die dynamisch von einer (oder auch mehreren) frei beweglichen Lichtquellen beleuchtet werden. In diesem Beispiel berechnet die CPU auf einem Kern 25.600 Dreiecke pro Frame, und das etwa 30 Mal in der Sekunde.
Ich verwende dazu nur die elementarsten Java-Bibliotheken wie das JFrame, ein Fenster, in dem ich Linien, Text und Vielecke zeichnen kann.
Wie funktioniert die Berechnung?
Für jedes Dreieck wird der Normalenvektor berechnet. Das ist sozusagen eine Linie, die immer senkrecht auf der Fläche des Dreiecks steht. Dann wird der Normalenvektor skalar mit dem Vektor vom Mittelpunkt des Dreiecks zur Lichtquelle multipliziert. Einfach ausgedrückt vergleicht man dabei, ob der Normalenvektor zur Lichtquelle zeigt. Wenn er das tut, ist die Fläche heller, sonst dunkler. Mit dem Ergebnis der skalaren Multiplikation wird die Helligkeit des Dreiecks skaliert.
Die Lichtquelle muss nicht immer am selben Punkt sein, sie kann sich auch bewegen, wie hier im Video demonstriert.
Was ist der praktische Nutzen davon?
Das Prinzip der dynamischen Beleuchtung ist heutzutage in jedem Computerspiel und in jeder Rendering-Software zu finden, bloß werden dort die Dreiecke noch viel kleiner gemacht, damit zum Beispiel ein animiertes Gesicht nicht eckig aussieht.")
