FAQ

What is Fluids v.3?

Fluids v.3 is a large scale, open source fluid simulator using the Smooth Particle Hydrodynamics method. It is at least 8x faster than Fluids v.2, and allows up to 8,000,000 particles on GPUs with 1500 GB ram.

What are Fluids v.3 system requirements?

Minimum system requirements are a CUDA-capable NVIDIA GPU with Compute capability 2.1 or higher, and OpenGL support.

How does Fluids v.3 compare to others?

See the Performance page for some details. Fluids v.3 is the only free, SPH simulator I know for the GPU that handles over 1,000,000 particles. NVIDIA PhysX is currently limited to 700,000 particles (as of Dec 2012).

Can I use Fluids in my field of study?

Yes. Fluids v.3 is intended for cross-disciplinary research, to be adopted in other fields. Previous interest has come from students and professionals in cosmology, hydrology, geophysics, and medicine. Fluids remains open source to allow others to adopt this basic algorithm to their particular application.

What are the Fluids licensing terms?

Fluids v.3 uses an modified ZLib license. Please note the additional clause below regarding attribution as compared to the standard ZLib.

The full text of the license is given here, and present in source files:

FLUIDS v.3 – SPH Fluid Simulator for CPU and GPU
Copyright (C) 2012-2013. Rama Hoetzlein, http://fluids3.com

Attribute-ZLib license (* See additional part 4)

This software is provided ‘as-is’, without any express or implied
warranty. In no event will the authors be held liable for any damages arising from the use of this software.

Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software.

2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.

3. This notice may not be removed or altered from any source distribution.

4. Any published work based on this code must include public acknowledgement of the origin. This includes the following when applicable:
– Journal/Paper publications. Credited by reference as a citation or in the acknowledgements.
– Public presentations. Credited in at least one slide.
– Distributed Games/Apps. Credited as a single line in game or app credit page.
Retaining this additional license term is required in derivative works.

You may use the following for citations:
In publications:
2014, Hoetzlein, Rama Karl. Fast Fixed-Radius Nearest Neighbors: Interactive Million-Particle Fluids. GPU Technology Conference, 2014. San Jose, CA. 2010-2014. Online at http://fluids3.com
App or game credits:
GPU Accelerated Fluids, Rama Karl Hoetzlein, Fluids v3

Clause #1 of ZLib indicates that “you must not claim that you wrote the original software”. However, it is unfortunately common that this attribution is hidden in source code. Clause #4 makes public acknowledgement explicit, and carries this forward to derivative works.

How is Fluids v.3 different from Fluids v.2?

Many of the feature differences are listed on the Main Page.
One of the key features in Fluids v.3, aside from performance gains, is that it relies on XML files to describe scenes. This allows you to modify the scene setup without rebuilding the Fluids code.

What algorithms does Fluids v.3 use?

Fluids v.3 uses efficient CPU and GPU techniques, but focuses primiarily on the neighbor-search problem. Methods more specific to fluids can be found in PCISPH and Position-Based Fluids (Macklin & Muller).

The method here uses Counting Sort to achieve very fast parallel neighbor search. This technique was presented at the GPU Technology Conference (GTC) in 2014, as “Fast Fixed-Radius Nearest Neighbors: Interactive-Million Particle Fluids”.
This technique is applicable to any problem that requires efficient parallel nearest neighbor search (not just fluids).

While running Fluids v.3, you can use the F and G keys to change the algorithm used. This will cycle through the following available algorithms:
– CPU Grid – CPU only, also reports grid statistics
– CUDA Radix Sort – Not currently implemented in v.3 (used in Fluids v.2)
– CUDA Index Sort – New method, but without deep copy (slightly slower)
– CUDA Full Sort – Most recent, Fast method (Default when started)
– CUDA Clustering – Shared memory solution, Not worked as expected (see Wishlist)

Does Fluids v.3 create rendered surfaces, or interact with rigid bodies?

At present, no. These features are on the wishlist in the Development section. I have focused my efforts on making the fastest, large scale simulator available. I encourage others to pursue surface rendering and rigid interactions, but I won’t be able to add these myself due to other commitments.

I thought GPUs had memory limits for large numbers of particles?

Fluids v.3 uses a new algorithm that reduces memory requirements. Strictly speaking, this was never a real limitation. A particle typically takes 72 bytes of memory, which implies that a GPU with 1.5 GB should handle up to 20 million particles. In practice, algorithm overhead places the real limit around 10 million with 1.5 GB GPU ram. Fluids v.3 also handles memory much more carefully to avoid GPU crashes with large numbers of particles, and is thus code-stable for large simulations.

12 Responses to "FAQ"

Ishaan says:

April 10, 2013 at 2:47 pm

Hi,
I’ve been working on extending this project to interact with rigid bodies based on a recent SIGGRAPH paper and was wondering if I could ask the author some questions.
I’ve had to modify the struct Fluid and have added another buffer in the Fluid System corresponding to the same.
This addition is essentially an index to the rigid body that a particle belongs to.
Since the comment in the Fluid struct says its size should be a multiple of 12, so I’ve added a Vector3DF instead of simply an int to make the size 84 instead of 72. Is there any other place I need to make changes to ensure full compatibility for the CPU and GPU versions?
I’m not sure what the “m_Param[PSTAT_PMEM] = 68 * 2 * cnt;” at the end of allocate particles refers to. Should I be changing the 68 to 80?
Thanks!

Reply
admin says:

April 11, 2013 at 6:59 am

Great. Yes, there are a few things you need to look out for. In the CUDA kernels, many accesses to the fluid particles are done using fixed width multipliers and offsets into structs of 72 bytes for the sake of efficiency. See the defines BUF_GCELL, BUF_VEL, BUF_VELEVAL used in fuild_system_kern.cu for example, which are defined in fluid_system_kern.cuh as having specific offsets. You need to make sure these are correct for your new structure. Check the CPU code for similar fixed width performance tricks. Since you’re adding to the end it should be pretty straightforward. Just keep in mind that the kernel does a deep copy of particles for cache coherence, and you need your new data copied too. Let me know how it goes. Best, R

Reply
Hong ZHANG says:

November 10, 2013 at 6:09 am

Hi，
I’ve been working on extending this project to interact with rigid bodies which need index of particles surrounding the rigid bodies. And I found a problem that the particles’ ID changes when they are thransferred from CUDA, which means the identical particle may “jump” from one position to another. This problem, however, does not exist in CPU version.
The algorithm to search the neighboring particles interacted with the rigid bodies need unchanged particle ID. So, I am wondering if I could ask the author how to lidentify the particle index as they are transferred to CPU.
Thanks!

Reply
1. admin says:
  
  November 14, 2013 at 2:38 am
  
  Yes, for efficient computing the GPU particles are sorted each frame. If you need to know the original particle ID, this would have to be included in the data transmitted from CPU to GPU. Then, during the sort phase the ID would be sorted as well. As the particles are shifted around in GPU memory, the unique ID is kept with the data, which you could use for rigid bodies.. Currently Fluids v.3 does not do this, so it would have to be added.
  
  Reply
Pavel Kudinov says:

June 2, 2014 at 9:05 am

Hello!

I have found that if you take the standard nvidia cuda sdk sample “particles” by Simon Green, which using fast radix sort, set the number of particles = 512K, set the grid cell count = 128x128x128 and disable bounding cube – it’s reached the simulation speed of 80 FPS (on GTX Titan), while your simulation fluids_v3 gives only 40 FPS on the same number of particles.

As I understand, your algorithm, on your benchmark, was faster than algortm of Simon Green – but I see the opposite.

I want to believe that there is a more quick solution for accelerating grid construction than fast radix sort, because my simulation is highly dependent on finding the best solutions to this problem (at the moment I’m using a modified version of the Simon Green’s algorithm)

Anyway, if you are had developed an algorithm faster than cuda sample “particles”, it would be good to make it visible on the actual launch of two executables with the same number of particles on the same hardware.

I think it would help to establish the truth about the real performance difference of two solutions.

I look forward to comments, thank you!

Reply
1. Rama Hoetzlein says:
  
  June 2, 2014 at 10:05 pm
  
  Pavel,
  Hi. The reason Cuda Particles runs faster is that it does not compute full SPH, it is just doing spring collisions. This is why you don’t see crashing waves or turbulence in Cuda particles. Spring collisions only require 1x NNS search loop. Fluids v.3 is doing 2x NNS search loops, one for pressure, another for forces. The full fluid calculations for SPH thus take 2x NNS. I have even attempted storing the neighbor tables from the first loop to be reused by the second, but in fact this consumes huge amounts of memory, and the newer Counting sort-based NNS is fast enough to not warrant the additional memory read/writes.
  
  Thus, a direct comparison would only look at the NNS portion of Cuda Particles vs. Fluids. As you mention, it would be good to have Fluids launch a RadixSort as well for a more direct comparison. I even have a placeholder in Fluids v3 where I had intended to do this (RunCudaRadiXSort), but just haven’t had the time to get around to implementing it. I really should, its a good suggestion. If you’d like to learn more about the Counting Sort (1-radix) method, you can find details from my GTC presentation via on-demand here: http://on-demand.gputechconf.com/gtc/2014/presentations/S4117-fast-fixed-radius-nearest-neighbor-gpu.pdf
  
  Reply
  1. Pavel Kudinov says:
    
    June 3, 2014 at 6:49 am
    
    Thanks for your reply!
    
    Now I will try to replace Fast Radix Sort by Counting Sort in my simulation, and report the results.
    
    I needed a faster algorithm NNS for my 2D soft body simulation, designed to simulate a large mass of the virtual biological organisms.
    
    Thanks for the PDF, that is what I found initially, and was very glad that you not only describe a new algorithm NNS, but also implemented it as an open source project.
    
    Reply
Ryan says:

July 18, 2014 at 5:45 pm

While I’m working on getting this to compile on Linux, I also wanted to try it out on Windows 7. However, when I run the executable, I’m warned that the program can’t start because cudart32_50_35.dll is missing from my computer. I noticed the download contained cudart32_42_9.dll, and the CUDA toolkit download installed cudart32_60.dll. Is there an easy way to point the program to one of these? Or is it obvious I’m doing something else wrong?

Thank you.

Reply
1. Rama Hoetzlein says:
  
  July 19, 2014 at 12:43 am
  
  If you’re recompiling with a different CUDA toolkit, you will need the dll that goes with the version you have. If you’re just rebuilding the download, without compile, then use the one that comes with it. Basically, the dll provided has to match the compile. You cannot override this requirement. The dll must match the cuda compile. CUDA will check the same directory as the exe first, so you can provide it by simply dropping the correct .dll in same folder as exe.
  
  Reply
Ryan says:

August 15, 2014 at 6:54 pm

Has anyone successfully compiled on a 64-bit laptop? I actually got it working when I put a downloaded copy of cudart32_50_35.dll to the working directory. However, I’d like to recompile it, and I don’t have a lot of experience with VS. I downloaded VS 2012 and 2013 Express. I think I changed some of the links appropriate, however, I’m getting errors that in app_util.cpp, not1 and ptr_fun are members of std. I’ve unsuccessfully tried a fix from Microsoft, so I’m hoping someone has experienced and overcome similar problems. Thanks.

Reply
Ehsan Izadi says:

October 9, 2014 at 9:35 am

I am running Ubuntu 14.04 (64 bit) and have cuda installed.
Is it poossible to make use of Fluids v.3 on linux?
If so, where can I find the instructions?
And I really appreciate if someone privide a tutorial file or something that I can understand how to work with that.

Thanks in advance

Reply
1. Rama Hoetzlein says:
  
  October 10, 2014 at 5:49 pm
  
  Others have done a port to Linux, which can be found here, by Serge Martin:
  https://github.com/sergemartin/fluids_v3
  Please note, as indicated in my comments, I am working on other projects so I no longer have time to develop or support Fluids v.3. You are welcome to use the source code, and talk to others here who have tried this.
  
  Reply