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:

Listing 1 Sample Nalu input file for the Heat Conduction problem
# -*- 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 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 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 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 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 is tpetra the valid options are: gmres, biCgStab, cg. For hypre the valid options are hypre_boomerAMG and hypre_gmres.

Options Common to both Solver Libraries

linear_solvers.preconditioner

The type of preconditioner used.

When linear_solvers.type is tpetra the valid options are sgs, mt_sgs, muelu. For hypre the valid options are boomerAMG or none.

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 to muelu 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 time-integration 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 both time_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 is fixed 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 by restart.restart_time in the restart 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 second-order time integration scheme is activated. Default: no.

time_int.time_stepping_type

One of fixed or adaptive indicating whether a fixed time-stepping scheme or an adaptive timestepping scheme is used for simulations. See time_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 match name used in the realms section. Names listed here not found in realms list will trigger an error, while realms not included in this list but present in realms will not be initialized and silently ignored. This can cause the code to abort if the user attempts to access the specific realm in the transfers 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 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

equation_systems

Set of physics equations to be solved

initial_conditions

Initial conditions for the various fields

boundary_conditions

Boundary condition for the different fields

material_properties

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

solution_options

Discretization options

output

Solution output options (file, frequency, etc.)

restart

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

time_step_control

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

turbulence_averaging

Generate statistics for the flow field

post_processing

Extract integrated data from the simulation

solution_norm

Compare the solution error to a reference solution

data_probes

Extract data using probes

actuator

Model turbine blades/tower using actuator lines

abl_forcing

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 time-integration scheme used for this computational domain.

mesh

The name of the Exodus-II 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 higher-order mesh simulations. The default value is 1. When polynomial_order is greater than 1, the Realm has the capability to promote the mesh to higher-order 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 second-order time integration but the restart file was created using first-order 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 and balance_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 non-linear 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 the linear_systems entry, whereas the continuity equation system (pressure Poisson solve) should be solved using the linear solver definition corresponding to the tag solve_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 pre-defined equation system name that contains additional parameters governing the solution of this equation set. The predefined equation types are

Equation system

Description

LowMachEOM

Low-Mach 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.0e-5
  - TurbKineticEnergy:
      name: myTke
      max_iterations: 1
      convergence_tolerance: 1.0e-2
  - Enthalpy:
      name: myEnth
      max_iterations: 1
      convergence_tolerance: 1.0e-2

Initial conditions

initial_conditions

The initial_conditions sub-sections 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 pre-defined 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 the initial_conditions.target_name this section requires another entry value 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 BC

  • wall

  • symmetry

  • periodic

  • non_conformal – e.g., BC across sliding mesh interfaces

  • overset – 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 sub-dictionary 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 Monin-Obukhov length scale calculation. The entry reference_temperature is the reference temperature used in calculation of the Monin-Obukhov 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 pre-defined 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

Non-Conformal 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 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

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.6e-5
    - 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

  1. Specification for density using the ideal gas. The code determines what is reference and what is transported

    specifications:
       - name: density
         type: ideal_gas
    
  2. Specification of viscosity as a function of temperature

    - name: viscosity
      type: polynomial
      coefficient_declaration:
       - species_name: Air
         coefficients: [1.7894e-5, 273.11, 110.56]
    

    The species_name must correspond to the entry in reference quantitites to lookup molecular weight information.

  3. 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]
    
  4. Specification via mixture_fraction

    material_properties:
      target_name: block_1
    
      specifications:
        - name: density
          type: mixture_fraction
          primary_value: 0.163e-3
          secondary_value: 1.18e-3
        - name: viscosity
          type: mixture_fraction
          primary_value: 1.967e-4
          secondary_value: 1.85e-4
    

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 Exodus-II 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 wall-clock 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 the equation_systems.systems. Nalu will restart from the closest time available in the mesh to restart_time. The timesteps available in a restart file can be examined by looking at the time_whole variable using the ncdump utility.

Note

The restart database used for restarting a simulation is the mesh parameter. The restart_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 wall-clock 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.

Time-step Control Options

time_step_control

This optional section specifies the adpative time stepping parameters used if time_int.time_stepping_type is set to adaptive.

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: Unspecified-2-HEX

  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 point-particles along the line.

Turbulence averaging

turbulence_averaging

turbulence_averaging subsection defines the turbulence post-processing quantities and averaging procedures. A sample section is shown below

turbulence_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 sub-filter scale stress is computed. The default value is no. The sub-filter scale stress model is assumed to be of an eddy viscosity type and the turbulent viscosity computed by the turbulence model is used. The sub-filter scale kinetic energy is used to determine the isotropic component of the sub-filter stress. As described in the section Conservation of Momentum, the Yoshizawa model is used to compute the sub-filter kinetic energy when it is not transported.

turbulence_averaging.specifications.compute_temperature_sfs_flux

A boolean flag indicating whether the average sub-filter scale flux of temperature is computed. The default value is no. The sub-filter 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 q-criterion 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 below

data_probes:

  output_frequency: 100

  search_method: stk_octree
  search_tolerance: 1.0e-3
  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.

Post-processing

post_processing

post_processing subsection defines the different post-processign options. A sample section is shown below

post_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 post-processing. Possible values are:

Value

Description

surface

Post-processing of surface quantities

post_processing.physics

Physics to be post-processing. 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 post-processing

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. The abl_forcing option needs to be specified in the momentum and/or enthalpy 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 time-step.

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/over-relax 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.

Transfers

transfers

Transfers section describes the search and mapping operations to be performed between participating realms within a simulation.

Simulations

simulations

This is the top-level section that orchestrates the entire execution of Nalu.