Nalu Input File¶
Nalu requires the user to provide an input file, in YAML format, during
invocation at the command line using the naluX i
flag. By default,
naluX will look for nalu.i
in the current working directory
to determine the mesh file as well as the run setup for execution. A sample
nalu.i
is shown below:
# * mode: yaml *
#
# Example Nalu input file for a heat conduction problem
#
Simulations:
 name: sim1
time_integrator: ti_1
optimizer: opt1
linear_solvers:
 name: solve_scalar
type: tpetra
method: gmres
preconditioner: sgs
tolerance: 1e3
max_iterations: 75
kspace: 75
output_level: 0
realms:
 name: realm_1
mesh: periodic3d.g
use_edges: no
automatic_decomposition_type: rcb
equation_systems:
name: theEqSys
max_iterations: 2
solver_system_specification:
temperature: solve_scalar
systems:
 HeatConduction:
name: myHC
max_iterations: 1
convergence_tolerance: 1e5
initial_conditions:
 constant: ic_1
target_name: block_1
value:
temperature: 10.0
material_properties:
target_name: block_1
specifications:
 name: density
type: constant
value: 1.0
 name: thermal_conductivity
type: constant
value: 1.0
 name: specific_heat
type: constant
value: 1.0
boundary_conditions:
 wall_boundary_condition: bc_left
target_name: surface_1
wall_user_data:
temperature: 20.0
 wall_boundary_condition: bc_right
target_name: surface_2
wall_user_data:
temperature: 40.0
solution_options:
name: myOptions
use_consolidated_solver_algorithm: yes
options:
 element_source_terms:
temperature: FEM_DIFF
output:
output_data_base_name: femHC.e
output_frequency: 10
output_node_set: no
output_variables:
 dual_nodal_volume
 temperature
Time_Integrators:
 StandardTimeIntegrator:
name: ti_1
start_time: 0
termination_step_count: 25
time_step: 10.0
time_stepping_type: fixed
time_step_count: 0
second_order_accuracy: no
realms:
 realm_1
Nalu input file contains the following toplevel sections that describe the simulation to be executed.
Realms
Realms describe the computational domain (via mesh input files) and the set of physics equations (LowMach NavierStokes, Heat Conduction, etc.) that are solved over this particular domain. The list can contain multiple computational domains (realms) that use different meshes as well as solve different sets of physics equations and interact via solution transfer. This section also contains information regarding the initial and boundary conditions, solution output and restart options, the linear solvers used to solve the linear system of equations, and solution options that govern the discretization of the equation set.
A special case of a realm instance is the inputoutput realm; this realm type does not solve any physics equations, but instead serves one of the following purposes:
provide timevarying boundary conditions to one or more boundaries within one or more of the participating realms in the simulations. In this context, it acts as an input realm.
extract a subset of data for output at a different frequency from the other realms. In this context, it acts as an output realm.
Inclusion of an input/output realm will require the user to provide the additional
transfers
section in the Nalu input file that defines the solution fields that are transferred between the realms. See Physics Realm Options for detailed documentation on all Realm options.
Linear Solvers
This section configures the solvers and preconditioners used to solve the resulting linear system of equations within Nalu. The linear system convergence tolerance and other controls are set here and can be used with multiple systems across different realms. See Linear Solvers for more details.
Time Integrators
This section configures the time integration scheme used (first/second order in time), the duration of simulation, fixed or adaptive timestepping based on Courant number constraints, etc. Each time integration section in this list can accept one or more
realms
that are integrated in time using that specific time integration scheme. See Time Integration Options for complete documentation of all time integration options available in Nalu.
Transfers
An optional section that defines one or more solution transfer definitions between the participating
realms
during the simulation. Each transfer definition provides a mapping of the to and from realm, part, and the solution field that must be transferred at every timestep during the simulation. See ABL Forcing section for complete documentation of all transfer options available in Nalu.
Simulations
Simulations provides the toplevel architecture that orchestrates the timestepping across all the realms and the required equation sets.
Linear Solvers¶
The linear_solvers
section contains a list of one or more linear solver
settings that specify the solver, preconditioner, convergence tolerance for
solving a linear system. Every entry in the YAML list will contain the following
entries:
Note
The variable in the linear_solvers
subsection are prefixed with
linear_solvers.name
but only the variable name after the period should
appear in the input file.

linear_solvers.name
¶ The key used to refer to the linear solver configuration in
equation_systems.solver_system_specification
section.

linear_solvers.type
¶ The type of solver library used.
Type
Description
tpetra
Tpetra data structures and Belos solvers/preconditioners
hypre
Hypre data structures and Hypre solver/preconditioners

linear_solvers.method
¶ The solver used for solving the linear system.
When
linear_solvers.type
istpetra
the valid options are:gmres
,biCgStab
,cg
. Forhypre
the valid options arehypre_boomerAMG
andhypre_gmres
.
Options Common to both Solver Libraries

linear_solvers.preconditioner
¶ The type of preconditioner used.
When
linear_solvers.type
istpetra
the valid options aresgs
,mt_sgs
,muelu
. Forhypre
the valid options areboomerAMG
ornone
.

linear_solvers.tolerance
¶ The relative tolerance used to determine convergence of the linear system.

linear_solvers.max_iterations
¶ Maximum number of linear solver iterations performed.

linear_solvers.kspace
¶ The Krylov vector space.

linear_solvers.output_level
¶ Verbosity of output from the linear solver during execution.

linear_solvers.write_matrix_files
¶ A boolean flag indicating whether the matrix, the right hand side, and the solution vector are written to files during execution. The matrix files are written in MatrixMarket format. The default value is
no
.
Additional parameters for Belos Solver/Preconditioners

linear_solvers.muelu_xml_file_name
¶ Only used when the
linear_solvers.preconditioner
is set tomuelu
and specifies the path to the XML filename that contains various configuration parameters for Trilinos MueLu package.

linear_solvers.recompute_preconditioner
¶ A boolean flag indicating whether preconditioner is recomputed during runs. The default value is
yes
.

linear_solvers.reuse_preconditioner
¶ Boolean flag. Default value is
no
.

linear_solvers.summarize_muelu_timer
¶ Boolean flag indicating whether MueLu timer summary is printed. Default value is
no
.
Additional parameters for Hypre Solver/Preconditioners
The user is referred to Hypre Reference Manual for full details on the usage of the parameters described briefly below.
The parameters that start with bamg_
prefix refer to options related to
Hypre’s BoomerAMG preconditioner.

linear_solvers.bamg_output_level
¶ The level of verbosity of BoomerAMG preconditioner. See
HYPRE_BoomerAMGSetPrintLevel
. Default: 0.

linear_solvers.bamg_coarsen_type
¶ See
HYPRE_BoomerAMGSetCoarsenType
. Default: 6

linear_solvers.bamg_cycle_type
¶ See
HYPRE_BoomerAMGSetCycleType
. Default: 1

linear_solvers.bamg_relax_type
¶ See
HYPRE_BoomerAMGSetRelaxType
. Default: 6

linear_solvers.bamg_relax_order
¶ See
HYPRE_BoomerAMGSetRelaxOrder
. Default: 1

linear_solvers.bamg_num_sweeps
¶ See
HYPRE_BoomerAMGSetNumSweeps
. Default: 2

linear_solvers.bamg_max_levels
¶ See
HYPRE_BoomerAMGSetMaxLevels
. Default: 20

linear_solvers.bamg_strong_threshold
¶ See
HYPRE_BoomerAMGSetStrongThreshold
. Default: 0.25
Time Integration Options¶

Time_Integrators
¶ A list of timeintegration options used to advance the
realms
in time. Each list entry must contain a YAML mapping with the key indicating the type of time integrator. Currently only one option,StandardTimeIntegrator
is available.Time_Integrators:  StandardTimeIntegrator: name: ti_1 start_time: 0.0 termination_step_count: 10 time_step: 0.5 time_stepping_type: fixed time_step_count: 0 second_order_accuracy: yes realms:  fluids_realm

time_int.name
¶ The lookup key for this time integration entry. This name must match the one provided in
Simulations
section.

time_int.termination_time
¶ Nalu will stop the simulation once the
termination_time
has reached.

time_int.termination_step_count
¶ Nalu will stop the simulation once the specified
termination_step_count
timesteps have been completed. If bothtime_int.termination_time
and this parameter are provided then this parameter will prevail.

time_int.time_step
¶ The time step (\(\Delta t\)) used for the simulation. If
time_int.time_stepping_type
isfixed
this value does not change during the simulation.

time_int.start_time
¶ The starting time step (default:
0.0
) when starting a new simulation. Note that this has no effect on restart which is controlled byrestart.restart_time
in therestart
section.

time_int.time_step_count
¶ The starting timestep counter for a new simulation. See
restart
for restarting from a previous simulation.

time_int.second_order_accuracy
¶ A boolean flag indicating whether secondorder time integration scheme is activated. Default:
no
.

time_int.time_stepping_type
¶ One of
fixed
oradaptive
indicating whether a fixed timestepping scheme or an adaptive timestepping scheme is used for simulations. Seetime_step_control
for more information on max Courant number based adaptive time stepping.

time_int.realms
¶ A list of
realms
names. The names entered here must matchname
used in therealms
section. Names listed here not found inrealms
list will trigger an error, while realms not included in this list but present inrealms
will not be initialized and silently ignored. This can cause the code to abort if the user attempts to access the specific realm in thetransfers
section.
Physics Realm Options¶
As mentioned previously, realms
is a YAML list data structure
containing at least one Physics Realm Options entry that defines the
computational domain (provided as an ExodusII mesh), the set of physics
equations that must be solved over this domain, along with the necessary initial
and boundary conditions. Each list entry is a YAML dictionary mapping that is
described in this section of the manual. The key subsections of a Realm entry
in the input file are
Realm subsection 
Purpose 

Set of physics equations to be solved 

Initial conditions for the various fields 

Boundary condition for the different fields 

Material properties (e.g., fluid density, viscosity etc.) 


Discretization options 
Solution output options (file, frequency, etc.) 

Optional: Restart options (restart time, checkpoint frequency etc.) 

Optional: Parameters determining variable timestepping 
In addition to the sections mentioned in the table, there are several additional sections that could be present depending on the specific simulation type and postprocessing options requested by the user. A brief description of these optional sections are provided below:
Realm subsection 
Purpose 

Generate statistics for the flow field 

Extract integrated data from the simulation 


Compare the solution error to a reference solution 
Extract data using probes 

Model turbine blades/tower using actuator lines 

Momentum source term to drive ABL flows to a desired velocity profile 
Common options¶

name
¶ The name of the realm. The name provided here is used in the
Time_Integrators
section to determine the timeintegration scheme used for this computational domain.

mesh
¶ The name of the ExodusII mesh file that defines the computational domain for this realm. Note that only the base name (i.e., without the
.NPROCS.IPROC
suffix) is provided even for simulations using previously decomposed mesh/restart files.

automatic_decomposition_type
¶ Used only for parallel runs, this indicates how the a single mesh database must be decomposed amongst the MPI processes during initialization. This option should not be used if the mesh has already been decomposed by an external utility. Possible values are:
Value
Description
rcb
recursive coordinate bisection
rib
recursive inertial bisection
linear
elements in order first n/p to proc 0, next to proc 1.
cyclic
elements handed out to id % proc_count

activate_aura
¶ A boolean flag indicating whether an extra element is ghosted across the processor boundaries. The default value is
no
.

use_edges
¶ A boolean flag indicating whether edge based discretization scheme is used instead of element based schemes. The default value is
no
.

polynomial_order
¶ An integer value indicating the polynomial order used for higherorder mesh simulations. The default value is
1
. Whenpolynomial_order
is greater than 1, the Realm has the capability to promote the mesh to higherorder during initialization.

solve_frequency
¶ An integer value indicating how often this realm is solved during time integration. The default value is
1
.

support_inconsistent_multi_state_restart
¶ A boolean flag indicating whether restarts are allowed from files where the necessary field states are missing. A typical situation is when the simulation is restarted using secondorder time integration but the restart file was created using firstorder time integration scheme.

activate_memory_diagnostic
¶ A boolean flag indicating whether memory diagnostics are activated during simulation. Default value is
no
.

balance_nodes
¶ A boolean flag indicating whether node balancing is performed during simulations. See also
balance_node_iterations
andbalance_nodes_target
.

balance_node_iterations
¶ The frequency at which node rebalancing is performed. Default value is
5
.

balance_node_target
¶ The target balance ratio. Default value is
1.0
.
Equation Systems¶

equation_systems
¶ equation_systems
subsection defines the physics equation sets that are solved for this realm and the linear solvers used to solve the different linear systems.
Note
The variable in the equation_systems
subsection are prefixed with
equation_systems.name
but only the variable name after the period should
appear in the input file.

equation_systems.name
¶ A string indicating the name used in log messages etc.

equation_systems.max_iterations
¶ The maximum number of nonlinear iterations performed during a timestep that couples the different equation systems.

equation_systems.solver_system_specification
¶ A mapping containing
field_name: linear_solver_name
that determines the linear solver used for solving the linear system. Example:solver_system_specification: pressure: solve_continuity enthalpy: solve_scalar velocity: solve_scalar
The above example indicates that the linear systems for the enthalpy and momentum (velocity) equations are solved by the linear solver corresponding to the tag
solve_scalar
in thelinear_systems
entry, whereas the continuity equation system (pressure Poisson solve) should be solved using the linear solver definition corresponding to the tagsolve_continuity
.

equation_systems.systems
¶ A list of equation systems to be solved within this realm. Each entry is a YAML mapping with the key corresponding to a predefined equation system name that contains additional parameters governing the solution of this equation set. The predefined equation types are
Equation system
Description
LowMachEOM
LowMach Momentum and Continuity equations
Enthalpy
Energy equations
ShearStressTransport
\(k\omega\) SST equation set
TurbKineticEnergy
TKE equation system
MassFraction
Mass Fraction
MixtureFraction
Mixture Fraction
MeshDisplacement
Arbitrary Mesh Displacement
An example of the equation system definition for ABL precursor simulations is shown below:
# Equation systems example for ABL precursor simulations systems:  LowMachEOM: name: myLowMach max_iterations: 1 convergence_tolerance: 1.0e5  TurbKineticEnergy: name: myTke max_iterations: 1 convergence_tolerance: 1.0e2  Enthalpy: name: myEnth max_iterations: 1 convergence_tolerance: 1.0e2
Initial conditions¶

initial_conditions
¶ The
initial_conditions
subsections defines the conditions used to initialize the computational fields if they are not provided via the mesh file. Two types of field initializations are currently possible:constant
 Initialize the field with a constant value throughout the domain;user_function
 Initialize the field with a predefined user function.
The snippet below shows an example of both options available to initialize the various computational fields used for ABL simulations. In this example, the pressure and turbulent kinetic energy fields are initialized using a constant value, whereas the velocity field is initialized by the user function
boundary_layer_perturbation
that imposes sinusoidal fluctations over a velocity field to trip the flow.initial_conditions:  constant: ic_1 target_name: [fluid_part] value: pressure: 0.0 turbulent_ke: 0.1  user_function: ic_2 target_name: [fluid_part] user_function_name: velocity: boundary_layer_perturbation user_function_parameters: velocity: [1.0,0.0075398,0.0075398,50.0,8.0]

initial_conditions.constant
¶ This input parameter serves two purposes: 1. it indicates the type (
constant
), and 2. provides the custom name for this condition. In addition to theinitial_conditions.target_name
this section requires another entryvalue
that contains the mapping of(field_name, value)
as shown in the above example.

initial_conditions.user_function
¶ Indicates that this block of YAML input must be parsed as input for a user defined function.

initial_conditions.target_name
¶ A list of element blocks (parts) where this initial condition must be applied.
Boundary Conditions¶

boundary_conditions
¶ This subsection of the physics Realm contains a list of boundary conditions that must be used during the simulation. Each entry of this list is a YAML mapping entry with the key of the form
<type>_boundary_condition
where the available types are:inflow
open
– Outflow BCwall
symmetry
periodic
non_conformal
– e.g., BC across sliding mesh interfacesoverset
– overset mesh assembly description
All BC types require bc.target_name
that contains a list of side sets
where the specified BC is to be applied. Additional information necessary for
certain BC types are provided by a subdictionary with the key
<type>_user_data:
that contains the parameters necessary to initialize a
specific BC type.

bc.target_name
¶ A list of side set part names where the given BC type must be applied. If a single string value is provided, it is converted to a list internally during input file processing phase.
Inflow Boundary Condition¶
 inflow_boundary_condition: bc_inflow
target_name: inlet
inflow_user_data:
velocity: [0.0,0.0,1.0]
Open Boundary Condition¶
 open_boundary_condition: bc_open
target_name: outlet
open_user_data:
velocity: [0,0,0]
pressure: 0.0
Wall Boundary Condition¶

bc.wall_user_data
¶ This subsection contains specifications as to whether wall models are used, or how to treat the velocity at the wall when there is mesh motion.
The following input file snippet shows an example of using an ABL wall function at the terrain during ABL simulations. See theory_abl_wall_function for more details on the actual implementation.
# Wall boundary condition example for ABL terrain modeling
 wall_boundary_condition: bc_terrain
target_name: terrain
wall_user_data:
velocity: [0,0,0]
use_abl_wall_function: yes
heat_flux: 0.0
roughness_height: 0.2
gravity_vector_component: 3
reference_temperature: 300.0
The entry gravity_vector_component
is an integer that
specifies the component of the gravity vector, defined in
solution_options.gravity
, that should be used in the
definition of the MoninObukhov length scale calculation. The
entry reference_temperature
is the reference temperature
used in calculation of the MoninObukhov length scale.
When there is mesh motion involved the wall boundary must specify a user function to determine relative velocity at the surface.
# Wall boundary specification with mesh motion
 wall_boundary_condition: bc_cylinder
target_name: cylinder_wall
wall_user_data:
user_function_name:
velocity: wind_energy
user_function_string_parameters:
velocity: [cylinder]
The misnomer wind_energy
is a predefined user function that provides the
correct velocity at the wall accounting for relative mesh motion with respect to
fluid and doesn’t specifically deal with any wind energy simulation. The
user_function_string_parameters
contains a YAML mapping of fields, e.g.
velocity, to the list of names provided in the soln_opts.mesh_motion
entry in the solution_options
section.
Example of wall boundary with a custom user function for temperature at the wall
 wall_boundary_condition: bc_6
target_name: surface_6
wall_user_data:
user_function_name:
temperature: steady_2d_thermal
Symmetry Boundary Condition¶
Requires no additional input other than bc.target_name
.
 symmetry_boundary_condition: bc_top
target_name: top
symmetry_user_data:
Periodic Boundary Condition¶
Unlike the other BCs described so far, the parameter bc.target_name
behaves differently for the periodic BC. This parameter must be a list
containing exactly two entries: the boundary face pair where periodicity is
enforced. The nodes on these planes must coincide after translation in the
direction of periodicity. This BC also requires a periodic_user_data
section that specifies the search tolerance for locating node pairs.

periodic_user_data
¶  periodic_boundary_condition: bc_east_west target_name: [east, west] periodic_user_data: search_tolerance: 0.0001
NonConformal Boundary¶
Like the periodic BC, the parameter bc.target_name
must be a list
with exactly two entries that specify the boundary plane pair forming the
nonconformal boundary.
 non_conformal_boundary_condition: bc_left
target_name: [surface_77, surface_7]
non_conformal_user_data:
expand_box_percentage: 10.0
Material Properties¶

material_properties
¶ The section provides the properties required for various physical quantities during the simulation. A sample section used for simulating ABL flows is shown below
material_properties: target_name: [fluid_part] constant_specification: universal_gas_constant: 8314.4621 reference_pressure: 101325.0 reference_quantities:  species_name: Air mw: 29.0 mass_fraction: 1.0 specifications:  name: density type: constant value: 1.178037722969475  name: viscosity type: constant value: 1.6e5  name: specific_heat type: constant value: 1000.0

material_properties.target_name
¶ A list of element blocks (parts) where the material properties are applied. This list should ideally include all the parts that are referenced by
initial_conditions.target_name
.

material_properties.constant_specification
¶ Values for several constants used during the simulation. Currently the following properties are defined:
Name
Description
universal_gas_constant
Ideal gas constant \(R\)
reference_temperature
Reference temperature for simulations
reference_pressure
Reference pressure for simulations

material_properties.reference_quantities
¶ Provides material properties for the different species involved in the simulation.
Name
Description
species_name
Name used to lookup properties
mw
Molecular weight
mass_fraction
Mass fraction
primary_mass_fraction
secondary_mass_fraction
stoichiometry

material_properties.specifications
¶ A list of material properties with the following parameters

material_properties.specifications.name
¶ The name used for lookup, e.g.,
density
,viscosity
, etc.

material_properties.specifications.type
¶ The type can be one of the following
Type
Description
constant
Constant value property
polynomial
Property determined by a polynomial function
ideal_gas
Function of temperature, pressure, and mixture molecular weight
hdf5table
Lookup from an HDF5 table
mixture_fraction
Property determined by the mixture fraction
geometric
generic
Examples
Specification for density using the ideal gas. The code determines what is reference and what is transported
specifications:  name: density type: ideal_gas
Specification of viscosity as a function of temperature
 name: viscosity type: polynomial coefficient_declaration:  species_name: Air coefficients: [1.7894e5, 273.11, 110.56]
The
species_name
must correspond to the entry inreference quantitites
to lookup molecular weight information.Specification via
hdf5table
material_properties: table_file_name: SLFM_CGauss_C2H4_ZMean_ZScaledVarianceMean_logChiMean.h5 specifications:  name: density type: hdf5table independent_variable_set: [mixture_fraction, scalar_variance, scalar_dissipation] table_name_for_property: density table_name_for_independent_variable_set: [ZMean, ZScaledVarianceMean, ChiMean] aux_variables: temperature table_name_for_aux_variables: temperature  name: viscosity type: hdf5table independent_variable_set: [mixture_fraction, scalar_variance, scalar_dissipation] table_name_for_property: mu table_name_for_independent_variable_set: [ZMean, ZScaledVarianceMean, ChiMean]
Specification via
mixture_fraction
material_properties: target_name: block_1 specifications:  name: density type: mixture_fraction primary_value: 0.163e3 secondary_value: 1.18e3  name: viscosity type: mixture_fraction primary_value: 1.967e4 secondary_value: 1.85e4
Output Options¶

output
¶ Specifies the frequency of output, the output database name, etc.
Example:
output: output_data_base_name: out/ABL.neutral.e output_frequency: 100 output_node_set: no output_variables:  velocity  pressure  temperature

output.output_data_base_name
¶ The name of the output ExodusII database. Can specify a directory relative to the run directory, e.g.,
out/nalu_results.e
. The directory will be created automatically if one doesn’t exist. Default:output.e

output.output_frequency
¶ Nalu will write the output file every
output_frequency
timesteps. Note that currently there is no option to output results at a specified simulation time. Default:1
.

output.output_start
¶ Nalu will start writing output past the
output_start
timestep. Default:0
.

output.output_forced_wall_time
¶ Force output at a specified wallclock time in seconds.

output.output_node_set
¶ Boolean flag indicating whether nodesets, if present, should be output to the output file along with element blocks.

output.compression_level
¶ Integer value indicating the compression level used. Default:
0
.

output.output_variables
¶ A list of field names to be output to the database. The field variables can be node or element based quantities.
Restart Options¶

restart
¶ This section manages the restart for this realm object.

restart.restart_data_base_name
¶ The filename for restart. Like
output
, the filename can contain a directory and it will be created if not already present.

restart.restart_time
¶ If this variable is present, it indicates that the current run will restart from a previous simulation. This requires that the
mesh
be a restart file with all the fields necessary for the equation sets defined in theequation_systems.systems
. Nalu will restart from the closest time available in themesh
torestart_time
. The timesteps available in a restart file can be examined by looking at thetime_whole
variable using thencdump
utility.Note
The restart database used for restarting a simulation is the
mesh
parameter. Therestart_data_base_name
parameter is used exclusively for outputs.

restart.restart_frequency
¶ The frequency at which restart files are written to the disk. Default:
500
timesteps.

restart.restart_start
¶ Nalu will write a restart file after
restart_start
timesteps have elapsed.

restart.restart_forced_wall_time
¶ Force writing of restart file after specified wallclock time in seconds.

restart.restart_node_set
¶ A boolean flag indicating whether nodesets are output to the restart database.

restart.max_data_base_step_size
¶ Default:
100,000
.

restart.compression_level
¶ Compression level. Default:
0
.
Timestep Control Options¶

time_step_control
¶ This optional section specifies the adpative time stepping parameters used if
time_int.time_stepping_type
is set toadaptive
.time_step_control: target_courant: 2.0 time_step_change_factor: 1.2

dtctrl.target_courant
¶ Maximum Courant number allowed during the simulation. Default:
1.0

dtctrl.time_step_change_factor
¶ Maximum allowable increase in
dt
over a given timestep.
Actuator¶

actuator
¶ actuator
subsection defines the inputs for actuator line simulations. A sample section is shown below for running actuator line simulations coupled to OpenFAST with two turbines.
actuator:
type: ActLinePointDrag
search_method: stk_kdtree
search_target_part: Unspecified2HEX
specifications:
 turbine_name: machine_one
radius: 0.5
omega: 1.57
gaussian_decay_radius: 1.0
gaussian_decay_target: 0.01
tip_coordinates: [2.5, 2.0, 0.0]
tail_coordinates: [2.5, 2.0, 0.0]
number_of_points: 11

actuator.type
¶ Type of actuator source. Options are only
ActLinePointDrag
.

actuator.search_method
¶ String specifying the type of search method used to identify the nodes within the search radius of the actuator points. Options are only
stk_kdtree
.

search_target_part
¶ String or an array of strings specifying the parts of the mesh to be searched to identify the nodes near the actuator points.

turbine_name
¶ A unique name for each line point drag.

radius
¶ Particle size.

omega
¶ Rotation rate.

gaussian_decay_radius
¶ Size of decay.

gaussian_decay_target
¶ Clipped value for PDF.

tip_coordinates
¶ Coordinates for tip.

tail_coordinates
¶ Coordinates for tail.

number_of_points
¶ Number of pointparticles along the line.
Turbulence averaging¶

turbulence_averaging
¶ turbulence_averaging
subsection defines the turbulence postprocessing quantities and averaging procedures. A sample section is shown belowturbulence_averaging: forced_reset: no time_filter_interval: 100000.0 averaging_type: nalu_classic/moving_exponential specifications:  name: turbulence_postprocessing target_name: interior reynolds_averaged_variables:  velocity favre_averaged_variables:  velocity  resolved_turbulent_ke compute_tke: yes compute_reynolds_stress: yes compute_resolved_stress: yes compute_temperature_resolved_flux: yes compute_sfs_stress: yes compute_temperature_sfs_flux: yes compute_q_criterion: yes compute_vorticity: yes compute_lambda_ci: yes
Note
The variable in the turbulence_averaging
subsection are
prefixed with turbulence_averaging.name
but only the variable
name after the period should appear in the input file.

turbulence_averaging.forced_reset
¶ A boolean flag indicating whether the averaging of all quantities in the turbulence averaging section is reset. If this flag is true, the running average is set to zero.

turbulence_averaging.averaging_type
¶ This parameter sets the choice of the running average type. Possible values are:
nalu_classic
“Sawtooth” average. The running average is set to zero each time the time filter width is reached and a new average is calculated for the next time interval.
moving_exponential
“Moving window” average where the window size is set to to the time filter width. The contribution of any quantity before the moving window towards the average value reduces exponentially with every time step.

turbulence_averaging.time_filter_interval
¶ Number indicating the time filter size over which to calculate the running average. This quantity is used in different ways for each filter discussed above.

turbulence_averaging.specifications
¶ A list of turbulence postprocessing properties with the following parameters

turbulence_averaging.specifications.name
¶ The name used for lookup and logging.

turbulence_averaging.specifications.target_name
¶ A list of element blocks (parts) where the turbulence averaging is applied.

turbulence_averaging.specifications.reynolds_average_variables
¶ A list of field names to be averaged.

turbulence_averaging.specifications.favre_average_variables
¶ A list of field names to be Favre averaged.

turbulence_averaging.specifications.compute_tke
¶ A boolean flag indicating whether the turbulent kinetic energy is computed. The default value is
no
.

turbulence_averaging.specifications.compute_reynolds_stress
¶ A boolean flag indicating whether the reynolds stress is computed. The default value is
no
.

turbulence_averaging.specifications.compute_resolved_stress
¶ A boolean flag indicating whether the average resolved stress is computed as \(< \bar\rho \widetilde{u_i} \widetilde{u_j} >\). The default value is
no
. When this option is turned on, the Favre average of the resolved velocity, \(< \bar{\rho} \widetilde{u_j} >\), is computed as well.

turbulence_averaging.specifications.compute_temperature_resolved_flux
¶ A boolean flag indicating whether the average resolved temperature flux is computed as \(< \bar\rho \widetilde{u_i} \widetilde{\theta} >\). The default value is
no
. When this option is turned on, the Favre average of the resolved temperature, \(< \bar{\rho} \widetilde{\theta} >\), is computed as well.

turbulence_averaging.specifications.compute_sfs_stress
¶ A boolean flag indicating whether the average subfilter scale stress is computed. The default value is
no
. The subfilter scale stress model is assumed to be of an eddy viscosity type and the turbulent viscosity computed by the turbulence model is used. The subfilter scale kinetic energy is used to determine the isotropic component of the subfilter stress. As described in the section Conservation of Momentum, the Yoshizawa model is used to compute the subfilter kinetic energy when it is not transported.

turbulence_averaging.specifications.compute_temperature_sfs_flux
¶ A boolean flag indicating whether the average subfilter scale flux of temperature is computed. The default value is
no
. The subfilter scale stress model is assumed to be of an eddy diffusivity type and the turbulent diffusivity computed by the turbulence model is used along with a constant turbulent Prandtl number obtained from the Realm.

turbulence_averaging.specifications.compute_favre_stress
¶ A boolean flag indicating whether the Favre stress is computed. The default value is
no
.

turbulence_averaging.specifications.compute_favre_tke
¶ A boolean flag indicating whether the Favre stress is computed. The default value is
no
.

turbulence_averaging.specifications.compute_q_criterion
¶ A boolean flag indicating whether the qcriterion is computed. The default value is
no
.

turbulence_averaging.specifications.compute_vorticity
¶ A boolean flag indicating whether the vorticity is computed. The default value is
no
.

turbulence_averaging.specifications.compute_lambda_ci
¶ A boolean flag indicating whether the Lambda2 vorticity criterion is computed. The default value is
no
.
Data probes¶

data_probes
¶ data_probes
subsection defines the data probes. A sample section is shown belowdata_probes: output_frequency: 100 search_method: stk_octree search_tolerance: 1.0e3 search_expansion_factor: 2.0 specifications:  name: probe_bottomwall from_target_part: bottomwall line_of_site_specifications:  name: probe_bottomwall number_of_points: 100 tip_coordinates: [6.39, 0.0, 0.0] tail_coordinates: [4.0, 0.0, 0.0] output_variables:  field_name: tau_wall field_size: 1  field_name: pressure specifications:  name: probe_profile from_target_part: interior line_of_site_specifications:  name: probe_profile number_of_points: 100 tip_coordinates: [0, 0.0, 0.0] tail_coordinates: [0.0, 0.0, 1.0] output_variables:  field_name: velocity field_size: 3  field_name: reynolds_stress field_size: 6
Note
The variable in the data_probes
subsection are prefixed
with data_probes.name
but only the variable name after the
period should appear in the input file.

data_probes.output_frequency
¶ Integer specifying the frequency of output.

data_probes.search_method
¶ String specifying the search method for finding nodes to transfer field quantities to the data probe lineout.

data_probes.search_tolerance
¶ Number specifying the search tolerance for locating nodes.

data_probes.search_expansion_factor
¶ Number specifying the factor to use when expanding the node search.

data_probes.specifications
¶ A list of data probe properties with the following parameters

data_probes.specifications.name
¶ The name used for lookup and logging.

data_probes.specifications.from_target_part
¶ A list of element blocks (parts) where to do the data probing.

data_probes.specifications.line_of_site_specifications
¶ A list specifications defining the lineout
Parameter
Description
name
File name (without extension) for the data probe
number_of_points
Number of points along the lineout
tip_coordinates
List containing the coordinates for the start of the lineout
tail_coordinates
List containing the coordinates for the end of the lineout

data_probes.specifications.output_variables
¶ A list of field names (and field size) to be probed.
Postprocessing¶

post_processing
¶ post_processing
subsection defines the different postprocessign options. A sample section is shown belowpost_processing:  type: surface physics: surface_force_and_moment output_file_name: results/wallHump.dat frequency: 100 parameters: [0,0] target_name: bottomwall
Note
The variable in the post_processing
subsection are prefixed with
post_processing.name
but only the variable name after the period should
appear in the input file.

post_processing.type
¶ Type of postprocessing. Possible values are:
Value
Description
surface
Postprocessing of surface quantities

post_processing.physics
¶ Physics to be postprocessing. Possible values are:
Value
Description
surface_force_and_moment
Calculate surface forces and moments
surface_force_and_moment_wall_function
Calculate surface forces and moments when using a wall function

post_processing.output_file_name
¶ String specifying the output file name.

post_processing.frequency
¶ Integer specifying the frequency of output.

post_processing.parameters
¶ Parameters for the physics function. For the
surface_force_and_moment
type functions, this is a list specifying the centroid coordinates used in the moment calculation.

post_processing.target_name
¶ A list of element blocks (parts) where to do the postprocessing
ABL Forcing¶

abl_forcing
¶ abl_forcing
allows the user to specify desired velocities and temperatures at different heights. These velocities and temperatures are enforced through the use of source in the momentum and enthalpy equations. Theabl_forcing
option needs to be specified in themomentum
and/orenthalpy
source blocks: source_terms: momentum: abl_forcing enthalpy: abl_forcing
This option allows the code to implement source terms in the momentum and/or enthalpy equations. A sample section is shown below
abl_forcing: search_method: stk_kdtree search_tolerance: 0.0001 search_expansion_factor: 1.5 output_frequency: 1 from_target_part: [fluid_part] momentum: type: computed relaxation_factor: 1.0 heights: [250.0, 500.0, 750.0] target_part_format: "zplane_%06.1f" # The velocities at each plane # Each list include a time and the velocities for each plane # Notice that the total number of elements in each list will be # number of planes + 1 velocity_x:  [0.0, 10.0, 5.0, 15.0]  [100000.0, 10.0, 5.0, 15.0] velocity_y:  [0.0, 0.0, 0.0, 0.0]  [100000.0, 0.0, 0.0, 0.0] velocity_z:  [0.0, 0.0, 0.0, 0.0]  [100000.0, 0.0, 0.0, 0.0] temperature: type: computed relaxation_factor: 1.0 heights: [250.0, 500.0, 750.0] target_part_format: "zplane_%06.1f" temperature:  [0.0, 300.0, 280.0, 310.0]  [100000.0, 300.0, 280.0, 310.0]
Note
The variables in the abl_forcing
subsection are
prefixed with abl_forcing.name
but only the variable
name after the period should appear in the input file.

abl_forcing.search_method
¶ This specifies the search method algorithm within the stk framework. The default option stk_kdtree is recommended.

abl_forcing.search_tolerance
¶ This is the tolerance specified for the search_method algorithm. A default value of 0.0001 is recommended.

abl_forcing.search_expansion_factor
¶ This option is related to the stk search algorithm. A value of 1.5 is recommended.

abl_forcing.output_frequency
¶ This is the frequency at which the source term is written to the output value. A value of 1 means the source term will be written to the output file every timestep.
Note
There are now two options in the following inputs.
The can be momentum
and/or temperature
.

abl_forcing.momentum.computed
¶ This option allows the user to choose if a momentum source is computed from a desired velocity (
computed
) or if a user defined source term is directly applied into the momentum equation (user_defined
).

abl_forcing.momentum.relaxation_factor
¶ This is a relaxation factor which can be used to under/overrelax the momentum source term. The default value is 1.

abl_forcing.momentum.heights
¶ This is a list containing the planes at which the forcing should be implemented. Each input is the height for that plane. This is the naming convention in the mesh file.

abl_forcing.momentum.target_part_format
¶ This is the format in which the planes are saved in the mesh file.

abl_forcing.momentum.velocity_x
¶ A set of lists containing the time in the first element, followed by the desired velocity at each plane in the \(x\) direction.

abl_forcing.momentum.velocity_y
¶ A set of lists containing the time in the first element, followed by the desired velocity at each plane in the \(y\) direction.

abl_forcing.momentum.velocity_z
¶ A set of lists containing the time in the first element, followed by the desired velocity at each plane in the \(z\) direction.
Note
The temperature has the same inputs as the momentum source
(abl_forcing.temperature.type
,
abl_forcing.temperature.relaxation_factor
,
abl_forcing.temperature.heights
, and
abl_forcing.temperature.target_part_format
)
which take the same options.

abl_forcing.temperature.temperature
¶ A set of lists containing the time in the first element, followed by the desired temperature at each plane.