Skip to content

Input File Overview

GUERNICA is configured through a single INI-style input file. This file is the main user interface to the code: it tells GUERNICA what problem to solve, which physics to include, how to initialize the state, and how to run the simulation.

All GUERNICA input files use the .cfg extension and are stored in the configs/ directory.

The goal of this page is to explain the structure of the input file at a practical level. For the full list of supported fields, defaults, and allowed values, see the Inputs Reference.

Big picture

A GUERNICA input file usually answers the following questions:

  • How long should the simulation run?
    Controlled by [time].

  • What spatial mesh and DG order should be used?
    Controlled by [grid].

  • What velocity grid should be used?
    Controlled by [vx], [vy], and [vz].

  • What backend should run the code?
    Controlled by [device].

  • What output should be written?
    Controlled by [output].

  • What species, operators, and boundaries are active?
    Controlled by [components].

  • How are the species initialized?
    Controlled by sections like [e:init], [i:init], and [n:init].

  • How do density, temperature, and velocity vary in space?
    Controlled by named profile sections like [profile:electron_density].

  • Are there sources, wall interactions, ionization, charge exchange, or neutral-neutral collisions?
    Controlled by sections such as [source], [boundary:wall], [ionization], [charge_exchange], and [neutral_neutral].

How to think about the input file

The input file can be separated it into four layers:

1. Global run controls

These sections set up the simulation itself:

  • [time]
  • [grid]
  • [vx], [vy], [vz]
  • [device]
  • [output]

These do not describe the plasma or neutral physics directly. They describe how GUERNICA should run.

2. What physics is active

The [components] section tells GUERNICA what is included in the run:

  • which species exist
  • which operators are enabled
  • which boundaries are active

This section acts like a high-level switchboard for the rest of the file.

3. Initial and boundary data

Sections like

  • [e:init]
  • [i:init]
  • [n:init]
  • [source]
  • [boundary:<name>]

describe what distributions or wall/source data should be used.

4. Reusable spatial profiles

Sections like

ini [profile:electron_density] type = constant value = 5.0

define reusable spatial data.

A profile might represent:

  • density
  • temperature
  • bulk velocity
  • wall accommodation data
  • source strength

Other sections refer to these profiles by name.

What this page does not cover

This page explains the overall structure of the input file, not every supported field.

For more detail, use the other pages: