Code usage

Configuration files

Simulation parameters are controlled by JSON configuration files.

Basic usage

The files have an \(.ini\) suffix and a simple structure of \(parameter: value\). When fed into the drivers, Runko will automatically parse the file and construct a \(Configuration\) object, typically called \(conf\). Any parameter in the configuration file gets turned into \(conf.parameter\) with a value of \(value\); this makes it easy to add any new user-defined parameters to the driver scripts.

During the construction of \(conf\) the configuratoin file is also typically passed through a problem-spesific \(init_problem.py\) file that introduces a specialiced \(Configuration_Problem\) derived from the base class. It can do additional manipulation on the configuration file parameters before resulting in a \(conf\) object.

Typical parameters

Typical default parameters found in configuration files include:

  • [io]: basics

    • \(outdir\): simulation output directory name (e.g., \(run_1\))

    • \(laprestart\): Simulation lap to restart from (\(-1\) = no restart, \(0\) = automatic, \(X\) lap to restart; \(0\) is default)

    • \(restart\): No. of steps between restart files written; these restart files are cycled and overwritten during the simulation to save disk space.

  • [io]: analysis

    • \(interval\): No. of steps between analysis output files written

    • \(stride\): thinning factor for analysis grids; results in saving only every \(st\):th grid point in each dimension (typically either \(1\) for complete data snapshots or tile length for maximum compression)

    • \(stride\): thinning factor for analysis grids; results in saving only every \(st\):th grid point in each dimension (typically either \(1\) for complete data snapshots or tile length for maximum compression)

  • [io]: deep io

    • \(full_interval\): No. of steps between writing of full output files (these act as full restart files but are not overwritten; typically \(-1\) to save disk space)

  • [io]: shock io (optional and relevant only for shock simulations)

    • \(box_nx\): length of a special grid that tracks the shock front during a simulation

    • \(box_stride\): similar thinning factor as \(stride\) but for the special shock grid

    • \(box_shift\): displacement of the box from the (automatically-located) shock front (use a value of \(-box_nx/2\) to center the grid on the shock front; \(0\) to track upstream).

  • [simulation]: MPI control parameters (optional)
    • \(mpi_track\): instead of partitioning the domain equally between processors we can optionally make a “caterpillar`-like track (along x-dimension) where tiles owned by different MPI ranks repeat themselves cyclically. This parameter controls the length of the track in units of tiles. A value of \(128\) would partition the tiles inside a sub-domain of \(128 x Ny x Nz\) equally between all the processors. The pattern is repeated for the length of the domain in x-direction.

      • make sure there are reasonable number of tiles in one cycle per processor. Each rank has \(mpi_track x Ny x Nz/Nprocs\) continuous tiles in the subdomain, multiplied by the number of cycles, \(Nx/mpi_track\). - The parameter can be tuned to roughly equal the active zone in a shock simulation. This way the simulation is always distributed among approximiately the same number of ranks. Physical length of the track is \(mpi_track * NxMesh/c_omp\).