# Input files specification

## File format

JavaScript Object Notation (JSON) is an open–standard file format, that uses human readable text in form of attribute–value pairs and array data types, is used as an input for the solver. Graphical setting up of simulations may be implemented, but JSON format is intuitive enough to make as rapid changes as graphical interface could.

Data types used for parameters:

Name | Description | Example |
---|---|---|

integer | Simple non-decimal value. | `3` |

number | Any decimal or non-decimal value. | `1.234` |

string | Text stored in quotes. | `"this is a string"` |

list of numbers | List of any number of values. | `[3.2, 4, 566.3, 0.0]` |

list of strings | List of quoted texts. | `["qwe", "asd", "xcv"]` |

vector | List of 2 or 3 numbers. | `[2.0, 44.53, 0.0]` |

timeline of scalars | List of time–scalar pairs. | `[ [0, 2.0], [1.2, -1.0] ]` |

timeline of vectors | List of time–vector pairs. | `[ [0, [2.0, 2.3]], [1.2, [-1.0, 2.1]] ]` |

timeline of motion | List of time and 3 (tx,ty,rz for 2D) or 6 (tx,ty,tz,rx,ry,rz for 3D) scalars. | `[ [0, [0, 1.0, 0.33]], ... ]` or `[ [0, [0, 0.2, 0.3, 0.01, 0.0, 0.0]], ... ]` |

boolean | Value saying something is enabled or disabled. | `true` or `false` |

object | Something that contains multiple data information. | `"object_name": { data goes here }` |

**Note:** When a default value is available for some parameter, user does not need to specify the parameter, unless they want to override it.

**Note:** The document is a JSON object, i.e. it must start with curly brackets ’{’ and ’}’.

**Note:** The last element in any list or object must not have comma after its definition.

**Note:** For quick testing, you can simply disable some option/parameter by adding any prefix or suffix to it. For example, change `"parameter"`

to `"parameter__"`

or `"parameter_IGNORE"`

.

## General parameters

Global parameters of the simulation:

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“dimensions” | integer | 3 | `2` (for 2D simulations) or `3` (for 3D simulations). |

“precision” | string | `single` | Machine representation of numbers. `single` (for 32-bit precision) `double` (for 64-bit precision). |

“description” | string | Optional textual description of the simulation. | |

“name” | string | same as file name | The name of the simulation (by default same as the file name) dictates result names. Convenient for doing multiple simulations in different output folders. |

“device” | string | `best` | On which device to execute the simulation. `cpu` (to use CPU cores) `gpu` (to execute it on a GPU) `best` to execute on the best device found in the system. |

**Note:** The modern GPU can execute simulations > 20 times faster than the modern CPU. This holds for typical GPUs optimized for 32-bit precision operations (GTX, RTX, etc.). If the double precision is needed, GPUs like Tesla, A100, H100 will perform better.

**Note:** 32-bit precision is usually enough when fast approximated/engineering results are needed.

**Example:** JSON input file with some general parameters.

```
{
"description": "Sway sloshing experiment blah blah",
"dimensions": 3,
"precision": "single",
... other parameters go here ...
}
```

## Relaxation

Relaxation is tightly connected to the pressure parameters. It says how strong factors dictate the simulation convergence within the time step.

“relaxation”: {

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“space” | number | `0.5` | How strong to force divergence cleaning based on the points arrangement information. |

“walls” | number | `0.5` | How strong to adapt to no-slip boundary condition in a single time step, i.e. adapt fluid acceleration near wall to the wall movement. |

}

**Example:**

```
"relaxation": {
"space": 0.9,
"walls": 0.7
}
```

## Pressure

Smooth and accurate pressure field is obtained by solving a Poisson equation. The equation is transformed to a system of linear equations, which is solved by using an iterative solver.

“pressure”: {

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“solver” | string | `pbicgstab` | Type of the iterative solver:`bicgstab` non-preconditioned BiCGStab`pbicgstab` diagonally-preconditioned BiCGStab`qmrcgstab` non-preconditioned QMRCGStab`pqmrcgstab` diagonally-preconditioned QMRCGStab`cg` non-preconditioned CG`pcg` diagonally-preconditioned CG`jacobi` Jacobi solver |

“max_iterations” | integer | `150` | Maximum number of iterations for trying to reach error lower than specified. |

“max_error” | number | `1e-3` | Tolerance or maximum allowed relative error trying to be reached. |

“gradient_limiter” | number | `0.0` | How much to limit overshooting within strong pressure gradient-areas. It is usually a value between 0.0 and 2.0, where higher values may be used for violent pressure fields to achieve large time-steps. |

}

**Example:**

```
"pressure": {
"solver": "bicgstab",
"max_iterations": 300,
"max_error": 1e-4,
"gradient_limiter": 1.0
}
```

## Velocity

Velocity is calculated from the momentum equation. For convection-dominated flows, it may be calculated directly, by explicitly approximating the diffusion operator. For diffusion-dominated flows, the velocity field should be solved implicitly using an iterative solver.

“velocity”: {

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“solver” | string | `explicit` | Type of the solver:`explicit` for solving velocity explicitly`jacobi` implicit Jacobi solver |

“max_iterations” | integer | `100` | If using the implicit solver, maximum number of iterations trying to reach error lower than specified. |

“max_error” | number | `1e-4` | If using the implicit solver, maximum allowed relative error trying to be reached. |

}

**Example:**

```
"velocity": {
"solver": "jacobi",
"max_iterations": 300,
"max_error": 1e-4
}
```

## Resolution

This category specifies the spacing between nearest neighbours, and the interaction radius. Each point can be connected to only first ring of its neighbours (fast, less diffusive), but better stability may be achieved by enlarging the radius to reach second ring of its neighbours (slower, more diffusive).

“resolution”: {

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“spacing” | number | must be specified | The initial spacing between neighbouring points. This is analogous to the base cell size in mesh–based methods. |

“truncation” | number | `1.8` | Interaction radius in terms of “number of spacings” to reach neighbouring points. It should be a value between 1.3 and 2.5. |

}

**Note:** Currently the point cloud resolution is constant in space and time, adaptive refinement is work in progress.

**Example:**

```
"resolution": {
"spacing": 0.02,
"truncation": 1.9
}
```

## Reordering

Each time step points perform Lagrangian advection, i.e. they move along solved streamlines. It can lead to distortion of the point distribution, and therefore mass conservation errors (imagine a rotating disc where points move in the tangential direction and increase the volume of the disc). During the movement, points try to keep equidistant neighbours to optimally conserve mass at all times.

“reordering”: {

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“iterations” | integer | `4` | Number of iterations to converge to constant neighbour spacing. The number may be from `1` to `20` . |

“radius” | number | `1.5` | Interaction radius in terms of “number of spacings” for optimizing the point spacing. The value may be from `1.35` up to `1.80` . |

“compression” | number | `1.0` | Allowed relative compression compared to the initial neighbourhood. Smaller compression may lead to better, but more aggressive re-organization of points. |

}

## External acceleration

Here we use term gravity as *constant acceleration* imposed to whole fluid in the domain, at all times.

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“gravity” | vector | `[0, 0, 0]` | Constant external acceleration vector. |

The harmonic oscillator object is created as follows:

**Note:** Setting domain rotation through key-frames is work-in-progress.

## Time control

If the user likes to impose duration of the simulation and the time-stepping control from the input file, use the following options. Otherwise, the user can control the simulation using GUI and console parameters.

“time”: {

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“duration” | integer | Seconds how long the simulation will run for. | |

“step_size” | number | Fixed time step size. | |

“step_coef” | number | Adaptive time step size is decided by the solver and multiplied by this coefficient. |

}

## Domain

The domain is an axis-aligned bounding box (or AABB), defined by the starting and ending coordinates of its diagonal. It specifies the space where fluid flow is allowed. By default the domain automatically encompasses all objects, and dynamically resizes during the simulation.

The user may impose variable domain movement, which is then applied by imposing variable domain acceleration in time and space. This may be achieved by setting movement key-frames, or by analytically defining a harmonic oscillator.

“domain”: {

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“min” | vector | minimum vertex coordinates in the scene | Minimum coordinates of the domain bounding box AABB. |

“max” | vector | maximum vertex coordinates in the scene | Maximum coordinates of the domain bounding box AABB. |

“resizable” | boolean | `true` | Is domain automatically expanded and shrinked during simulation to encompass moving objects. |

“rotation_center” | vector | `[0, 0, 0]` | About which point the domain will rotate when imposing the motion. |

“impose_motion” | timeline of motion | Impose motion of the domain as translation and rotation key-frames. | |

“impose_position” | timeline of vectors | Impose motion of the domain as translation key-frames. | |

“impose_velocity” | timeline of vectors | Impose motion of the domain as translational velocity key-frames. | |

“impose_acceleration” | timeline of vectors | Impose motion of the domain as translational acceleration key-frames. | |

“impose_rotation” | timeline of vectors | Impose motion of the domain as rotation key-frames. | |

“impose_angular_velocity” | timeline of vectors | Impose motion of the domain as rotational velocity key-frames. | |

“impose_angular_acceleration” | timeline of vectors | Impose motion of the domain as rotational acceleration key-frames. | |

“impose_oscillation” | object | See explanation below. | |

“move_with” | string | Name of the moving body that domain with copy movement from. |

}

**Note:** Points leaving the domain boundaries are removed from the simulation.

**Note:** Performance will suffer if user specifies too large domain compared to the space of the fluid body.

**Example:**

```
"domain": {
"min": [0, 0, 1],
"max": [5, 1, 3.2]
"impose_motion": {
"impose_position": [[0, [0, 0, 0]], [5.0, [0, 0, 9.8]]
}
"impose_oscillation": {
"frequency": 3.0,
"axis": [0.0, 1.0, 0.0]
}
}
```

## Patches

The simulation input file does not incorporate any volumetric mesh, but only bounding surfaces (patches) of the domain and objects in the scene. These surfaces can be defined using primitives (list of connected line–segments, quadrilaterals) or imported from the commonly used mesh file formats. Patches can be movable, i.e. their motions can be imposed similarly as domain motions.

**Note:** The input is an object `patches`

containing any number of named boundary surfaces.

“patches”: {

“name_of_patch”: {

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“type” | string | `solid` | Type or boundary condition of the surface. Currently available values are:`solid` imposes solid wall boundary condition,`free_surface` marks virtual free surface of the fluid body,`inlet` uses the body geometry/mesh for flow generation. |

“geometry” | string | must be specified | How to define the geometry of the patch:`polyline` to define 2D connected line segments,`triangle` to define a single 3D triangle,`quad` to define a single 3D quad,`plane` to define a quad triangulated using default spacing,`circle` to define a circle triangulated using default spacing,`arc` to define arc patch on x-z plane (z is symmetric axis),`mesh_relative_path.obj` to load triangulated 3D surface (allowed formats: STL, OBJ, OFF, PLY) |

“cog” | vector | `[0, 0, 0]` | Initial center-of-gravity location around which the object rotates, and calculates the torque. |

“position” | vector | `[0, 0, 0]` | Initial translation. |

“rotation” | vector | `[0, 0, 0]` | Initial rotation. |

“probes” | list of vectors | List of positions where to measure the pressure. The probes move and rotate with the patch. | |

“output_forces” | boolean | `false` | If the force and torque due to fluid acting on the patch will be output to disk. |

“impose_motion” | timeline of motion | Impose motion of the patch as translation and rotation key-frames. | |

“impose_position” | timeline of vectors | Impose motion of the patch as translation key-frames. | |

“impose_velocity” | timeline of vectors | Impose motion of the patch as translational velocity key-frames. | |

“impose_acceleration” | timeline of vectors | Impose motion of the patch as translational acceleration key-frames. | |

“impose_rotation” | timeline of vectors | Impose motion of the patch as rotation key-frames. | |

“impose_angular_velocity” | timeline of vectors | Impose motion of the patch as rotational velocity key-frames. | |

“impose_angular_acceleration” | timeline of vectors | Impose motion of the patch as rotational acceleration key-frames. | |

“impose_oscillation” | object | See explanation below. | |

“points” | list of vectors | Manually input list of vertices for the polyline, triangle or quad. | |

“normal” | vector | Direction of inlet (needed for `circle` ). | |

“center” | vector | Center coordinates of `circle` . | |

“radius” | number | Radius of `circle` or `arc` . | |

“angle” | number | Arc angle (alternatively, it can be deduced by the below option `arc_length` ). | |

“arc_length” | number | Length of the arc (alternatively, it can be deduced by the above option `angle` ). | |

“thickness” | number | Depth of the arc extrusion. | |

“mass” | number | 0.0 | Mass of the object in kilograms. Must be specified if patch is not constrained, for rigid body FSI. |

“inertia” | list of numbers | List of 9 numbers to describe 3×3 body-intertia matrix. | |

“constraints” | list of strings | List of translation and rotation axes that can be constrained: `"tx"` , `"ty"` , `"tz"` , `"rx"` , `"ry"` , `"rz"` . | |

“volume_rate” | number or timeline of scalars | Define volume rate in m3/second for the generated flow for `inlet` type of patch. | |

“inlet_speed” | number | Define constant speed in meters/second for the generated flow for `inlet` type of patch. | |

“apex” | number | Angle in degrees to generate conical inlet generation. | |

“uniform_inlet_speed” | boolean | `true` | Whether the speed is uniformly distributed across the inlet. |

“minV_to_maxV” | number | 1.0 | The ratio between the minimum and the maximum inlet speed magnitude in case of non-uniform distribution. The maximum speed is supposed to be located at the inlet center, while the minimum speed is located furthest from the center. |

“average_normals” | number or timeline of scalars | 0.0 | Controlling how strong the inlet normals incline to the average direction, 0.0 means no inclination, postive value indicates concentration and negative indicates spreading. |

“inlet_speed_power” | number | 0.0 | A power used to define the shape of the inlet speed profile in case of non-uniform distribution, for instance, 0.0=uniform distribution, 1.0=linear profile, 2.0=parabolic profile. The speed distribution is further scaled to fulfill the input`inlet_speed` or`volume_rate` . |

“inlet_speed_vector” | string | “ | Designed to accept user provided inlet velocity vector per vertex. Data of one column or three columns can be accepted in csv format: Inlet_speedVariation.csv. |

“remesh” | number | The spacing of remeshing. Do nothing if not double value or no value is given. |

},

“another_patch”: { … }

}

The oscillation object can be defined as follows:

“impose_oscillation”: {

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“frequency” | number | Oscillation frequency, rad/s. Not needed if the period is specified. | |

“period” | number | Oscillation period, s. Not needed if the frequency is specified. | |

“direction” | vector | Vector specifying the direction of translation. It’s magnitude defines the amplitude of movement. | |

“axis” | vector | Vector specifying the axis of rotation. It’s magnitude defines the amplitude of movement. | |

“damping” | number | Damping ratio. |

}

**Note:** Generally, it’s not wise to use STL meshes (anywhere!) as they do not incorporate triangle connectivity information. If you still wish to use this format, solver will automatically connect triangles using default tolerance 1e-8. After merging, bad topology triangles will get removed.

**Example in 2D:**

```
"patches": {
"tank": {
"type": "solid",
"geometry": "polyline",
"points": [
[-0.3, 0.3], [-0.3, 0.0], [ 0.3, 0.0], [ 0.3, 0.3], [-0.3, 0.3]
],
"oscillation": {
"period": 1.5,
"direction": [0.05, 0]
},
"probes": [
[-0.3, 0.1],
[0.3, 0.1]
]
},
"water": {
"type": "free_surface",
"geometry": "polyline",
"points": [ [-1, 0.12], [1, 0.12] ]
}
}
```

**Example in 3D:**

```
"patches": {
"tank": {
"type": "solid",
"geometry": "some_tank_mesh.obj"
}
}
```

## Fluid

Currently a single fluid phase is supported, but soon multi-phase and variable-phase calculation will be implemented. The specified single fluid moves in the domain specified above. When the boundary surfaces are defined, user may fill the domain space with fluid.

**Note:** The fluid set-up follows the same as idea as bucket fill or flood fill tools in painting programs. Fluid is filled from some source point until it reaches wall and free-surface boundaries, defined above.

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“density” | number | `1000` | Constant density of the fluid phase, $\rho$. |

“initial_temperature” | number | `20` | Initial temperature of the fluid phase (in degrees). |

“viscosity” | number | `1e-6` | Constant kinematic viscosity of the fluid phase, $\nu$. |

“surface_tension” | number | `0.0` | Surface tension coefficient between the fluid phase and (unmodeled) other light phase, $\sigma$. |

“flood_point” | vector | [] | The point where to start flooding from. |

“flood_points” | list of vectors | [] | If multiple separated spaces need to be filled with same fluid, then specify a list of points where to flood from. |

“type” | string | `newtonian` | How the fluid diffusivity is modelled.`newtonian` for Newtonian fluids,`bingham` for Bingham-type viscoplastics,`casson` for Casson-type viscoplastics,`power_law` for Power Law model,`cross_power_law` for Cross-Power Law model,`bird_carreau` for Bird-Carreau model,`mohr_coulomb` for geophysical Mohr-Coulomb model,`pvc_pb1335` for sealing material PB1335. |

“wall_model” | string | `no_slip` | For manual control between non-slip or partially slip velocity at all boundaries. |

```
"fluid": {
"density": 998.6,
"viscosity": 1.14e-6,
"flood_point": [0.0, 0.05]
}
```

## Wall-Slip models

Currently there are four boundary condition for imposing the velocity boundary condition on the solid walls, including: no-slip, partial-slip, wall-function, and Navier-slip boundary conditions. The defaul BC is the no-slip boundary condition.

### No-slip BC

In `no_slip`

model, adjacent fluid molecule has the same velocity as the wall. This model does not need any additional input parameters.

### Partial-slip BC

In `partial_slip`

model user can manually control the slip coefficient on the boundaries.

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“slip_coef” | number | 0.5 | value between 0 and 1 to control the amount of slip. |

### wall-function slip model

In `wall_function`

model, nothing else is needed as an input. This model is for the turbulent flow applying the log-law.

### Navier-slip BC

`navier_slip`

model relates the slip velocity with the velocity gradient through a non-linear equation.

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“slip_coef” | number | 0.01 | value between 0 and 1 to control the amount of slip. |

“slip_exponent” | number | 0.5 | order of the non-linearity. For 1, it becomes a linear Navier slip prediction and non-linear for any other value |

## Non-Newtonian models

If the fluid type is not Newtonian, but some non-Newtonian type, then the below listed parameters should be set. Currently available non-Newtonian models are: `bingham`

, `casson`

, `power_law`

, `cross_power_law`

, `bird_carreau`

, `mohr_coulomb`

.

**Note:** The viscosities of non-Newtonian models are input as *dynamic*, instead of *kinematic*. This may change in the future, or there may be a switch.

### Bingham

Models a viscoplastic material that behaves as a rigid body at low stresses but flows as a viscous fluid at high stress. Once the critical shear stress (yield stress) is exceeded, the material flows in such a way that the shear rate is proportional to the amount by which the applied shear stress exceeds the yield stress.

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“viscosity” | number | must be specified | Dynamic viscosity at infinite shear rate. |

“yield_stress” | number | `0` | The critical shear stress that sets a threshold for flowing. |

“regularization” | number | `500` | Avoids the singularity of the model. Higher number allows higher viscosity near the singularity. |

### Casson Model

Similar to the Bingham model, for simulating shear-thickening behaviour of non-Newtonian fluids, for modelling viscoplastic fluids.

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“viscosity_inf” | number | must be specified | Dynamic viscosity at infinite shear rate. |

“yield_stress” | number | `0` | The critical shear stress that sets a threshold for flowing. |

“regularization” | number | `500` | Avoids the singularity of the model. Higher number allows higher viscosity near the singularity. |

### Power Law

Power-law or the Ostwald–de Waele relationship, is a type of approximate generalised Newtonian fluid (time independent Non-Newtonian fluid). It yields good flow description across the range of shear rates to which the coefficients were fitted.

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“viscosity_min” | number | must be specified | Lower bound value of dynamic viscosity. |

“viscosity_max” | number | must be specified | Upper bound value of dynamic viscosity. |

“flow_index” | number | `0.5` | $n$, dimensionless flow behaviour index. Pseudoplastic: $n < 1$, Newtonian: $n = 1$, Dilatant: $n > 1$. |

“consistency_index” | number | `0` | $k$, flow consistency index or or power-law coefficient. |

### Cross-Power Law model

A type of generalised Newtonian fluid whose viscosity depends upon shear rate according to the following equation. The zero-shear viscosity is approached at very low shear rates, while the infinite shear viscosity is approached at very high shear rates.

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“viscosity_0” | number | must be specified | Value of dynamic viscosity at zero shear rate. |

“viscosity_inf” | number | must be specified | Value of dynamic viscosity at infinite shear rate. |

“flow_index” | number | `0.5` | $n$, dimensionless flow behaviour index. Pseudoplastic: $n < 1$, Newtonian: $n = 1$, Dilatant: $n > 1$. |

“time_change” | number | `0` | Relaxation time in seconds, at which the linear behaviour changes to power law. 0 for Newtonian behaviour. |

### Bird-Carreau Model

A model that is valid over the complete range of shear rates. For cases where there are significant variations from the Power law model, i.e. at very high and very low shear rates it becomes essential to incorporate the values of viscosity at zero shear and at infinite shear into the formulation.

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“viscosity_0” | number | must be specified | Value of dynamic viscosity at zero shear rate. |

“viscosity_inf” | number | must be specified | Value of dynamic viscosity at infinite shear rate. |

“flow_index” | number | `0.5` | $n$, dimensionless flow behaviour or power index. |

“time_change” | number | `0` | Time in seconds at which the linear behaviour changes to power law. 0 for Newtonian behaviour. |

“time_relaxation” | number | `0` | Relaxation time constant. |

### Mohr-Coulomb Model

A model describing the response of brittle materials such as concrete, or rubble piles, to shear stress as well as normal stress. Generally the theory applies to materials for which the compression strength far exceeds the tensile strength.

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“viscosity” | number | must be specified | Dynamic viscosity of the fluid phase. |

“friction_angle” | number | `30` | $\phi$, internal friction angle in degrees. |

“cohesion” | number | `0` | $C$, cohesion in pressure units, Pascals. |

“regularization” | number | `500` | Avoids the singularity of the model. Higher number allows higher viscosity near the singularity. |

### PVC PB1335 Model

This is a relation that derived from fitting the experimental data of PB1335, which is used in sealing by many companies. It is a three-segment function. No parameters are needed for this model. It is hard-coded. This will hopefully be removed soon.

## Output

The results may be written to hard drive to post-process them in some post-processing software.

“output”: {

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“format” | string | `vtu` | Which output file-format to use: `vtk` , `vtu` and `hdf5` are available. |

“time_step” | number | Time interval to repeatedly output results. Zero value ignores outputting. | |

“times” | list of numbers | If not via the time–step, user may require simulation to write its results at specific times. | |

“boundary_points” | boolean | `true` | Whether to export points generated for boundary conditions or not. |

“fields” | list of strings | `["pressure", "velocity"]` | List of fluid information to export. Available values are:`pressure` `pressure_gradient` `velocity` `vorticity` |

“vertex_fields” | list of strings | List of mesh information to export on vertices. Available values are:`pressure` `contact_time` `flux` |

}

**Note:** The folder for outputting is created where the input file is located.

**Note:** Along with output fields, the solver writes: *log, forces & torques, pressure probes.*

**Note:** For `vtu`

format of output, a file named `data_time.pvd`

will be created to collect all vtu files (into Multi-block dataset) with their time makers, which can be directly read by Paraview (the filter `Extract Block`

should be used for obtaining results in a certain layer, e.g. to see the `flow`

block that contains fluid particles). A python script `run_dataset.py`

is also prepared for automatically importing data (`data_time.pvd`

), setting up filters and zoom into proper view, but this requires `python3-paraview`

support to be installed.

**Example:**

```
"output": {
"time_step": 0.2,
"times": [0.1666, 1.53],
"fields": ["velocity", "vorticity"]
}
```

## Coupling

The fluid simulation can be directly coupled to a FEM solver, using the preCICE coupling tool.

“coupling”: {

Parameter name | Data type | Default value | What to input |
---|---|---|---|

“solver” | string | `unknown` | The name of FEM solver that the simulation will be coupled to. |

“command” | string | The FEM solver command that will be called. | |

“patch” | string | The name of the patch that is used as interface for coupling the flow and the structure results. | |

“depths” | vector | `[0, 1, 0]` | 2D flows solvers coupled to 3D FE models need to specify the depth of their structure. |

“files” | list of strings | List of files needed for the FEM simulation, that will be symlinked in the output dir. |

}

**Note:** Currently explicit type of bi-directional coupling is implemented. Implicit coupling is work-in-progress.