Overall, we were very happy with how this project turned out. We created a functioning fluild-mechanics simulator that is quite fast, works to a Reynold's number of about 10,000, and wrote it in such a way that it will be easy to create extensions in the future. It was very satisfying to see realistic the fluid flow around strange (CS-205 shaped) obstacles. We made a good team and both have plans to develop this software further in the future.
Some parts of the project were frustrating, however. The majority of our time was spent troubleshooting boundary conditions and trying to understand the Lattice Boltzmann method as opposed to optimizing or writing code. Perhaps this is what one should expect when writing a physics simulation; it is tough to get the physics correct!
We also wish that we had more time to create fields that were advected with the flow and to visualize our simulations with OpenGL (what we had originally hoped to accomplish). You can see other things we would like to do in the future below.
We discussed what pieces of our OpenCL code we must improve in the Performance and Optimization page. We believe that it will be straightforwards to obtain a 10% performance increase with our code; improvements beyond 10% will likely be challenging to obtain.
In addition to what was written in the Performance and Optimization page, we are especially interested in figuring out if it is possible to write the move kernel so it moves f in-place as opposed to copying it to another buffer. This could potentially speed up our code beyond the 10% mark mentioned previously.
We may also try to port our code into CUDA at some point. We believe that we could obtain significant performance increases at the cost of decreased flexibility.
As discussed in the Simulation Verification page, the boundary conditions that we use to enforce zero-velocity at the walls are only accurate to the first order. It should be straightforward to implement boundary conditions that are accurate to second order. However, by applying the more accurate boundary conditions, we may slow down our simulation.
The rate-limiting step in our simulation is actually visualizing the fields extracted from the GPU with the CPU. It takes a lot of time to transfer the data from the GPU to the CPU and even more time to visualize the data. It would be better if we could do the visualization on the GPU itself with OpenGL. This was another goal of our project, which we hope to implement in the near future.
It is easy to implement additional equations of motion for particles or populations that are advected by the flow. We would like to create a simulation that combines our fluid flow simulations with passive fields that stochastically grow and decay. We wanted to include this in our project but ran out of time.
Please find the current issues with the code in the link below. We are continuously working to improve the code.