"Wow, it's just like the real cosmological codes!" - Somebody hopefully, (2024)

Starflood is an open-source SPH and N-body code(s) written in C/C++.

• 2D (New!) 3D O(N*log(N))-complexity tree gravity solver using the Barnes-Hut algorithm!
• 2D (New!) 3D hydrodynamics with Smoothed-particle hydrodynamics (SPH)!
• Reasonably performant low-level C/C++ code with high-level parallelism via OpenMP!
• Simultaneous Simulation AND Rendering!
• Profiling using omp_get_wtime for double-precision timing (a little less granularity than a nanosecond after 6 months uptime)!

• Combine all sources into one clean, configurable, unified SPH/N-body code
• Optimize SPH neighbor search (better than O(N²))
• Multipole Barnes-Hut or Fast-Multipole Method (FMM)
• Ability to save/load simulation data and render it afterwards
• Ability to load pre-generated initial conditions
• Heterogenous Compute Offloading (development is currently made difficult due to a lack of compiler packages with build support on Arch Linux, and NVIDIA's HPC SDK requires AVX so that's out of the question...) I now have access to an Intel Core i7-3770K, which has AVX (something which NVIDIA's HPC SDK unfortunately requires)
• Volumetric-ally rendering SPH particles for eye candy visualization
• A more standardized build system such as CMake
• Distributed computing (Using Open MPI or something)

• Philip Mocz's Python SPH Guide
  • https://github.com/pmocz/sph-python
  • Used as a reference for the SPH algorithm, although the numpy syntax was a little hard to decipher...
• stb Headers
  • https://github.com/nothings/stb
  • stb_image.h and stb_image_write.h headers for image read/write
• Jeffrey Heer's article The Barnes-Hut Approximation: Efficient computation of N-body forces
  • https://jheer.github.io/barnes-hut/

Starflood doesn't currently have a method of installation. It's up to the user to manually choose where they want the Starflood repository and build it.

First, change directories to a place you like to keep your repositories. For example, I like to keep mine in ~/source.

cd <directory you want the starflood repo in>

Next, clone the Starflood repository.

git clone https://github.com/Zi7ar21/starflood.git

Next, change directories to the newly-cloned repo.

cd starflood

Starflood is still in its infancy. As such, configuration is achieved by modifying source code. Don't be scared, I try to keep the parameters as #defines near the top of the source files (check src/common.h).

Starflood uses a custom shell script for compilation. While I am flattered if you trust me, I encourage you to never run shell scripts without at least inspecting them first.

In the root of the repository there is a shell script test.sh, which will automatically build Starflood, clean a previous render (if one exists), and render the resulting frames with ffmpeg. However, you can execute each of these steps individually if you so wish. build.sh builds starflood with g++, and encode.sh renders it as a .mp4.

Starflood renders timesteps and saves the frames to the disk, before they get rendered by ffmpeg as a video file. You can mount a tmpfs to out either by using the temp.sh script,

./temp.sh

or by just running mount directly (2g means 2 GiB of storage):

sudo mount -t tmpfs -o size=2g tmpfs out

This will make running Starflood faster as it doesn't have to wait for images to be written to a disk. My condolences if your sysadmin does not let you mount tmpfss. I plan on adding the ability to defer writing images, or writing them in a separate thread, but this hasn't been implemented yet.

The compiled binary which should be located in <path to starflood>/build. If you aren't using test.sh, you can run the binary from the root of the repo. For example, if you are in the repo directory on Linux you can just run:

./build/starflood.out