# Models One essential part of a numerical simulation is to define the models and conditions for it. There are multiple features of Nassu that require some configuration like this. These configurations are gathered in the `models` field and define the behavior of the simulation in multiple ways. Some of the features available in it are: * Numerical models * Boundary conditions * Initialization * Devices and precision to use ```{note} For further details on theorical aspects of the models presented here, check the [theory documentation](../../../theory/index.md). ``` ## Numerical models When running a simulation, one of the most important aspects is the numerical models that are used. Nassu combines LBM with other models to achieve its capabilities and each model has its own configurations. ```yaml simulations: - name: example models: # Multiblock options multiblock: # Number of overlap nodes in Fine-to-coarse communication # Defaults to 1 overlap_F2C: 2 # Custom overlaps of F2C for specific levels # Use as [lvl_from]: overlap to use # Defaults to {} (no custom) custom_overlap_F2C: 1: 3 2: 3 5: 1 # Filter size for average of stress tensor in fine-to-coarse communication # Defaults to 0 (no filter) stress_filter_F2C: 1 # Large eddy simulation options LES: # Model to use (only Smagorinsky currently) model: Smagorinsky # Subgrid Smagorinsky constant sgs_cte: 0.17 # LBM options LBM: # Global force to use F: { x: 0, y: 0, z: 0 } # Collision operator # Options are: RBGK, RRBGK, HRRBGK coll_oper: RRBGK coll_oper_params: # Constant sigma to use for HRRBGK, between 0.95 and 1. # Defaults to 0.99 sigma_hrrbgk: 0.99 # Mode for HRRBGK # Options are: dynamic, constant # Defaults to constant mode_hrrbgk: dynamic # True to activate thermal model and variable theta thermal_model: true # Relaxation time (tau) value tau: 0.5000008125 # Velocity set # Options are: D2Q9 for 2D, D3Q15, D3Q19, D3Q27 for 3D vel_set: D3Q27 # Immersed boundary method options IBM: # Dirac delta to use # Options are: 3_points, 4_points # Defaults to 3_points dirac_delta: 3_points # For all IBM interpolation or spread kernels, the minimun value of dirac for the operation # to be done. # Use high value to avoid running IBM on domain borders or multiblock transitions # Use low value to allow for IBM to run everywhere # Defaults to 0.99 min_dirac_sum: 0.99 # Number of time steps to use for force accomodation # The force applied linearly increases from 0% to 100% in this interval # Defaults to 0 forces_accomodate_time: 500 # Limiter to force spreading on IBM iteration. This is the limit between two iterations. # A reasonable value is 1e-3 for limiting (force ~ rho*u^2, So u~0.03 yields this) # Defaults to 1000 (in practice, no limit) forces_spread_limit: 1e-3 # Wheter to reset forces between time steps or use the force from the previous # tims step as reference # Defaults to true reset_forces: true # IBM configurations for bodies body_cfgs: default: {} # Configuration name to reference building_cfg: # Number of iterations # Defaults to 5 n_iterations: 5 # Force factor to use for force spreading. # The force is multiplied by this factor before being applied # When `kinetic_energy_correction` is true, it's scaled to level, diving by 2**lvl # Defaults to 1 forces_factor: 1 # Use kinetic energy correction over the traditional IBM velocity correction. # Used for modeling of porous medium (to force a drag coefficient over a velocity) # It makes `forces_factor` be rescaled to the level. # Invalid to be used along wall model # Defaults to false kinetic_energy_correction: false # Model of constant force to apply in body. Defaults to null # (fields explained in `constant_force_cfg`) constant_model: null # Wall model to use wall_model: # Name of wall model # Availables one are: EqTBL, EqLog name: EqTBL # Reference distance for tangential velocity interpolation dist_ref: 2 # Shell distance for spreading forces dist_shell: 0.25 # Step to start applying wall model. Before this step # conventional IBM is applied # Defaults to 1000 start_step: 1000 # Parameters required by EqTBL params: # Roughness length z0: 0.0001 # Max error for TDMA TDMA_max_error: 5e-06 # Max iterations for TDMA TDMA_max_iters: 50 # Number of divisions in TDMA (max, min) # Must be an odd number TDMA_max_div: 25 TDMA_min_div: 21 # Target y+ for nearest wall point in TDMA discretization # defaults to 0.2 TDMA_yp_target: 0.2 terrain_cfg: n_iterations: 3 forces_factor: 1 wall_model: name: EqLog dist_ref: 2.5 dist_shell: 0.5 # Parameters required by EqLog params: z0: 0.0001 constant_force_cfg: n_iterations: 1 forces_factor: 0.12 constant_model: # Constant velocity to apply in body normal constant_velocity: 1e-2 # Tangential direction force factor. # 0 to not change tangential velocity, 1 to make tangential velocity zero tangential_force_factor: 0 # Use body normals to make force direction use_normal: false # Direction to apply force, in case normal is not used # Defaults to null direction_apply: [0, 1, -1] ``` ```{note} The configurations for these model requires an understanding of how the solver works under the hood. So be careful when changing these values from the guideline ones. ``` ## Boundary conditions For CFD simulations, boundary conditions (BC) deserve a very very special topic. They can be the difference between a great result and a simulation diverging. Here is how to configure the BCs for the simulations in Nassu ```yaml simulations: - name: example models: BC: # Periodic dimensions in the domain (x, y, z) periodic_dims: [false, false, false] # Wall model configurations WM_cfg: # Max error for TDMA TDMA_max_error: 5e-06 # Max iterations for TDMA TDMA_max_iters: 50 # Number of divisions in TDMA # Must be an odd number TDMA_max_div: 25 # Map of boundary conditions to use BC_map: # The boundary conditions are added from first to last # So if there is one BC that conflicts nodes and order with order, # The last one will be the one that stands - # Boundary condition name # Available ones are: # HWBB # RegularizedHWBB # VelocityBounceBack # UniformFlow # Neumann # RegularizedNeumannSlip # RegularizedNeumannOutlet BC: RegularizedNeumannOutlet # Order in which apply the BC # 0 are the first applied, then 1, then 2 and so on order: 2 # Position of the BC (x, y, z) # Options are: (N is the domain limit) # E: at (N, _, _) # W: at (0, _, _) # N: at (_, N, _) # S: at (_, 0, _) # F: at (_, _, N) # B: at (_, _, 0) # It's possible to combine these positions, as in NW: at (0, N, _) pos: E # Normal position to consider in BC # It points to outside the domain, so for a wall at the top (_, N, _) # you would use N # It's also possible to combine these directions, as in the position # Some BCs, such as UniformFlow, don't require a wall normal wall_normal: E # Kwargs for the boundary condition. Depends on the BC rho: 1.0 # Others BCs to apply - BC: RegularizedNeumannSlip order: 1 pos: F wall_normal: F - BC: RegularizedHWBB order: 1 pos: B wall_normal: B - BC: RegularizedNeumannSlip order: 0 pos: N wall_normal: N - BC: RegularizedNeumannSlip order: 0 pos: S wall_normal: S - BC: Neumann order: 0 # It's also possible to combine the positions and normals to # combine the limitations of each name pos: NF wall_normal: N - BC: Neumann order: 0 pos: SF wall_normal: S ``` For the boundary conditions, check the documentation on each one for what they apply and how. ### SEM One special and important BC is the SEM (Synthetic eddy method) that applies a velocity profile with synthetic eddies to produce turbulence in the inlet. It enforces this condition on all nodes at the start of the domain, so at x=0. The height is obligatory in z direction and the "width" in y direction. ```yaml simulations: - name: example models: # Synthetic eddy method configuration SEM: # Specifications for SEM eddies generation eddies: # Lengthscale to use, may specify different values for each dimension lengthscale: {x: 14, y: 14, z: 14} # Volume density of eddies (n_eddies=eddies_vol_density*(SEM_volume/eddy_volume)) eddies_vol_density: 15 # Seed for random numbers to generate the eddies seed_rand: 0 # All eddies are generated in this limit in yz domain (x is 2*lenghtscale.x) domain_limits_yz: start: [16, 0] end: [48, 96] profile: # Profile with velocity and R (rate od strain) for SEM csv_profile_data: "fixture/SEM/example/real_profile.csv" # Sums in z profile z_offset: 0 # K multiplication factor K: 1 # When z has variable dimension along y direction, it can be specified in this csv csv_y_height: "fixture/SEM/example/y_heights.csv" # Multiplier for profile length. # Scales Z (z*height_mul) for csv_profile_data and [y, z_height] for csv_y_height length_mul: 1 # Multiplier for velocity values. # Scales velocity values (ux*vel_height) for csv_profile_data # Scales Reynolds stress tensor (R*(height_mul^2)) for csv_profile_data vel_mul: 1 ``` ```{note} For more informations on SEM, check its specific documentation. ``` ## Initialization To initialize the simulation it's possible to start with a constant velocity and density field, load a custom field or start from a checkpoint. ```yaml simulations: - name: example models: initialization: # .vtm file to load fields from, it uses linear interpolation for refinement # The multiblock must have rho and u fields and at least the domain size # S field is generated using finite differences of U field # Defaults to None (no load from file, use constant field) vtm_filename: ./fixture/vtms/macrs72x48x24.vtm # For constant initialization # Rho initial value rho: 1 # Velocity initial value u: { x: 0, y: 0, z: 0 } checkpoint: load: # Start simulation from checkpoint. Defaults to False checkpoint_start: true # Reset simulation time step, start at 0 instead of checkpoint time step. # Defaults to false. reset_time_step: false # Path to folder to load checkpoint from. If not specified, tries to load # from the simulation output folder the last checkpoint saved # Defaults to null folderpath: null ``` ```{important} For checkpoint details, check the [data](data.md) section. ``` ## Devices and precision to use Nassu is configured to run in GPU devices, using [NVIDIA CUDA](https://developer.nvidia.com/cuda-toolkit) library. Some options are available currently for the setup of the devices. It's also required to specify the floating point precision to use for the simulation. ```yaml simulations: - name: example models: # Engine options engine: # Devices numbers to use # Defaults to none, devices are chosen automatically in ascending order devices_numbers: [0] # Number of devices to use # Defaults to one (no support for multidevices currently) n_devices: 1 # Engine to use # Options are: CUDA (previously we supported OpenCL too) name: CUDA # Numerical precision options precision: # The default precision, must be specified # Options are: single | double default: single # All options below are: single | double | default # Defaults to: default # Precision to perform calculations calculations: default # Precision to store macroscopics fields macroscopics: default # Precision to use for populations in shared memory populations: default ``` ```{note} The precision used for the populations impacts the block size that can be used, because it's allocated in the GPU shared memory, which is very limited. ``` ```{important} Currently there is no support for multidevices. ```