Home

Context Navigation

initialization_parameters

Timestamp:: Feb 24, 2021 3:04:01 PM (4 years ago)
Author:: wagner
Comment:: --

Legend:

: Unmodified
: Added
: Removed
: Modified

doc/app/initialization_parameters

-                      v486
+                      v487
 Number of grid points in x-direction.\\\\
 A value for this parameter must be assigned. Since the lower array bound in PALM starts with i = 0, the actual number of grid points is equal to '''nx+1'''. In case of cyclic boundary conditions along x, the domain size is ('''nx+1''')* [#dx dx].\\\\
 For parallel runs '''nx+1''' must be an integral multiple of the number of processors along x-direction (see [../d3par#npex npex]). If the fft-solver is used for calculating the Poisson equation (see [#psolver psolver]), it must be an integral multiple of the number of processors along y-direction, too (see [../d3par#npey npey]), due to data transposition restrictions.\\\\
+For parallel runs '''nx+1''' must be an integral multiple of the number of processors along x-direction (see [../runtime_parameters#npex npex]). If the fft-solver is used for calculating the Poisson equation (see [#psolver psolver]), it must be an integral multiple of the number of processors along y-direction, too (see [../runtime_parameters#npey npey]), due to data transposition restrictions.\\\\
 For coupled runs ([../examples/coupled see details])  the product of '''dx''' and '''nx'''  in both parameter files [../iofiles#PARIN PARIN] and [../iofiles#PARIN_O PARIN_O] has to be same (same model domain length in x-direction).
 }}}
 …
 Number of grid points in y-direction.\\\\
 A value for this parameter must be assigned. Since the lower array bound in PALM starts with j = 0, the actual number of grid points is equal to '''ny+1'''. In case of cyclic boundary conditions along y, the domain size is ('''ny+1''') * [#dy dy].\\\\
 For parallel runs '''ny+1''' must be an integral multiple of the number of processors along y-direction. (see [../d3par#npey npey]). If the fft-solver is used for calculating the Poisson equation (see [#psolver psolver]), it must be an integral multiple of the number of processors along x-direction, too (see [../d3par#npex npex]), due to data transposition restrictions.\\\\
+For parallel runs '''ny+1''' must be an integral multiple of the number of processors along y-direction. (see [../runtime_parameters#npey npey]). If the fft-solver is used for calculating the Poisson equation (see [#psolver psolver]), it must be an integral multiple of the number of processors along x-direction, too (see [../runtime_parameters#npex npex]), due to data transposition restrictions.\\\\
 For coupled runs ([../examples/coupled see details])  the product of '''dy''' and '''ny'''  in both parameter files [../iofiles#PARIN PARIN] and [../iofiles#PARIN_O PARIN_O] has to be same (same model domain length in y-direction).
 }}}
 …
 {{{#!td
 Time step limiting factor.\\\\
 In the model, the maximum allowed time step according to CFL and diffusion-criterion [../d3par#dt_max dt_max] is reduced by [#dt dt] = dt_max * '''cfl_factor''' in order to avoid stability problems which may arise in the vicinity of the maximum allowed time step. The condition ''0.0'' < '''cfl_factor''' < ''1.0'' applies.\\\\
+In the model, the maximum allowed time step according to CFL and diffusion-criterion [../runtime_parameters#dt_max dt_max] is reduced by [#dt dt] = dt_max * '''cfl_factor''' in order to avoid stability problems which may arise in the vicinity of the maximum allowed time step. The condition ''0.0'' < '''cfl_factor''' < ''1.0'' applies.\\\\
 The default value of '''cfl_factor''' depends on the [#timestep_scheme timestep_scheme] used:\\\\
 For the third order Runge-Kutta scheme it is '''cfl_factor''' = ''0.9.'', for the second-order Runge-Kutta scheme a value of ''0.8'' is applied.\\\\
 …
 {{{#!td
 Random number generator to be used for creating uniformly distributed random numbers.\\\\
 It is used if random perturbations are to be imposed on the velocity field or on the surface heat flux field (see [../d3par#create_disturbances create_disturbances] and [#random_heatflux random_heatflux]). By default, the "parallel" random number generator is used. \\\\
+It is used if random perturbations are to be imposed on the velocity field or on the surface heat flux field (see [../runtime_parameters#create_disturbances create_disturbances] and [#random_heatflux random_heatflux]). By default, the "parallel" random number generator is used. \\\\
 By setting ( '''random_generator''' = '' 'numerical-recipes' '') PALM provides exactly the same order of random numbers on all different machines and should be used in particular for comparison runs.\\\\
 By setting ( '''random_generator''' = '' 'random-parallel' '') a fully parallelized random number generator can be chosen. Like the default, this generator creates random numbers in a reproducible order. The parallel random number generator also provides ensemble run capability, which can be steered by specifying the parameter [#ensemble_member_nr ensemble_member_nr]\\\\
 …
       The scheme of Piacsek and Williams (1970, J. Comp. Phys., 6, 392-405) with central differences in the form C3 is used.\\\\
 '' 'bc-scheme' ''\\\\
       The Bott scheme modified by Chlond (1994, Mon. Wea. Rev., 122, 111-125). This is a conservative monotonous scheme with very small numerical diffusion and therefore very good conservation of scalar flow features. The scheme, however, is computationally very expensive both because it is expensive itself and because it does (so far) not allow specific code optimizations (e.g. cache optimization). Choice of this scheme forces the Euler time step scheme to be used for the scalar quantities. For output of horizontally averaged profiles of the resolved / total heat flux, [../d3par#data_output_pr data_output_pr] = '' 'w*theta*BC' '' / '' 'wthetaBC' '' should be used, instead of the standard profiles ('' 'w*theta*' '' and '' 'wtheta' '') because these are too inaccurate with this scheme. However, for subdomain analysis (see [#statistic_regions statistic_regions]) exactly the reverse holds: here '' 'w*theta*BC' '' and '' 'wthetaBC' '' show very large errors and should not be used.\\\\
+      The Bott scheme modified by Chlond (1994, Mon. Wea. Rev., 122, 111-125). This is a conservative monotonous scheme with very small numerical diffusion and therefore very good conservation of scalar flow features. The scheme, however, is computationally very expensive both because it is expensive itself and because it does (so far) not allow specific code optimizations (e.g. cache optimization). Choice of this scheme forces the Euler time step scheme to be used for the scalar quantities. For output of horizontally averaged profiles of the resolved / total heat flux, [../runtime_parameters#data_output_pr data_output_pr] = '' 'w*theta*BC' '' / '' 'wthetaBC' '' should be used, instead of the standard profiles ('' 'w*theta*' '' and '' 'wtheta' '') because these are too inaccurate with this scheme. However, for subdomain analysis (see [#statistic_regions statistic_regions]) exactly the reverse holds: here '' 'w*theta*BC' '' and '' 'wthetaBC' '' show very large errors and should not be used.\\\\
       This scheme is not allowed for non-cyclic lateral boundary conditions (see [#bc_lr bc_lr] and [#bc_ns bc_ns]) and requires that [#loop_optimization loop_optimization] = '' 'vector' '' is set.\\\\
 '' 'up-scheme' ''\\\\
 …
 In case of these non-cyclic lateral boundaries, a Dirichlet condition is used at the inflow for all quantities (initial vertical profiles - see [#initializing_actions initializing_actions] - are fixed during the run) except e, to which a Neumann (zero gradient) condition is applied. At the outflow, a radiation condition is used for all velocity components. A constant phase velocity is used, which is set to the maximum velocity allowed by the CFL criterion (i.e. for a Courant number of one).
 For scalars, a Neumann condition is used. For the perturbation pressure, Neumann conditions are assumed both at the inflow and at the outflow.\\\\
 In order to maintain a turbulent state of the flow, it may be necessary to continuously impose perturbations on the horizontal velocity field in the vicinity of the inflow throughout the whole run. This can be switched on using [../d3par#create_disturbances create_disturbances]. The horizontal range to which these perturbations are applied is controlled by the parameters [#inflow_disturbance_begin inflow_disturbance_begin] and [#inflow_disturbance_end inflow_disturbance_end]. The vertical range and the perturbation amplitude are given by [../d3par#disturbance_level_b disturbance_level_b], [../d3par#disturbance_level_t disturbance_level_t], and [../d3par#disturbance_amplitude disturbance_amplitude]. The time interval at which perturbations are to be imposed is set by [../d3par#dt_disturb dt_disturb]. Note that these inflow perturbances are added '''in addition''' to the standard perturbances that are activated with [../d3par#create_disturbances create_disturbances]. The standard perturbances can be deactivated by setting the d3par-parameter [../d3par#disturbance_energy_limit disturbance_energy_limit] = 0.0 .\\\\
+In order to maintain a turbulent state of the flow, it may be necessary to continuously impose perturbations on the horizontal velocity field in the vicinity of the inflow throughout the whole run. This can be switched on using [../runtime_parameters#create_disturbances create_disturbances]. The horizontal range to which these perturbations are applied is controlled by the parameters [#inflow_disturbance_begin inflow_disturbance_begin] and [#inflow_disturbance_end inflow_disturbance_end]. The vertical range and the perturbation amplitude are given by [../runtime_parameters#disturbance_level_b disturbance_level_b], [../runtime_parameters#disturbance_level_t disturbance_level_t], and [../runtime_parameters#disturbance_amplitude disturbance_amplitude]. The time interval at which perturbations are to be imposed is set by [../runtime_parameters#dt_disturb dt_disturb]. Note that these inflow perturbances are added '''in addition''' to the standard perturbances that are activated with [../runtime_parameters#create_disturbances create_disturbances]. The standard perturbances can be deactivated by setting the d3par-parameter [../runtime_parameters#disturbance_energy_limit disturbance_energy_limit] = 0.0 .\\\\
 In case of non-cyclic horizontal boundaries [#call_psolver_at_all_substeps call_psolver_at_all_substeps] = ''.T.'' should be used.\\\\
 …
 {{{#!td
 Lower limit of the horizontal range for which random perturbations are to be imposed on the horizontal velocity field (grid points).\\\\
 If non-cyclic lateral boundary conditions are used (see [#bc_lr bc_lr] or [#bc_ns bc_ns]), this parameter gives the grid point number (counted horizontally from the inflow) from which on perturbations are imposed on the horizontal velocity field. Perturbations must be switched on with parameter [../d3par#create_disturbances create_disturbances]. Note that these inflow perturbances are added '''in addition''' to the standard perturbances that are activated with [../d3par#create_disturbances create_disturbances].
+If non-cyclic lateral boundary conditions are used (see [#bc_lr bc_lr] or [#bc_ns bc_ns]), this parameter gives the grid point number (counted horizontally from the inflow) from which on perturbations are imposed on the horizontal velocity field. Perturbations must be switched on with parameter [../runtime_parameters#create_disturbances create_disturbances]. Note that these inflow perturbances are added '''in addition''' to the standard perturbances that are activated with [../runtime_parameters#create_disturbances create_disturbances].
 }}}
 |----------------
 …
 {{{#!td
 Upper limit of the horizontal range for which random perturbations are to be imposed on the horizontal velocity field (grid points).\\\\
 If non-cyclic lateral boundary conditions are used (see [#bc_lr bc_lr] or [#bc_ns bc_ns]), this parameter gives the grid point number (counted horizontally from the inflow) up to which perturbations are imposed on the horizontal velocity field. Perturbations must be switched on with parameter [../d3par#create_disturbances create_disturbances].
+If non-cyclic lateral boundary conditions are used (see [#bc_lr bc_lr] or [#bc_ns bc_ns]), this parameter gives the grid point number (counted horizontally from the inflow) up to which perturbations are imposed on the horizontal velocity field. Perturbations must be switched on with parameter [../runtime_parameters#create_disturbances create_disturbances].
 }}}
 |----------------
 …
 If '''dt''' is assigned a value, then the time step is fixed to this value throughout the whole run (whether it fulfills the time step criteria or not). However, changes are allowed for restart runs, because '''dt''' can also be used as a [../d3par run parameter].\\\\
 In case that the automatically calculated time step meets the condition\\\\
       '''dt''' < 0.00001 * [../d3par#dt_max dt_max] (with dt_max = 20.0)\\\\
+      '''dt''' < 0.00001 * [../runtime_parameters#dt_max dt_max] (with dt_max = 20.0)\\\\
 the simulation will be aborted. Such situations usually arise in case of any numerical problem / instability which causes a non-realistic increase of the wind speed.\\\\
 A small time step due to a large mean horizontal wind speed may be enlarged by using a coordinate transformation (see [#galilei_transformation galilei_transformation]), in order to spare CPU time.\\\\