Nalu-Wind Input File
Nalu-Wind 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: 1e-3
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: 1e-5
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-Wind input file contains the following top-level sections that describe the simulation to be executed.
Realms
Realms describe the computational domain (via mesh input files) and the set of physics equations (Low-Mach Navier-Stokes, 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 input-output realm; this realm type does not solve any physics equations, but instead serves one of the following purposes:
provide time-varying 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 :inpfile:`transfers` section in the Nalu-Wind 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-Wind. 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 :inpfile:`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-Wind.
Transfers
An optional section that defines one or more solution transfer definitions between the participating :inpfile:`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-Wind.
Simulations
Simulations provides the top-level architecture that orchestrates the time-stepping 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 :inpfile:`linear_solvers` subsection are prefixed with
linear_solvers.name
but only the variable name after the period should
appear in the input file.
Options Common to both Solver Libraries
Additional parameters for Belos Solver/Preconditioners
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.
Time Integration Options
Physics Realm Options
As mentioned previously, :inpfile:`realms` is a YAML list data structure containing at least one Physics Realm Options entry that defines the computational domain (provided as an Exodus-II 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 and numerical stability |
|
Mesh transformation |
|
Mesh motion |
|
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 post-processing 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 |
|
Compute boundary layer statistics |
Common options
Equation Systems
Note
The variable in the :inpfile:`equation_systems` subsection are prefixed with
equation_systems.name
but only the variable name after the period should
appear in the input file.
Initial conditions
Boundary Conditions
All BC types require :inpfile:`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 sub-dictionary with the key
<type>_user_data:
that contains the parameters necessary to initialize a
specific BC type.
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
entrainment_method: {computed, specified}
total_pressure: {yes, no}
Wall Boundary Condition
The following input file snippet shows an example of using an ABL wall function at the terrain during ABL simulations. See 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 :inpfile:`gravity_vector_component` is an integer that specifies the component of the gravity vector, defined in :inpfile:`solution_options.gravity`, that should be used in the definition of the Monin-Obukhov length scale calculation. The entry :inpfile:`reference_temperature` is the reference temperature used in calculation of the Monin-Obukhov length scale.
When there is mesh motion involved the wall boundary velocity takes the value of the mesh_velocity along the part represented by :inpfile:`bc.target_name`. In such a scenario all information under :inpfile:`bc.wall_user_data` is rendered unused.
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 :inpfile:`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 :inpfile:`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 :inpfile:`periodic_user_data` section that specifies the search tolerance for locating node pairs.
Non-Conformal Boundary
Like the periodic BC, the parameter :inpfile:`bc.target_name` must be a list with exactly two entries that specify the boundary plane pair forming the non-conformal boundary.
- non_conformal_boundary_condition: bc_left
target_name: [surface_77, surface_7]
non_conformal_user_data:
expand_box_percentage: 10.0
Material Properties
Solution Options
Note
The documentation for this section is incomplete.
Mesh Transformation
Mesh Motion
Output Options
Restart Options
Time-step Control Options
Turbine specific input options
Actuator Turbine Model
actuator:
type: ActLineFAST
search_method: stk_kdtree
search_target_part: Unspecified-2-HEX
n_turbines_glob: 2
dry_run: False
debug: False
t_start: 0.0
simStart: init # init/trueRestart/restartDriverInitFAST
t_max: 5.0
n_every_checkpoint: 100
Turbine0:
procNo: 0
num_force_pts_blade: 50
num_force_pts_tower: 20
nacelle_cd: 1.0
nacelle_area: 1.0
air_density: 1.225
epsilon: [ 5.0, 5.0, 5.0 ]
turbine_base_pos: [ 0.0, 0.0, -90.0 ]
turbine_hub_pos: [ 0.0, 0.0, 0.0 ]
restart_filename: ""
FAST_input_filename: "Test01.fst"
turb_id: 1
turbine_name: machine_zero
Turbine1:
procNo: 0
num_force_pts_blade: 50
num_force_pts_tower: 20
nacelle_cd: 1.0
nacelle_area: 1.0
air_density: 1.225
epsilon: [ 5.0, 5.0, 5.0 ]
turbine_base_pos: [ 250.0, 0.0, -90.0 ]
turbine_hub_pos: [ 250.0, 0.0, 0.0 ]
restart_filename: ""
FAST_input_filename: "Test02.fst"
turb_id: 2
turbine_name: machine_one
Note
t_max
can only be set when OpenFAST is running from t=0s and simStart
is init
. t_max
can not be changed on a restart. OpenFAST will not be able to run beyond t_max
. Choose t_max
to be large enough to accomodate any possible future extensions of runs. One can change t_start
and t_end
to start and stop the simulation any number of times as long as t_end
<= t_max
.
Turbine specific input options
Fluid-Structure Interaction
Turbulence averaging
Note
The variable in the :inpfile:`turbulence_averaging` subsection are
prefixed with turbulence_averaging.name
but only the variable
name after the period should appear in the input file.
Data probes
Note
The variable in the :inpfile:`data_probes` subsection are prefixed
with data_probes.name
but only the variable name after the
period should appear in the input file.
Post-processing
Note
The variable in the :inpfile:`post_processing` subsection are prefixed with
post_processing.name
but only the variable name after the period should
appear in the input file.
ABL Forcing
Note
The variables in the :inpfile:`abl_forcing` subsection are
prefixed with abl_forcing.name
but only the variable
name after the period should appear in the input file.
Note
There are now two options in the following inputs.
The can be momentum
and/or temperature
.
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.