Configuring simulations

This chapter teaches you how to describe a complete simulation to Nassu using a single configuration file.

Everything you do with Nassu starts here: instead of writing code or scripts, you write a .yaml file that declares what to simulate. This is the no-code philosophy in practice. It has three practical benefits:

• Simplicity: you describe the simulation, not how to run it. No programming required.

• Portability: a configuration is a single text file you can send over the internet, for example to a remote GPU server, and run as-is.

• Reproducibility: the file is the case. Anyone with the same file gets the same simulation.

The mental model of a configuration file

A Nassu configuration declares a list of simulations, where each simulation is described by a handful of major blocks. Once you know what these blocks are for, every configuration file becomes easy to read:

• Domain: the simulated volume, the solid bodies inside it, and where the grid is refined. This is where the flow happens and what it flows around.

• Data: what the solver exports and when (instantaneous fields, statistics, probes, checkpoints). This is what you get back.

• Models: the numerical methods and their parameters (LBM collision operator, LES, IBM, boundary conditions, initialization, GPU precision). This is how the flow is solved.

A minimal file is just a simulations list; the richer features (inheritance, variables, custom tags) are conveniences layered on top to keep large configurations clean.

How to read this chapter

Start with the Configuration File page to learn the overall structure and the file-level mechanics (parent simulations, variable substitution, custom tags). From there, the topic pages below go deep on each major block and on the cross-cutting concerns that deserve their own treatment.