Uploaded August 2022 | Updated September 2026, 1 week ago
Live long and prosper! 🖖😎
This is a quick 220 million voxel FluidX3D CFD simulation of the Star Trek USS Enterprise NCC-1701-E. OpenCL simulation+rendering took 15 minutes on my 2017 gaming PC with 12GB Titan Xp GPU.
Grid resolution is 528×1584×264 and 18000 time steps are computed with a video frame every 30 steps. Shown is the Q-criterion isosurfaces with marching-cubes. Reynolds number is 100k with Smagorinsky-Lilly subgrid model.
FluidX3D source code on GitHub: github.com/ProjectPhysX/FluidX3D
How is it possible to squeeze 220 million grid points in only 12GB?
I'm using two techniques here, which together form the holy grail of lattice Boltzmann, cutting memory demand down to only 55 Bytes/node for D3Q19 LBM, 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 (1 frame of the velocity field is 2.5GB!) ever has to be copied to the CPU or hard drive, but only rendered 1080p frames (8MB) 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.
Paper: researchgate.net/publication/360501260_Combined_scientific_CFD_simulation_and_interactive_raytracing_with_OpenCL
#CFD #GPU #FluidX3D #OpenCL
Live long and prosper! 🖖😎
This is a quick 220 million voxel FluidX3D CFD simulation of the Star Trek USS Enterprise NCC-1701-E. OpenCL simulation+rendering took 15 minutes on my 2017 gaming PC with 12GB Titan Xp GPU.
Grid resolution is 528×1584×264 and 18000 time steps are computed with a video frame every 30 steps. Shown is the Q-criterion isosurfaces with marching-cubes. Reynolds number is 100k with Smagorinsky-Lilly subgrid model.
FluidX3D source code on GitHub: github.com/ProjectPhysX/FluidX3D
How is it possible to squeeze 220 million grid points in only 12GB?
I'm using two techniques here, which together form the holy grail of lattice Boltzmann, cutting memory demand down to only 55 Bytes/node for D3Q19 LBM, 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 (1 frame of the velocity field is 2.5GB!) ever has to be copied to the CPU or hard drive, but only rendered 1080p frames (8MB) 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.
Paper: researchgate.net/publication/360501260_Combined_scientific_CFD_simulation_and_interactive_raytracing_with_OpenCL
#CFD #GPU #FluidX3D #OpenCL
![PhysX3D [GRAVITY SIMULATION] short galaxy demo](https://i.ytimg.com/vi/xgz18CcV0G8/mqdefault.jpg "PhysX3D [GRAVITY SIMULATION] short galaxy demo
n-Körper-Simulationen gibt es viele, doch die wenigsten berücksichtigen die Gezeitenreibung und die auf den ersten Blick unscheinbare Konstante c – die Lichtgeschwindigkeit. Dass bewegte Massen schwerer sind ist eine der einfachen Folgen, die sich mit etwa zehn Zeilen Quellcode bewältigen lässt. Aber c verursacht noch ein weiteres Problem, ein sehr viel schwierigeres, das man erst bei genauerem Hinsehen bemerkt: Nichts kann sich schneller als c ausbreiten, eben auch nicht die Gravitation selbst.
Mein Programm kann sowohl Sonnensysteme als auch Kollisionen von Sternhaufen und Galaxien mit mehreren tausend Körpern relativistisch berechnen. Je nach Prozessorleistung sind bei Desktopcomputern bis zu 15 Millionen Rechenschritte pro Sekunde möglich.
Es enthält zudem verschiedene zuschaltbare Module, mit denen man beispielsweise die Raumkrümmung visualisieren kann oder zusätzliche Informationen zu den Körpern wie Flugbahn, Geschwindigkeit oder Gruppierungen von Körpern anzeigen kann.
Hier zu sehen ist ein Demonstrationsprogramm einer Galaxie aus 3000 Partikeln.
Mehr Informationen auf: http://www.projectphysx.de")
