= Initialization parameters = [[TracNav(doc/app/partoc|nocollapse)]] ==== [#mode Mode] ==== ==== [#grid Grid] ==== ==== [#num Numerics] ==== ==== [#phys Physics] ==== ==== [#bc Boundary conditions] ==== ==== [#ini Initialization] ==== ==== [#topo Topography] ==== ==== [#canopy Canopy] ==== ==== [#others Others] ==== \\\\ NAMELIST group name: '''inipar'''\\ ---- [=#mode '''Mode:]\\ ||='''Parameter Name''' =||='''[../fortrantypes FORTRAN]\\[../fortrantypes Type]''' =||='''Default\\Value''' =||='''Explanation''' =|| |---------------- {{{#!td style="vertical-align:top;width: 150px" [=#cloud_droplets '''cloud_droplets'''] }}} {{{#!td style="vertical-align:top;width: 50px" L }}} {{{#!td style="vertical-align:top;width: 75px" .F. }}} {{{#!td Parameter to switch on usage of cloud droplets.\\\\ Cloud droplets require to use particles (i.e. the NAMELIST group [../parpar particles_par] has to be included in the parameter file). Then each particle is a representative for a certain number of droplets. The droplet features (number of droplets, initial radius, etc.) can be steered with the respective particle parameters (see e.g. [../parpar#radius radius]). The real number of initial droplets in a grid cell is equal to the initial number of droplets (defined by the particle source parameters [../parpar#pst pst], [../parpar#psl psl], [../parpar#psr psr], [../parpar#pss pss], [../parpar#psn psn], [../parpar#psb psb], [../parpar#pdx pdx], [../parpar#pdy pdy] and [../parpar#pdz pdz]) times the [../parpar#initial_weighting_factor initial_weighting_factor].\\\\ In case of using cloud droplets, the default condensation scheme in PALM cannot be used, i.e. [#cloud_physics cloud_physics] must be set ''.F.''. }}} |---------------- {{{#!td style="vertical-align:top" [=#cloud_physics '''cloud_physics'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter to switch on the condensation scheme.\\\\ For '''cloud_physics''' = ''.T.'', equations for the liquid water content and the liquid water potential temperature are solved instead of those for specific humidity and potential temperature. Note that a grid volume is assumed to be either completely saturated or completely unsaturated (0%-or-100%-scheme). A simple precipitation scheme can additionally be switched on with parameter [#precipitation precipitation]. Also cloud-top cooling by longwave radiation can be utilized (see [#radiation radiation]).\\\\ '''cloud_physics''' = ''.T.'' requires [#humidity humidity] = ''.T.''.\\\\ Detailed information about the condensation scheme is given in the description of the [[cloud physics module]] (pdf-file).\\\\ This condensation scheme is not allowed if cloud droplets are simulated explicitly (see [#cloud_droplets cloud_droplets]). }}} |---------------- {{{#!td style="vertical-align:top" [=#conserve_volume_flow '''conserve_volume_flow'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Conservation of volume flow in x- and y-direction.\\\\ In case of lateral cyclic boundary conditions (bc_lr = '' 'cyclic' '' and bc_ns = '' 'cyclic{{{'}}}'') '''conserve_volume_flow''' = ''.T.'' guarantees that the volume flow through the xz- and yz-cross-sections of the total model domain remains constant throughout the run depending on the chosen [#conserve_volume_flow_mode conserve_volume_flow_mode]. In case of non-cyclic lateral boundary conditions (bc_lr /= '' 'cyclic' '' or bc_ns /= '' 'cyclic{{{'}}}'') this option guarantees that the volume flow at the inflow boundary equals at each time step the volume flow at the outflow. \\\\ Note that '''conserve_volume_flow''' = ''.T.'' requires [#dp_external dp_external] = ''.F.''. }}} |---------------- {{{#!td style="vertical-align:top" [=#conserve_volume_flow_mode '''conserve_volume_flow_mode'''] }}} {{{#!td style="vertical-align:top" C*16 }}} {{{#!td style="vertical-align:top" 'default' }}} {{{#!td Modus of volume flow conservation.\\\\ The following values are allowed:\\\\ '' 'default' ''\\\\ Per default, PALM uses '' 'initial_profiles' ''. \\\\ '' 'initial_profiles' ''\\\\ The target volume flow is calculated at t=0 from the initial profiles of u and v. This option is also standard for non-cyclic lateral boundary conditions (bc_lr /= '' 'cyclic' '' or bc_ns /= '' 'cyclic{{{'}}}'') because the (spanwise averaged) inflow profiles do not vary with time and are identical with the initial profiles.\\\\ '' 'inflow_profile' ''\\\\ The target volume flow is calculated at every timestep from the inflow profile of u or v, respectively. This setting is only allowed for non-cyclic lateral boundary conditions (bc_lr /= '' 'cyclic' '' or bc_ns /= '' 'cyclic{{{'}}}''). '''This option is not implemented so far, because at this time (spanwise averaged) inflow profiles do not vary with time in the standard code.'''\\\\ '' 'bulk_velocity' ''\\\\ The target volume flow is calculated from a predefined bulk velocity (see [#u_bulk u_bulk] and [#v_bulk v_bulk]). This setting is only allowed for cyclic lateral boundary conditions .\\\\ Note that '''conserve_volume_flow_mode''' only comes into effect if [#conserve_volume_flow conserve_volume_flow] = ''.T.''. }}} |---------------- {{{#!td style="vertical-align:top" [=#coupling_start_time '''coupling_start_time'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Simulation time of precursor run.\\\\ Sets the time period a precursor run shall run uncoupled. This parameter is used to set up the precursor run control for atmosphere-ocean-coupled runs. It has to be set individually to the atmospheric / oceanic precursor run. The time in the data output will show negative values during the precursor run. See [[attachment:precursor_run_control.pdf|precursor run control documentation]] for further information. }}} |---------------- {{{#!td style="vertical-align:top" [=#dp_external '''dp_external'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td External pressure gradient switch.\\\\ This parameter is used to switch on/off an external pressure gradient as driving force. The external pressure gradient is controlled by the parameters [#dp_smooth dp_smooth], [#dp_level_b dp_level_b] and [#dpdxy dpdxy].\\\\ Note that '''dp_external''' = ''.T.'' requires [#conserve_volume_flow conserve_volume_flow] = ''.F.''. It is normally recommended to disable the Coriolis force by setting [#omega omega] = ''0.0''. }}} |---------------- {{{#!td style="vertical-align:top" [=#dp_smooth '''dp_smooth'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Vertically smooth the external pressure gradient using a sinusoidal smoothing function.\\\\ This parameter only applies if [#dp_external dp_external] = ''.T.''. It is useful in combination with [#dp_level_b dp_level_b] >> 0 to generate a non-accelerated boundary layer well below dp_level_b. }}} |---------------- {{{#!td style="vertical-align:top" [=#dp_level_b '''dp_level_b'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Lower limit of the vertical range for which the external pressure gradient is applied (in m).\\\\ This parameter only applies if [#dp_external dp_external] = ''.T.''. It must hold the condition zu(0) <= '''dp_level_b''' <= zu([#nz nz]). It can be used in combination with [#dp_smooth dp_smooth] = ''.T.'' to generate a non-accelerated boundary layer well below '''dp_level_b''' if '''dp_level_b''' >> 0.\\\\ Note that there is no upper limit of the vertical range because the external pressure gradient is always applied up to the top of the model domain. }}} |---------------- {{{#!td style="vertical-align:top" [=#dpdxy '''dpdxy'''] }}} {{{#!td style="vertical-align:top" R(2) }}} {{{#!td style="vertical-align:top" 2 * 0.0 }}} {{{#!td Values of the external pressure gradient applied in x- and y-direction, respectively (in Pa/m).\\\\ This parameter only applies if [#dp_external dp_external] = ''.T.''. It sets the pressure gradient values. Negative values mean an acceleration, positive values mean deceleration. For example, '''dpdxy''' = ''-0.0002, 0.0,'' drives the flow in positive x-direction. }}} |---------------- {{{#!td style="vertical-align:top" [=#e_init '''e_init'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Initial subgrid-scale TKE in m^2^s^-2^.\\\\ This option prescribes an initial subgrid-scale TKE from which the initial diffusion coefficients K,,m,, and K,,h,, will be calculated if '''e_init''' is positive. This option only has an effect if [#km_constant km_constant] is not set. }}} |---------------- {{{#!td style="vertical-align:top" [=#e_min '''e_min'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Minimum subgrid-scale TKE in m^2^s^-2^.\\\\ This option adds artificial viscosity to the flow by ensuring that the subgrid-scale TKE does not fall below the minimum threshold '''e_min'''. }}} |---------------- {{{#!td style="vertical-align:top" [=#galilei_transformation '''galilei_transformation'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Application of a Galilei-transformation to the coordinate system of the model.\\\\ With '''galilei_transformation''' = ''.T.,'' a so-called Galilei-transformation is switched on which ensures that the coordinate system of the model is moved along with the geostrophical wind. Alternatively, the model domain can be moved along with the averaged horizontal wind (see [#use_ug_for_galilei_tr use_ug_for_galilei_tr], this can and will naturally change in time). With this method, numerical inaccuracies of the Piascek - Williams - scheme (concerns in particular the momentum advection) are minimized. Beyond that, in the majority of cases the lower relative velocities in the moved system permit a larger time step ([#dt dt]). Switching the transformation on is only worthwhile if the geostrophical wind (ug, vg) and the averaged horizontal wind clearly deviate from the value 0. In each case, the distance the coordinate system has been moved is written to the file [../iofiles#RUN_CONTROL RUN_CONTROL].\\\\ Non-cyclic lateral boundary conditions (see [#bc_lr bc_lr] and [#bc_ns bc_ns]), the specification of a gestrophic wind that is not constant with height as well as e.g. stationary inhomogeneities at the bottom boundary do not allow the use of this transformation. }}} |---------------- {{{#!td style="vertical-align:top" [=#humidity '''humidity'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter to switch on the prognostic equation for specific humidity q.\\\\ The initial vertical profile of q can be set via parameters [#q_surface q_surface], [#q_vertical_gradient q_vertical_gradient] and [#q_vertical_gradient_level q_vertical_gradient_level]. Boundary conditions can be set via [#q_surface_initial_change q_surface_initial_change] and [#surface_waterflux surface_waterflux].\\\\ If the condensation scheme is switched on ([#cloud_physics cloud_physics] = ''.T.''), q becomes the total liquid water content (sum of specific humidity and liquid water content). }}} |---------------- {{{#!td style="vertical-align:top" [=#km_constant '''km_constant'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" variable (computed from TKE) }}} {{{#!td Constant eddy diffusivities are used (laminar simulations).\\\\ If this parameter is specified, both in the 1d and in the 3d-model constant values for the eddy diffusivities are used in space and time with K,,m,, = '''km_constant''' and K,,h,, = K,,m,, / [#prandtl_number prandtl_number]. The prognostic equation for the subgrid-scale TKE is switched off. Constant eddy diffusivities are only allowed with the Prandtl layer ([#prandtl_layer prandtl_layer]) switched off. }}} |---------------- {{{#!td style="vertical-align:top" [=#km_damp_max '''km_damp_max'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.5*([#dx dx] or [#dy dy]) }}} {{{#!td Maximum diffusivity used for filtering the velocity field in the vicinity of the outflow (in m^2^/s).\\\\ When using non-cyclic lateral boundaries (see [#bc_lr bc_lr] or [#bc_ns bc_ns]), a smoothing has to be applied to the velocity field in the vicinity of the outflow in order to suppress any reflections of outgoing disturbances. Smoothing is done by increasing the eddy diffusivity along the horizontal direction which is perpendicular to the outflow boundary. Only velocity components parallel to the outflow boundary are filtered (e.g. v and w, if the outflow is along x). Damping is applied from the bottom to the top of the domain.\\\\ The horizontal range of the smoothing is controlled by [#outflow_damping_width outflow_damping_width] which defines the number of gridpoints (counted from the outflow boundary) from where on the smoothing is applied. Starting from that point, the eddy diffusivity is linearly increased (from zero to its maximum value given by '''km_damp_max''') until half of the damping range width, from where it remains constant up to the outflow boundary. If at a certain grid point the eddy diffusivity calculated from the flow field is larger than as described above, it is used instead.\\\\ The default value of '''km_damp_max''' has been empirically proven to be sufficient. }}} |---------------- {{{#!td style="vertical-align:top" [=#ocean '''ocean'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter to switch on ocean runs.\\\\ By default PALM is configured to simulate atmospheric flows. However, starting from version 3.3, '''ocean''' = ''.T.'' allows simulation of ocean turbulent flows. Setting this switch has several effects:\\\\ * An additional prognostic equation for salinity is solved.[[BR]] * Potential temperature in buoyancy and stability-related terms is replaced by potential density.[[BR]] * Potential density is calculated from the equation of state for seawater after each timestep, using the algorithm proposed by Jackett et al. (2006, J. Atmos. Oceanic Technol., 23, 1709-1728).[[BR]] So far, only the initial hydrostatic pressure is entered into this equation.[[BR]] * z=0 (sea surface) is assumed at the model top (vertical grid index k=[#nzt nzt] on the w-grid), with negative values of z indicating the depth.[[BR]] * Initial profiles are constructed (e.g. from [#pt_vertical_gradient pt_vertical_gradient] / [#pt_vertical_gradient_level pt_vertical_gradient_level]) starting from the sea surface, using surface values given by [#pt_surface pt_surface], [#sa_surface sa_surface], [#ug_surface ug_surface], and [#vg_surface vg_surface].[[BR]] * Zero salinity flux is used as default boundary condition at the bottom of the sea.[[BR]] * If switched on, random perturbations are by default imposed to the upper model domain from zu(nzt*2/3) to zu(nzt-3).\\\\ Relevant parameters to be exclusively used for steering ocean runs are [#bc_sa_t bc_sa_t], [#bottom_salinityflux bottom_salinityflux], [#sa_surface sa_surface], [#sa_vertical_gradient sa_vertical_gradient], [#sa_vertical_gradient_level sa_vertical_gradient_level], and [#top_salinityflux top_salinityflux].\\\\ Section [[4.4.2]] gives an example for appropriate settings of these and other parameters neccessary for ocean runs.\\\\ '''ocean''' = ''.T.'' does not allow settings of [#timestep_scheme timestep_scheme] = '' 'leapfrog' '' or '' 'leapfrog+euler' '' as well as [#scalar_advec scalar_advec] = '' 'ups-scheme'.'' }}} |---------------- {{{#!td style="vertical-align:top" [=#passive_scalar '''passive_scalar'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter to switch on the prognostic equation for a passive scalar.\\\\ The initial vertical profile of ''s'' can be set via parameters [#s_surface s_surface], [#s_vertical_gradient s_vertical_gradient] and [#s_vertical_gradient_level s_vertical_gradient_level]. Boundary conditions can be set via [#s_surface_initial_change s_surface_initial_change] and [#surface_scalarflux surface_scalarflux].\\\\ '''Note:'''\\ With '''passive_scalar''' switched on, the simultaneous use of humidity (see [#humidity humidity]) is impossible. }}} |---------------- {{{#!td style="vertical-align:top" [=#precipitation '''precipitation'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter to switch on the precipitation scheme.\\\\ For precipitation processes PALM uses a simplified Kessler scheme. This scheme only considers the so-called autoconversion, that means the generation of rain water by coagulation of cloud drops among themselves. Precipitation begins and is immediately removed from the flow as soon as the liquid water content exceeds the critical value of 0.5 g/kg.\\\\ The precipitation rate and amount can be output by assigning the runtime parameter [../d3par#data_output data_output] = '' 'prr*' '' or '' 'pra*','' respectively. The time interval on which the precipitation amount is defined can be controlled via runtime parameter [../d3par#precipitation_amount_interval precipitation_amount_interval]. }}} |---------------- {{{#!td style="vertical-align:top" [=#radiation '''radiation'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter to switch on longwave radiation cooling at cloud-tops.\\\\ Long-wave radiation processes are parameterized by the effective emissivity, which considers only the absorption and emission of long-wave radiation at cloud droplets. The radiation scheme can be used only with [#cloud_physics cloud_physics] = ''.T.''. }}} |---------------- {{{#!td style="vertical-align:top" [=#random_heatflux '''random_heatflux'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter to impose random perturbations on the internal two-dimensional near surface heat flux field '''shf'''.\\\\ If a near surface heat flux is used as bottom boundary condition (see [#surface_heatflux surface_heatflux]), it is by default assumed to be horizontally homogeneous. Random perturbations can be imposed on the internal two-dimensional heat flux field '''shf''' by assigning '''random_heatflux''' = ''.T.''. The disturbed heat flux field is calculated by multiplying the values at each mesh point with a normally distributed random number with a mean value and standard deviation of 1. This is repeated after every timestep.\\\\ In case of a non-flat topography, assigning '''random_heatflux''' = ''.T.'' imposes random perturbations on the combined heat flux field '''shf''' composed of surface_heatflux at the bottom surface and [#wall_heatflux wall_heatflux](0) at the topography top face. }}} |---------------- {{{#!td style="vertical-align:top" [=#subs_vertical_gradient '''subs_vertical_gradient'''] }}} {{{#!td style="vertical-align:top" R(10) }}} {{{#!td style="vertical-align:top" 10 * 0.0 }}} {{{#!td Gradient(s) of the profile for the large scale subsidence/ascent velocity (in (m/s) / 100 m).\\\\ This gradient holds starting from the height level defined by [#subs_vertical_gradient_level subs_vertical_gradient_level] (precisely: for all uv levels k where zu(k) > subs_vertical_gradient_level, '''w_subs'''(k) is set: w_subs(k) = w_subs(k-1) + dzu(k) * '''subs_vertical_gradient''') up to the top boundary or up to the next height level defined by subs_vertical_gradient_level. A total of 10 different gradients for 11 height intervals (10 intervals if subs_vertical_gradient_level(1) = 0.0) can be assigned.\\\\ '''Example:'''\\\\ '''subs_vertical_gradient''' = ''-0.002,'' ''0.0,''\\ [#subs_vertical_gradient_level subs_vertical_gradient_level] = ''0.0,'' ''1000.0,''\\\\ That defines the subsidence/ascent profile to be linear up to z = 1000.0 m with a surface value of 0 m/s. Due to the gradient of -0.002 (m/s) / 100 m the subsidence velocity has a value of -0.02 m/s in z = 1000.0 m. For z > 1000.0 m up to the top boundary the gradient is 0.0 (m/s) / 100 m (it is assumed that the assigned height levels correspond with uv levels). This results in a subsidence velocity of -0.02 m/s at the top boundary.\\\\ With an appropriate construction of '''w_subs''' the height of the boundary layer ''z_i'' can be kept approximately constant.\\\\ '''Attention:'''\\ The large scale vertical motion is only applied to the prognostic equation for the scalar quantities (potential temperature, humidity if [#humidity humidity] = ''.T.'' or passive scalar if [#passive_scalar passive_scalar] = ''.T.'') because it cannot be applied to the momentum equations due to incompressibility. Thus, the model is not mass consistent. }}} |---------------- {{{#!td style="vertical-align:top" [=#subs_vertical_gradient_level '''subs_vertical_gradient_level'''] }}} {{{#!td style="vertical-align:top" R(10) }}} {{{#!td style="vertical-align:top" 10 * 0.0 }}} {{{#!td Height level from which on the gradient for the subsidence/ascent velocity defined by [#subs_vertical_gradient subs_vertical_gradient] is effective (in m).\\\\ The height levels have to be assigned in ascending order. The default values result in a profile which is zero everywhere regardless of the values of subs_vertical_gradient. For the piecewise construction of the subsidence/ascent velocity profile see [#subs_vertical_gradient subs_vertical_gradient]. }}} |---------------- {{{#!td style="vertical-align:top" [=#u_bulk '''u_bulk'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td u-component of the predefined bulk velocity (in m/s).\\\\ This parameter comes into effect if [#conserve_volume_flow conserve_volume_flow] = ''.T.'' and [#conserve_volume_flow_mode conserve_volume_flow_mode] = '' 'bulk_velocity'.'' }}} |---------------- {{{#!td style="vertical-align:top" [=#use_ug_for_galilei_tr '''use_ug_for_galilei_tr'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .T. }}} {{{#!td Switch to determine the translation velocity in case that a Galilean transformation is used.\\\\ In case of a Galilean transformation (see [#galilei_transformation galilei_transformation]), '''use_ug_for_galilei_tr''' = ''.T.'' ensures that the coordinate system is translated with the geostrophic windspeed.\\\\ Alternatively, with '''use_ug_for_galilei_tr''' = ''.F.,'' the geostrophic wind can be replaced as translation speed by the (volume) averaged velocity. However, in this case the user must be aware of fast growing gravity waves, so this choice is usually not recommended! }}} |---------------- {{{#!td style="vertical-align:top" [=#v_bulk '''v_bulk'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td v-component of the predefined bulk velocity (in m/s).\\\\ This parameter comes into effect if [#conserve_volume_flow conserve_volume_flow] = ''.T.'' and [#conserve_volume_flow_mode conserve_volume_flow_mode] = '' 'bulk_velocity'.'' }}} [[BR]] [=#grid '''Grid:]\\ ||='''Parameter Name''' =||='''[../fortrantypes FORTRAN]\\[../fortrantypes Type]''' =||='''Default\\Value''' =||='''Explanation''' =|| |---------------- {{{#!td style="vertical-align:top;width: 150px" [=#dx '''dx'''] }}} {{{#!td style="vertical-align:top;width: 50px" R }}} {{{#!td style="vertical-align:top;width: 75px" 1.0 }}} {{{#!td Horizontal grid spacing along the x-direction (in m).\\\\ Along x-direction only a constant grid spacing is allowed.\\\\ 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). }}} |---------------- {{{#!td style="vertical-align:top" [=#dy '''dy'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 1.0 }}} {{{#!td Horizontal grid spacing along the y-direction (in m).\\\\ Along y-direction only a constant grid spacing is allowed.\\\\ 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 style="vertical-align:top" [=#dz '''dz'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" }}} {{{#!td Vertical grid spacing (in m).\\\\ This parameter must be assigned by the user, because no default value is given.\\\\ By default, the model uses constant grid spacing along z-direction, but it can be stretched using the parameters [#dz_stretch_level dz_stretch_level] and [#dz_stretch_factor dz_stretch_factor]. In case of stretching, a maximum allowed grid spacing can be given by [#dz_max dz_max].\\\\ Assuming a constant '''dz''', the scalar levels (zu) are calculated directly by:\\\\ zu(0) = - '''dz''' * 0.5\\\\ zu(1) = '''dz''' * 0.5\\\\ The w-levels lie half between them:\\\\ zw(k) = ( zu(k) + zu(k+1) ) * 0.5 }}} |---------------- {{{#!td style="vertical-align:top" [=#dz_max '''dz_max'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 9999999.9 }}} {{{#!td Allowed maximum vertical grid spacing (in m).\\\\ If the vertical grid is stretched (see [#dz_stretch_factor dz_stretch_factor] and [#dz_stretch_level dz_stretch_level]), '''dz_max''' can be used to limit the vertical grid spacing. }}} |---------------- {{{#!td style="vertical-align:top" [=#dz_stretch_factor '''dz_stretch_factor'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 1.08 }}} {{{#!td Stretch factor for a vertically stretched grid (see [#dz_stretch_level dz_stretch_level]).\\\\ The stretch factor should not exceed a value of approx. ''1.10 - 1.12'', otherwise the discretization errors due to the stretched grid are not negligible any more. (refer Kalnay de Rivas) }}} |---------------- {{{#!td style="vertical-align:top" [=#dz_stretch_level '''dz_stretch_level'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 100000.0 }}} {{{#!td Height level above/below which the grid is to be stretched vertically (in m).\\\\ For [#ocean ocean] = ''.F.,'' '''dz_stretch_level''' is the height level (in m) above which the grid is to be stretched vertically. The vertical grid spacings [#dz dz] above this level are calculated as\\\\ dz(k+1) = dz(k) * [#dz_stretch_factor dz_stretch_factor]\\\\ and used as spacings for the scalar levels (zu). The w-levels are then defined as:\\\\ zw(k) = ( zu(k) + zu(k+1) ) * 0.5.\\\\ For [#ocean ocean] = ''.T.,'' '''dz_stretch_level''' is the height level (in m, negative) below which the grid is to be stretched vertically. The vertical grid spacings [#dz dz] below this level are calculated correspondingly as\\\\ dz(k-1) = dz(k) * [#dz_stretch_factor dz_stretch_factor]. }}} |---------------- {{{#!td style="vertical-align:top" [=#grid_matching '''grid_matching'''] }}} {{{#!td style="vertical-align:top" C*6 }}} {{{#!td style="vertical-align:top" 'strict' }}} {{{#!td Variable to adjust the subdomain sizes in parallel runs.\\\\ For '''grid_matching''' = '' 'strict' '', the subdomains are forced to have an identical size on all processors. In this case the processor numbers in the respective directions of the virtual processor net must fulfill certain divisor conditions concerning the grid point numbers in the three directions (see [#nx nx], [#ny ny] and [#nz nz]). Advantage of this method is that all PEs bear the same computational load.\\\\ There is no such restriction by default, because then smaller subdomains are allowed on those processors which form the right and/or north boundary of the virtual processor grid. On all other processors the subdomains are of same size. Whether smaller subdomains are actually used, depends on the number of processors and the grid point numbers used. Information about the respective settings are given in file [../iofiles#RUN_CONTROL RUN_CONTROL].\\\\ When using a multi-grid method for solving the Poisson equation (see [#psolver psolver]) only '''grid_matching''' = '' 'strict' '' is allowed.\\\\ '''Note:'''\\ In some cases for small processor numbers there may be a very bad load balancing among the processors which may reduce the performance of the code. }}} |---------------- {{{#!td style="vertical-align:top" [=#nx '''nx'''] }}} {{{#!td style="vertical-align:top" I }}} {{{#!td style="vertical-align:top" }}} {{{#!td 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, in case of [#grid_matching grid_matching] = '' 'strict','' '''nx+1''' must be an integral multiple of the processor numbers (see [../d3par#npex npex] and [../d3par#npey npey]) along x- as well as along y-direction (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). }}} |---------------- {{{#!td style="vertical-align:top" [=#ny '''ny'''] }}} {{{#!td style="vertical-align:top" I }}} {{{#!td style="vertical-align:top" }}} {{{#!td 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, in case of [#grid_matching grid_matching] = '' 'strict','' '''ny+1''' must be an integral multiple of the processor numbers (see [../d3par#npex npex] and [../d3par#npey npey]) along y- as well as along x-direction (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 style="vertical-align:top" [=#nz '''nz'''] }}} {{{#!td style="vertical-align:top" I }}} {{{#!td style="vertical-align:top" }}} {{{#!td Number of grid points in z-direction.\\\\ A value for this parameter must be assigned. Since the lower array bound in PALM starts with k = 0 and since one additional grid point is added at the top boundary (k = '''nz+1'''), the actual number of grid points is '''nz+2'''. However, the prognostic equations are only solved up to '''nz''' (u, v) or up to '''nz-1''' (w, scalar quantities). The top boundary for u and v is at k = '''nz+1''' (u, v) while at k = '''nz''' for all other quantities.\\\\ For parallel runs, in case of [#grid_matching grid_matching] = '' 'strict','' '''nz''' must be an integral multiple of the number of processors in x-direction (due to data transposition restrictions). }}} |---------------- {{{#!td style="vertical-align:top" [=#nz_do3d '''nz_do3d'''] }}} {{{#!td style="vertical-align:top" I }}} {{{#!td style="vertical-align:top" nz+1 }}} {{{#!td Limits the output of 3d volume data along the vertical direction (grid point index k).\\\\ By default, data for all grid points along z are output. The parameter '''nz_do3d''' can be used to limit the output up to a certain vertical grid point (e.g. in order to reduce the amount of output data). It affects all output of volume data ("normal" output to file, see [../d3par#data_output data_output], as well as output for '''dvrp'''-software, see [../d3par#mode_dvrp mode_dvrp]). }}} [[BR]] [=#num '''Numerics:]\\ ||='''Parameter Name''' =||='''[../fortrantypes FORTRAN]\\[../fortrantypes Type]''' =||='''Default\\Value''' =||='''Explanation''' =|| |---------------- {{{#!td style="vertical-align:top;width: 150px" [=#call_psolver_at_all_substeps '''call_psolver_at_all_substeps'''] }}} {{{#!td style="vertical-align:top;width: 50px" L }}} {{{#!td style="vertical-align:top;width: 75px" ''.T.'' }}} {{{#!td Switch to steer the call of the pressure solver.\\\\ In order to speed-up performance, the Poisson equation for perturbation pressure (see [#psolver psolver]) can be called only at the last substep of multistep Runge-Kutta timestep schemes (see [#timestep_scheme timestep_scheme]) by setting '''call_psolver_at_all_substeps''' = ''.F.''. In many cases, this sufficiently reduces the divergence of the velocity field. Nevertheless, small-scale ripples (2-delta-x) may occur. In this case and in case of non-cyclic lateral boundary conditions, the default value '''call_psolver_at_all_substeps''' = ''.T.'' should be used. }}} |---------------- {{{#!td style="vertical-align:top" [=#cfl_factor '''cfl_factor'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.1, 0.8 or 0.9 (see right) }}} {{{#!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 timestep. 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.''\\\\ In case of the leapfrog scheme a quite restrictive value of '''cfl_factor''' = ''0.1'' is used because for larger values the velocity divergence significantly effects the accuracy of the model results. Possibly larger values may be used with the leapfrog scheme but these are to be determined by appropriate test runs.\\\\ The default value for the Euler scheme is '''cfl_factor''' = ''0.8.'' }}} |---------------- {{{#!td style="vertical-align:top;width: 150px" [=#collective_wait '''collective_wait'''] }}} {{{#!td style="vertical-align:top;width: 50px" L }}} {{{#!td style="vertical-align:top;width: 75px" see right }}} {{{#!td Set barriers in front of collective MPI operations.\\\\ Depending on the communication network in use, setting of barriers (MPI_BARRIER) in front of collective MPI operations (MPI_ALLTOALL, MPI_ALLREDUCE) may speedup the code, e.g. by a few percent on SGI-ICE-systems with Infiniband fat tree. Therefore, {{{collective_wait}}} is {{{.TRUE.}}} by default on SGI-systems (if hostname(3:5) = "{{{sgi}}}", given with '''mrun'''-option {{{-h}}}), but {{{.FALSE.}}} on all other systems. }}} |---------------- {{{#!td style="vertical-align:top" [=#cycle_mg '''cycle_mg'''] }}} {{{#!td style="vertical-align:top" C*1 }}} {{{#!td style="vertical-align:top" 'w' }}} {{{#!td Type of cycle to be used with the multi-grid method.\\\\ This parameter determines which type of cycle is applied in the multi-grid method used for solving the Poisson equation for perturbation pressure (see [#psolver psolver]). It defines in which way it is switched between the fine and coarse grids. So-called v- and w-cycles are realized (i.e. '''cycle_mg''' may be assigned the values '' 'v' '' or '' 'w' ''). The computational cost of w-cycles is much higher than that of v-cycles, however, w-cycles give a much better convergence. }}} |---------------- {{{#!td style="vertical-align:top" [=#fft_method '''fft_method'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'system-specific' }}} {{{#!td FFT-method to be used.\\\\ The fast fourier transformation (FFT) is used for solving the perturbation pressure equation with a direct method (see [#psolver psolver]) and for calculating power spectra (see [../packages optional software packages]).\\\\ By default, system-specific, optimized routines from external vendor libraries are used. However, these are available only on certain computers and there are more or less severe restrictions concerning the number of gridpoints to be used with them.\\\\ There are two other PALM internal methods available on every machine (their respective source code is part of the PALM source code):\\\\ 1.: The '''Temperton'''-method from Clive Temperton (ECWMF) which is computationally very fast and switched on with '''fft_method''' = '' 'temperton-algorithm'.'' The number of horizontal gridpoints ([#nx nx]+1, [#ny ny]+1) to be used with this method must be composed of prime factors 2, 3 and 5.\\\\ 2.: The '''Singleton'''-method which is very slow but has no restrictions concerning the number of gridpoints to be used with, switched on with '''fft_method''' = '' 'singleton-algorithm'.'' }}} |---------------- {{{#!td style="vertical-align:top" [=#long_filter_factor '''long_filter_factor'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Filter factor for the so-called Long-filter.\\\\ This filter very efficiently eliminates 2-delta-waves sometimes caused by the upstream-spline scheme (see Mahrer and Pielke, 1978: Mon. Wea. Rev., 106, 818-830). It works in all three directions in space. A value of '''long_filter_factor''' = ''0.01'' sufficiently removes the small-scale waves without affecting the longer waves.\\\\ By default, the filter is switched off (= ''0.0''). It is exclusively applied to the tendencies calculated by the upstream-spline scheme (see [#momentum_advec momentum_advec] and [#scalar_advec scalar_advec]), not to the prognostic variables themselves. At the bottom and top boundary of the model domain the filter effect for vertical 2-delta-waves is reduced. There, the amplitude of these waves is only reduced by approx. 50%, otherwise by nearly 100%.\\\\ Filter factors with values > ''0.01'' also reduce the amplitudes of waves with wavelengths longer than 2-delta (see the paper by Mahrer and Pielke, quoted above). }}} |---------------- {{{#!td style="vertical-align:top" [=#loop_optimization '''loop_optimization'''] }}} {{{#!td style="vertical-align:top" C*16 }}} {{{#!td style="vertical-align:top" see right }}} {{{#!td Method used to optimize loops for solving the prognostic equations.\\\\ By default, the optimization method depends on the host on which PALM is running. On machines with vector-type CPUs, single 3d-loops are used to calculate each tendency term of each prognostic equation, while on all other machines, all prognostic equations are solved within one big loop over the two horizontal indices {{{i}}} and {{{j}}} (giving a good cache uitilization).\\\\ The default behaviour can be changed by setting either '''loop_optimization''' = '' 'vector' '' or '''loop_optimization''' = '' 'cache'.'' }}} |---------------- {{{#!td style="vertical-align:top" [=#mg_cycles '''mg_cycles'''] }}} {{{#!td style="vertical-align:top" I }}} {{{#!td style="vertical-align:top" -1 }}} {{{#!td Number of cycles to be used with the multi-grid scheme.\\\\ This parameter determines the number of cycles to be carried out in the multi-grid method used for solving the Poisson equation for perturbation pressure (see [#psolver psolver]). The type of the cycles can be set with [#cycle_mg cycle_mg].\\\\ By default ('''mg_cyles''' = -''1''), the number of cycles depends on the requested accuracy of the scheme (see [#residual_limit residual_limit]) and may vary from time step to time step. In this case, the CPU time for a run will be difficult to estimate, since it heavily depends on the total number of the cycles to be carried out.\\\\ By assigning '''mg_cycles''' a value (>= ''1''), the number of cycles can be fixed so that the CPU time can be clearly estimated.\\\\ '''Note:'''\\ When using a fixed number of cycles, the user must examine the local file [../iofiles#RUN_CONTROL RUN_CONTROL] regularly to check whether the divergence of the velocity field is sufficiently reduced by the pressure solver. It should be reduced at least by two orders of magnitude. For cyclic boundary conditions along both horizontal directions (see [#bc_lr bc_lr] and [#bc_ns bc_ns]) '''mg_cycles''' = ''2'' is typically a good choice, for non-cyclic lateral boundary conditions '''mg_cycles''' = ''4'' may be sufficient. }}} |---------------- {{{#!td style="vertical-align:top" [=#mg_switch_to_pe0_level '''mg_switch_to_pe0_level'''] }}} {{{#!td style="vertical-align:top" I }}} {{{#!td style="vertical-align:top" }}} {{{#!td Grid level at which data shall be gathered on PE0.\\\\ In case of a run using several PEs and the multigrid method for solving the Poisson equation for perturbation pressure (see [#psolver psolver]), the value of this parameter defines on which grid level the data are gathered on PE0 in order to allow for a further coarsening of the grid. The finest grid defines the largest grid level. By default, the gathering level is determined automatically and displayed in file [../iofiles#RUN_CONTROL RUN_CONTROL]. It is only possible to gather data from a level larger than the one determined automatically. A test run may be neccessary to determine this level.\\\\ Setting of '''mg_switch_to_pe0_level''' = -''1'' prevents that data are collected on PE0 at all, i.e. coarsening of grids is limited by the subdomains. }}} |---------------- {{{#!td style="vertical-align:top" [=#momentum_advec '''momentum_advec'''] }}} {{{#!td style="vertical-align:top" C*10 }}} {{{#!td style="vertical-align:top" 'ws-scheme' }}} {{{#!td Advection scheme to be used for the momentum equations.\\\\ The user can choose between the following schemes:\\\\ '' 'ws-scheme' ''\\\\ The 5 th order upwind scheme of Wicker and Skamarock (2002, Mon. Wea. Rev, 130, 2088-2097) is used. The dispersion error is much smaller than the dispersion error of 'pw-scheme'. The 5th order schemes implies a small numerical dissipation that stabilized the solution. To assure a stable numerical solution the time integration has to be carry out with [#timestep_scheme timestep_scheme] = 'runge-kutta-3'. This scheme is based on a formultion of the advection term in flux form, which requires a vanishing divergence of the flow field, else a stable numerical solution is not given. So [#call_psolver_at_all_substeps call_psolver_at_all_substeps] = 'True' has to be used. When [#psolver psolver] = 'multigrid' the [#residual_limit residual_limit] should be smaller than 1.0E-6 for a sufficient reduction of the divergences. For the moment the scheme can only be used in conjunction with [#topography topography] = 'flat'. So far [#bc_lr bc_lr] /= 'cyclic' or [#bc_ns bc_ns] /= 'cyclic' are not allowed with [#loop_optimization loop_optimization] = 'vector' in combination with 'ws-scheme'. Note: Due to the larger stencil of this scheme vertical grid stretching should be handled with care.\\\\ '' 'pw-scheme' ''\\\\ The scheme of Piascek and Williams (1970, J. Comp. Phys., 6, 392-405) with central differences in the form C3 is used. If intermediate Euler-timesteps are carried out in case of [#timestep_scheme timestep_scheme] = '' 'leapfrog+euler' '' the advection scheme is - for the Euler-timestep - automatically switched to an upstream-scheme.\\\\ '' 'ups-scheme' ''\\\\ The upstream-spline scheme is used (see Mahrer and Pielke, 1978: Mon. Wea. Rev., 106, 818-830). In opposite to the Piascek-Williams scheme, this is characterized by much better numerical features (less numerical diffusion, better preservation of flow structures, e.g. vortices), but computationally it is much more expensive. In addition, the use of the Euler-timestep scheme is mandatory ([#timestep_scheme timestep_scheme] = '' 'euler' ''), i.e. the timestep accuracy is only of first order. For this reason the advection of scalar variables (see [#scalar_advec scalar_advec]) should then also be carried out with the upstream-spline scheme, because otherwise the scalar variables would be subject to large numerical diffusion due to the upstream scheme.\\\\ Since the cubic splines used tend to overshoot under certain circumstances, this effect must be adjusted by suitable filtering and smoothing (see [#long_filter_factor long_filter_factor]). This is always neccessary for runs with stable stratification, even if this stratification appears only in parts of the model domain.\\\\ With stable stratification the upstream-spline scheme also produces gravity waves with large amplitude, which must be suitably damped (see [../inipar#rayleigh_damping_factor rayleigh_damping_factor]).\\\\ '''Important:'''\\ The upstream-spline scheme is not implemented for humidity and passive scalars (see [#humidity humidity] and [#passive_scalar passive_scalar]) and requires the use of a 2d-domain-decomposition. The last conditions severely restricts code optimization on several machines leading to very long execution times! The scheme is also not allowed for non-cyclic lateral boundary conditions (see [#bc_lr bc_lr] and [#bc_ns bc_ns]). }}} |---------------- {{{#!td style="vertical-align:top" [=#ngsrb '''ngsrb'''] }}} {{{#!td style="vertical-align:top" I }}} {{{#!td style="vertical-align:top" 2 }}} {{{#!td Number of Gauss-Seidel iterations to be carried out on each grid level of the multigrid Poisson solver.\\\\ In case of using the multigrid method for solving the Poisson equation for perturbation pressure (see [#psolver psolver]), this parameter defines the number of Gauss-Seidel iterations to be carried out on each grid level. High numbers give better convergence. The dafault value of ''2'' reduces the divergence of the preliminary velocity field by about 1-2 orders of magnitude, which is sufficient in most cases. The value of '''ngsrb''' has a significant effect on the cpu requirement of the run. }}} |---------------- {{{#!td style="vertical-align:top" [=#nsor '''nsor'''] }}} {{{#!td style="vertical-align:top" I }}} {{{#!td style="vertical-align:top" 20 }}} {{{#!td Number of iterations to be used with the SOR-scheme.\\\\ This parameter is only effective if the SOR-scheme is selected as pressure solver ([#psolver psolver] = '' 'sor' ''). The number of iterations necessary for a sufficient convergence of the scheme depends on the grid point numbers and is to be determined by appropriate test runs (the default value will not at all be sufficient for larger grid point numbers). The number of iterations used for the first call of the SOR-scheme (t = 0) is determined via the parameter [#nsor_ini nsor_ini]. }}} |---------------- {{{#!td style="vertical-align:top" [=#nsor_ini '''nsor_ini'''] }}} {{{#!td style="vertical-align:top" I }}} {{{#!td style="vertical-align:top" 100 }}} {{{#!td Initial number of iterations with the SOR algorithm.\\\\ This parameter is only effective if the SOR algorithm was selected as the pressure solver scheme ([#psolver psolver] = '' 'sor' '') and specifies the number of initial iterations of the SOR scheme (at t = 0). The number of subsequent iterations at the following timesteps is determined with the parameter [#nsor nsor]. Usually nsor < '''nsor_ini''', since in each case subsequent calls to [#psolver psolver] use the solution of the previous call as initial value. Suitable test runs should determine whether sufficient convergence of the solution is obtained with the default value and if necessary the value of '''nsor_ini''' should be changed. }}} |---------------- {{{#!td style="vertical-align:top" [=#omega_sor '''omega_sor'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 1.8 }}} {{{#!td Convergence factor to be used with the the SOR-scheme.\\\\ If the SOR-scheme is selected ([#psolver psolver] = '' 'sor' ''), this parameter determines the value of the convergence factor, where ''1.0'' <= '''omega_sor''' < ''2.0.'' The optimum value of '''omega_sor''' depends on the number of grid points along the different directions in space. For non-equidistant grids it can only be determined by appropriate test runs. }}} |---------------- {{{#!td style="vertical-align:top" [=#psolver '''psolver'''] }}} {{{#!td style="vertical-align:top" C*10 }}} {{{#!td style="vertical-align:top" 'poisfft' }}} {{{#!td Scheme to be used to solve the Poisson equation for the perturbation pressure.\\\\ The user can choose between the following schemes:\\\\ '' 'poisfft' ''\\\\ Direct method using FFT along x and y, solution of a tridiagonal matrix along z, and backward FFT (see Siano, institute reports, volume 54). The FFT routines to be used can be determined via the initialization parameter [#fft_method fft_method].\\ This solver is specially optimized for 1d domain decompositions. Vectorization is optimized for domain decompositions along x only.\\\\ '' 'poisfft_hybrid' ''\\\\ Direct method using FFT along x and y, solution of a tridiagonal matrix along z, and backward FFT (see Siano, institute reports, volume 54). The FFT routines to be used can be determined via the initialization parameter [#fft_method fft_method].\\ This solver is specially optimized for 1d domain decompositions. Vectorization is optimized for domain decompositions along x only.\\\\ '' 'multigrid' ''\\\\ Multi-grid scheme (see [[Diplomarbeit J. Uhlenbrock]], in German only). v- and w-cycles (see [#cycle_mg cycle_mg]) are implemented. The convergence of the iterative scheme can be steered by the number of v-/w-cycles to be carried out for each call of the scheme ([#mg_cycles mg_cycles]) and by the number of Gauss-Seidel iterations (see [#ngsrb ngsrb]) to be carried out on each grid level. Instead the requested accuracy can be given via [#residual_limit residual_limit]. This is the default! The smaller this limit is, the more cycles have to be carried out in this case and the number of cycles may vary from timestep to timestep.\\\\ If [#mg_cycles mg_cycles] is set to its optimal value, the computing time of the multi-grid scheme amounts approximately to that of the direct solver '' 'poisfft','' as long as the number of grid points in the three directions of space corresponds to a power-of-two (2^n^) where ''n'' >= 5 must hold. With large ''n'', the multi-grid scheme can even be faster than the direct solver (although its accuracy is several orders of magnitude worse, but this does not affect the accuracy of the simulation). Nevertheless, the user should always carry out some test runs in order to find out the optimum value for [#mg_cycles mg_cycles], because the CPU time of a run very critically depends on this parameter.\\\\ This scheme requires that the number of grid points of the subdomains (or of the total domain, if only one PE is uesd) along each of the directions can at least be devided once by 2 without rest.\\\\ With parallel runs, starting from a certain grid level the data of the subdomains are possibly gathered on PE0 in order to allow for a further coarsening of the grid. The grid level for gathering can be manually set by [#mg_switch_to_pe0_level mg_switch_to_pe0_level].\\ Using this procedure requires the subdomains to be of identical size (see [#grid_matching grid_matching]).\\\\ '' 'sor' ''\\\\ Successive over relaxation method (SOR). The convergence of this iterative scheme is steered with the parameters [#omega_sor omega_sor], [#nsor_ini nsor_ini] and [#nsor nsor].\\ Compared to the direct method and the multi-grid method, this scheme needs substantially more computing time. It should only be used for test runs, e.g. to compare results with the other pressure solver methods.\\\\ In case of using a multistep Runge-Kutta timestep scheme (see [#timestep_scheme timestep_scheme]), the Poisson equation is by default solved after each of the substeps. In order to speed-up performance, the Poisson equation may be solved only for the last substep (see [#call_psolver_at_all_substeps call_psolver_at_all_substeps]). }}} |---------------- {{{#!td style="vertical-align:top" [=#pt_reference '''pt_reference'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" use horizontal average as reference }}} {{{#!td Reference temperature to be used in all buoyancy terms (in K).\\\\ By default, the instantaneous horizontal average over the total model domain is used.\\\\ '''Attention:'''\\ In case of ocean runs (see [#ocean ocean]), always a reference temperature is used in the buoyancy terms with a default value of '''pt_reference''' = [#pt_surface pt_surface]. }}} |---------------- {{{#!td style="vertical-align:top" [=#random_generator '''random_generator'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'numerical\\recipes' }}} {{{#!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 "Numerical Recipes" random number generator is used. This one provides exactly the same order of random numbers on all different machines and should be used in particular for comparison runs.\\\\ Besides, a system-specific generator is available ( '''random_generator''' = '' 'system-specific' '') which should particularly be used for runs on vector parallel computers (NEC), because the default generator cannot be vectorized and therefore significantly drops down the code performance on these machines.\\\\ '''Note:'''\\ Results from two otherwise identical model runs will not be comparable one-to-one if they used different random number generators. }}} |---------------- {{{#!td style="vertical-align:top" [=#rayleigh_damping_factor '''rayleigh_damping_factor'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 or 0.01 }}} {{{#!td Factor for Rayleigh damping.\\\\ A so-called Rayleigh damping is applied to all prognostic variables if a non-zero value is assigned to '''rayleigh_damping_factor'''. If switched on, variables are forced towards the value of their respective basic states (e.g. the geostrophic wind). The intensity of damping is controlled by the value the '''rayleigh_damping_factor''' is assigned to. The damping starts weakly at a height defined by [#rayleigh_damping_height rayleigh_damping_height] and rises according to a sin^2^-function to its maximum value at the top (ocean: bottom) boundary.\\\\ This method effectively damps gravity waves, caused by boundary layer convection, which may spread out vertically in the inversion layer and which are reflected at the top (ocean: bottom) boundary. This particularly happens with the upstream-spline scheme switched on (see [#momentum_advec momentum_advec] or [#scalar_advec scalar_advec]). Therefore, with this scheme the Rayleigh damping is switched on ('''rayleigh_damping_factor''' = ''0.01'') by default. Otherwise it remains switched off.\\\\ The Rayleigh damping factor must hold the condition ''0.0'' <= '''rayleigh_damping_factor''' <= ''1.0.'' Large values (close to 1.0) can cause numerical instabilities. }}} |---------------- {{{#!td style="vertical-align:top" [=#rayleigh_damping_height '''rayleigh_damping_height'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 2/3*zu(nz)\\ (ocean:\\ 2/3*zu(0)) }}} {{{#!td Height above (ocean: below) which the Rayleigh damping starts (in m).\\\\ With Rayleigh damping switched on (see [#rayleigh_damping_factor rayleigh_damping_factor]), this parameter determines the range where damping is applied. By default, Rayleigh damping will be applied in the upper (ocean: lower) third of the model domain. }}} |---------------- {{{#!td style="vertical-align:top" [=#residual_limit '''residual_limit'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 1.0E-6 }}} {{{#!td Largest residual permitted for the multi-grid scheme (in s^-2^m^-3^).\\\\ This is a parameter to steer the accuracy of the multi-grid scheme (see [#psolver psolver]). The assigned cycle (v- or w-cycle, see [#mg_cycles mg_cycles]) is passed through until the residual falls below the limit given by '''residual_limit'''. If this is not the case after 1000 cycles, the PALM aborts with a corresponding error message.\\\\ The reciprocal value of this parameter can be interpreted as a factor by the divergence of the provisional velocity field is approximately reduced after the multi-grid scheme has been applied (thus the default value causes a reduction of the divergence by approx. 6 orders of magnitude). }}} |---------------- {{{#!td style="vertical-align:top" [=#scalar_advec '''scalar_advec'''] }}} {{{#!td style="vertical-align:top" C*10 }}} {{{#!td style="vertical-align:top" 'ws-scheme' }}} {{{#!td Advection scheme to be used for the scalar quantities.\\\\ The user can choose between the following schemes:\\\\ '' 'ws-scheme' ''\\\\ The 5th order upwind scheme of Wicker and Skamarock (2002, Mon. Wea. Rev, 130, 2088-2097) is used. The dispersion error is much smaller than the dispersion error of 'pw-scheme'. The 5th order schemes implies a small numerical dissipation that stabilized the solution. To assure a stable numerical solution the time integration has to be carry out with [#timestep_scheme timestep_scheme] = 'runge-kutta-3' . This scheme is based on a formultion of the advection term in flux form, which requires a vanishing divergence of the flow field, else a stable numerical solution is not given. So [#call_psolver_at_all_substeps call_psolver_at_all_substeps] = 'True' has to be used. When [#psolver psolver] = 'multigrid' the [#residual_limit residual_limit] should be smaller than 1.0E-6 for a sufficient reduction of the divergences. For the moment the scheme can only be used in conjunction with [#topography topography] = 'flat'. So far [#bc_lr bc_lr] /= 'cyclic' or [#bc_ns bc_ns] /= 'cyclic' are not allowed with [#loop_optimization loop_optimization] = 'vector' in combination with 'ws-scheme'. Note: Due to the larger stencil of this scheme vertical grid stretching should be handled with care.\\\\ '' 'pw-scheme' ''\\\\ The scheme of Piascek and Williams (1970, J. Comp. Phys., 6, 392-405) with central differences in the form C3 is used. If intermediate Euler-timesteps are carried out in case of [#timestep_scheme timestep_scheme] = '' 'leapfrog+euler' '' the advection scheme is - for the Euler-timestep - automatically switched to an upstream-scheme.\\\\ '' '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 timestep 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*pt*BC' '' / '' 'wptBC' '' should be used, instead of the standard profiles ('' 'w*pt*' '' and '' 'wpt' '') because these are too inaccurate with this scheme. However, for subdomain analysis (see [../d3par#statistic_regions statistic_regions]) exactly the reverse holds: here '' 'w*pt*BC' '' and '' 'wptBC' '' 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]).\\\\ '' 'ups-scheme' ''\\\\ The upstream-spline-scheme is used (see Mahrer and Pielke, 1978: Mon. Wea. Rev., 106, 818-830). In opposite to the Piascek Williams scheme, this is characterized by much better numerical features (less numerical diffusion, better preservation of flux structures, e.g. vortices), but computationally it is much more expensive. In addition, the use of the Euler-timestep scheme is mandatory ([#timestep_scheme timestep_scheme] = '' 'euler' ''), i.e. the timestep accuracy is only first order. For this reason the advection of momentum (see [#momentum_advec momentum_advec]) should then also be carried out with the upstream-spline scheme, because otherwise the momentum would be subject to large numerical diffusion due to the upstream scheme.\\\\ Since the cubic splines used tend to overshoot under certain circumstances, this effect must be adjusted by suitable filtering and smoothing (see [#long_filter_factor long_filter_factor]). This is always neccesssary for runs with stable stratification, even if this stratification appears only in parts of the model domain.\\\\ With stable stratification the upstream-upline scheme also produces gravity waves with large amplitude, which must be suitably damped (see [#rayleigh_damping_factor rayleigh_damping_factor]).\\\\ '''Important:'''\\ The upstream-spline scheme is not implemented for humidity and passive scalars (see [#humidity humidity] and [#passive_scalar passive_scalar]) and requires the use of a 2d-domain-decomposition. The last conditions severely restricts code optimization on several machines leading to very long execution times! This scheme is also not allowed for non-cyclic lateral boundary conditions (see [#bc_lr bc_lr] and [#bc_ns bc_ns]).\\\\ A differing advection scheme can be chosen for the subgrid-scale TKE using parameter [#use_upstream_for_tke use_upstream_for_tke]. }}} |---------------- {{{#!td style="vertical-align:top" [=#timestep_scheme '''timestep_scheme'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'runge\\ kutta-3' }}} {{{#!td Time step scheme to be used for the integration of the prognostic variables.\\\\ The user can choose between the following schemes:\\\\ '' 'runge-kutta-3' ''\\\\ Third order Runge-Kutta scheme.\\ This scheme requires the use of [#momentum_advec momentum_advec] = [#scalar_advec scalar_advec] = '' 'pw-scheme'.'' Please refer to the documentation on PALM's time integration schemes (28p., in German) for further details.\\\\ '' 'runge-kutta-2' ''\\\\ Second order Runge-Kutta scheme.\\ For special features see '''timestep_scheme''' = '' 'runge-kutta-3'.''\\\\ '' 'leapfrog' ''\\\\ Second order leapfrog scheme.\\ Although this scheme requires a constant timestep (because it is centered in time), it is even applied in case of changes in timestep. Therefore, only small changes of the timestep are allowed (see [#dt dt]). However, an Euler timestep is always used as the first timestep of an initial run. When using the Bott-Chlond scheme for scalar advection (see [#scalar_advec scalar_advec]), the prognostic equation for potential temperature will be calculated with the Euler scheme, although the leapfrog scheme is switched on.\\ The leapfrog scheme must not be used together with the upstream-spline scheme for calculating the advection (see [#scalar_advec scalar_advec] = '' 'ups-scheme' '' and [#momentum_advec momentum_advec] = '' 'ups-scheme' '').\\\\ '' 'leapfrog+euler' ''\\\\ The leapfrog scheme is used, but after each change of a timestep an Euler timestep is carried out. Although this method is theoretically correct (because the pure leapfrog method does not allow timestep changes), the divergence of the velocity field (after applying the pressure solver) may be significantly larger than with '' 'leapfrog'.''\\\\ '' 'euler' ''\\\\ First order Euler scheme.\\ The Euler scheme must be used when treating the advection terms with the upstream-spline scheme (see [#scalar_advec scalar_advec] = '' 'ups-scheme' '' and [#momentum_advec momentum_advec] = '' 'ups-scheme' '').\\\\ A differing timestep scheme can be chosen for the subgrid-scale TKE using parameter [#use_upstream_for_tke use_upstream_for_tke]. }}} |---------------- {{{#!td style="vertical-align:top" [=#use_upstream_for_tke '''use_upstream_for_tke'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter to choose the advection/timestep scheme to be used for the subgrid-scale TKE.\\\\ By default, the advection scheme and the timestep scheme to be used for the subgrid-scale TKE are set by the initialization parameters [#scalar_advec scalar_advec] and [#timestep_scheme timestep_scheme], respectively. '''use_upstream_for_tke''' = ''.T.'' forces the Euler-scheme and the upstream-scheme to be used as timestep scheme and advection scheme, respectively. By these methods, the strong (artificial) near-surface vertical gradients of the subgrid-scale TKE are significantly reduced. This is required when subgrid-scale velocities are used for advection of particles (see particle package parameter [../parpar#use_sgs_for_particles use_sgs_for_particles]). }}} [[BR]] [=#phys '''Physics:]\\ ||='''Parameter Name''' =||='''[../fortrantypes FORTRAN]\\[../fortrantypes Type]''' =||='''Default\\Value''' =||='''Explanation''' =|| |---------------- {{{#!td style="vertical-align:top;width: 150px" [=#omega '''omega'''] }}} {{{#!td style="vertical-align:top;width: 50px" R }}} {{{#!td style="vertical-align:top;width: 75px" 7.29212E-5 }}} {{{#!td Angular velocity of the rotating system (in rad/s).\\\\ The angular velocity of the earth is set by default. The values of the Coriolis parameters are calculated as:\\\\ f = 2.0 * '''omega''' * sin([#phi phi])\\ f* = 2.0 * '''omega''' * cos(phi) }}} |---------------- {{{#!td style="vertical-align:top" [=#phi '''phi'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 55.0 }}} {{{#!td Geographical latitude (in degrees).\\\\ The value of this parameter determines the value of the Coriolis parameters f and f*, provided that the angular velocity (see [#omega omega]) is non-zero. }}} |---------------- {{{#!td style="vertical-align:top" [=#prandtl_number '''prandtl_number'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 1.0 }}} {{{#!td Ratio of the eddy diffusivities for momentum and heat (K,,m,,/K,,h,,).\\\\ For runs with constant eddy diffusivity (see [#km_constant km_constant]), this parameter can be used to assign the Prandtl number (ratio K,,m,, / K,,h,,). }}} [[BR]] [=#bc '''Boundary conditions:]\\ ||='''Parameter Name''' =||='''[../fortrantypes FORTRAN]\\[../fortrantypes Type]''' =||='''Default\\Value''' =||='''Explanation''' =|| |---------------- {{{#!td style="vertical-align:top;width: 150px" [=#adjust_mixing_length '''adjust_mixing_length'''] }}} {{{#!td style="vertical-align:top;width: 50px" L }}} {{{#!td style="vertical-align:top;width: 75px" .F. }}} {{{#!td Near-surface adjustment of the mixing length to the Prandtl-layer law.\\\\ Usually the mixing length in LES models l,,LES,, depends (as in PALM) on the grid size and is possibly restricted further in case of stable stratification and near the lower wall (see parameter [#wall_adjustment wall_adjustment]). With '''adjust_mixing_length''' = ''.T.'' the Prandtl' mixing length l,,PR,, = kappa * z/phi is calculated and the mixing length actually used in the model is set l = MIN (l,,LES,, , l,,PR,,). This usually gives a decrease of the mixing length at the bottom boundary and considers the fact that eddy sizes decrease in the vicinity of the wall.\\\\ '''Warning:''' So far, there is no good experience with '''adjust_mixing_length''' = ''.T.''{{{!}}}\\\\ With '''adjust_mixing_length''' = ''.T.'' and the Prandtl-layer being switched on (see [#prandtl_layer prandtl_layer]) '' '(u*){{{**}}} 2+neumann' '' should always be set as the lower boundary condition for the TKE (see [#bc_e_b bc_e_b]), otherwise the near-surface value of the TKE is not in agreement with the Prandtl-layer law (Prandtl-layer law and Prandtl-Kolmogorov-Ansatz should provide the same value for K,,m,,). A warning is given, if this is not the case. }}} |---------------- {{{#!td style="vertical-align:top" [=#bc_e_b '''bc_e_b'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'neumann' }}} {{{#!td Bottom boundary condition of the TKE.\\\\ '''bc_e_b''' may be set to '' 'neumann' '' or '' '(u*){{{**}}}2+neumann' ''. '''bc_e_b''' = '' 'neumann' '' yields to e(k=0)=e(k=1) (Neumann boundary condition), where e(k=1) is calculated via the prognostic TKE equation. Choice of '' '(u*){{{**}}}2+neumann' '' also yields to e(k=0)=e(k=1), but the TKE at the Prandtl-layer top (k=1) is calculated diagnostically by e(k=1)=(us/0.1){{{**}}}2. However, this is only allowed if a Prandtl-layer is used ([#prandtl_layer prandtl_layer]). If this is not the case, a warning is given and '''bc_e_b''' is reset to '' 'neumann' ''.\\\\ At the top boundary a Neumann boundary condition is generally used: (e(nz+1) = e(nz)). }}} |---------------- {{{#!td style="vertical-align:top" [=#bc_lr '''bc_lr'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'cyclic' }}} {{{#!td Boundary condition along x (for all quantities).\\\\ By default, a cyclic boundary condition is used along x.\\\\ '''bc_lr''' may also be assigned the values '' 'dirichlet/radiation' '' (inflow from left, outflow to the right) or '' 'radiation/dirichlet' '' (inflow from right, outflow to the left). This requires the multi-grid method to be used for solving the Poisson equation for perturbation pressure (see [../d3par#psolver psolver]) and it also requires cyclic boundary conditions along y (see [#bc_ns bc_ns]).\\\\ 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 u, to which a Neumann (zero gradient) condition is applied. At the outflow, a radiation condition is used for all velocity components, while a Neumann (zero gradient) condition is used for the scalars. For perturbation pressure Neumann (zero gradient) conditions are assumed both at the inflow and at the outflow.\\\\ When using non-cyclic lateral boundaries, a filter is applied to the velocity field in the vicinity of the outflow in order to suppress any reflections of outgoing disturbances (see [#km_damp_max km_damp_max] and [#outflow_damping_width outflow_damping_width]).\\\\ In order to maintain a turbulent state of the flow, it may be neccessary 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].\\\\ In case of non-cyclic horizontal boundaries [#call_psolver_at_all_substeps call_psolver_at_all_substeps] = ''.T.'' should be used.\\\\ '''Note:'''\\ Using non-cyclic lateral boundaries requires very sensitive adjustments of the inflow (vertical profiles) and the bottom boundary conditions, e.g. a surface heating should not be applied near the inflow boundary because this may significantly disturb the inflow. Please check the model results very carefully. }}} |---------------- {{{#!td style="vertical-align:top" [=#bc_ns '''bc_ns'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'cyclic' }}} {{{#!td Boundary condition along y (for all quantities).\\\\ By default, a cyclic boundary condition is used along y.\\\\ '''bc_ns''' may also be assigned the values '' 'dirichlet/radiation' '' (inflow from rear ("north"), outflow to the front ("south")) or '' 'radiation/dirichlet' '' (inflow from front ("south"), outflow to the rear ("north")). This requires the multi-grid method to be used for solving the Poisson equation for perturbation pressure (see [../d3par#psolver psolver]) and it also requires cyclic boundary conditions along x (see [#bc_lr bc_lr]).\\\\ 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 u, to which a Neumann (zero gradient) condition is applied. At the outflow, a radiation condition is used for all velocity components, while a Neumann (zero gradient) condition is used for the scalars. For perturbation pressure Neumann (zero gradient) conditions are assumed both at the inflow and at the outflow.\\\\ For further details regarding non-cyclic lateral boundary conditions see [#bc_lr bc_lr]. }}} |---------------- {{{#!td style="vertical-align:top" [=#bc_p_b '''bc_p_b'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'neumann' }}} {{{#!td Bottom boundary condition of the perturbation pressure.\\\\ Allowed values are '' 'dirichlet' '', '' 'neumann' '' and '' 'neumann+inhomo' ''. '' 'dirichlet' '' sets p(k=0)=0.0, '' 'neumann' '' sets p(k=0)=p(k=1). '' 'neumann+inhomo' '' corresponds to an extended Neumann boundary condition where heat flux or temperature inhomogeneities near the surface (pt(k=1)) are additionally regarded (see Shen and LeClerc (1995, Q.J.R. Meteorol. Soc., 1209)). This condition is only permitted with the Prandtl-layer switched on ([#prandtl_layer prandtl_layer]), otherwise the run is terminated.\\\\ Since at the bottom boundary of the model the vertical velocity disappears (w(k=0) = 0.0), the consistent Neumann condition ('' 'neumann' '' or '' 'neumann+inhomo' '') dp/dz = 0 should be used, which leaves the vertical component w unchanged when the pressure solver is applied. Simultaneous use of the Neumann boundary conditions both at the bottom and at the top boundary ([#bc_p_t bc_p_t]) usually yields no consistent solution for the perturbation pressure and should be avoided. }}} |---------------- {{{#!td style="vertical-align:top" [=#bc_p_t '''bc_p_t'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'dirichlet' }}} {{{#!td Top boundary condition of the perturbation pressure.\\\\ Allowed values are '' 'dirichlet' '' (p(k=nz+1)= 0.0) or '' 'neumann' '' (p(k=nz+1)=p(k=nz)).\\\\ Simultaneous use of Neumann boundary conditions both at the top and bottom boundary ([#bc_p_b bc_p_b]) usually yields no consistent solution for the perturbation pressure and should be avoided. Since at the bottom boundary the Neumann condition is a good choice (see [#bc_p_b bc_p_b]), a Dirichlet condition should be set at the top boundary. }}} |---------------- {{{#!td style="vertical-align:top" [=#bc_pt_b '''bc_pt_b'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'dirichlet' }}} {{{#!td Bottom boundary condition of the potential temperature.\\\\ Allowed values are '' 'dirichlet' '' (pt(k=0) = const. = [#pt_surface pt_surface] + [#pt_surface_initial_change pt_surface_initial_change]; the user may change this value during the run using [#user-defined] code) and '' 'neumann' '' (pt(k=0)=pt(k=1)). When a constant surface sensible heat flux is used ([#surface_heatflux surface_heatflux]), '''bc_pt_b''' = '' 'neumann' '' must be used, because otherwise the resolved scale may contribute to the surface flux so that a constant value cannot be guaranteed.\\\\ In the coupled atmosphere executable, '''bc_pt_b''' is internally set and does not need to be prescribed. }}} |---------------- {{{#!td style="vertical-align:top" [=#bc_pt_t '''bc_pt_t'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'initial_gradient' }}} {{{#!td Top boundary condition of the potential temperature.\\\\ Allowed are the values '' 'dirichlet' '' (pt(k=nz+1) does not change during the run), '' 'neumann' '' (pt(k=nz+1)=pt(k=nz)), and '' 'initial_gradient' ''. With the '' 'initial_gradient' ''-condition the value of the temperature gradient at the top is calculated from the initial temperature profile (see [#pt_surface pt_surface], [#pt_vertical_gradient pt_vertical_gradient]) by bc_pt_t_val = (pt_init(k=nz+1) - pt_init(k=nz)) / dzu(nz+1). Using this value (assumed constant during the run) the temperature boundary values are calculated as pt(k=nz+1) = pt(k=nz) + bc_pt_t_val * dzu(nz+1) (up to k=nz the prognostic equation for the temperature is solved). When a constant sensible heat flux is used at the top boundary ([#top_heatflux top_heatflux]), '''bc_pt_t''' = '' 'neumann' '' must be used, because otherwise the resolved scale may contribute to the top flux so that a constant value cannot be guaranteed. }}} |---------------- {{{#!td style="vertical-align:top" [=#bc_q_b '''bc_q_b'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'dirichlet' }}} {{{#!td Bottom boundary condition of the specific humidity / total water content.\\\\ Allowed values are '' 'dirichlet' '' (q(k=0) = const. = [#q_surface q_surface] + [#q_surface_initial_change q_surface_initial_change]; the user may change this value during the run using [#user-defined] code) and '' 'neumann' '' (q(k=0)=q(k=1)). When a constant surface latent heat flux is used ([#surface_waterflux surface_waterflux]), '''bc_q_b''' = '' 'neumann' '' must be used, because otherwise the resolved scale may contribute to the surface flux so that a constant value cannot be guaranteed. }}} |---------------- {{{#!td style="vertical-align:top" [=#bc_q_t '''bc_q_t'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'neumann' }}} {{{#!td Top boundary condition of the specific humidity / total water content.\\\\ Allowed are the values '' 'dirichlet' '' (q(k=nz) and q(k=nz+1) do not change during the run) and '' 'neumann' ''. With the Neumann boundary condition the value of the humidity gradient at the top is calculated from the initial humidity profile (see [#q_surface q_surface], [#q_vertical_gradient q_vertical_gradient]) by: bc_q_t_val = ( q_init(k=nz) - q_init(k=nz-1)) / dzu(nz). Using this value (assumed constant during the run) the humidity boundary values are calculated as q(k=nz+1) =q(k=nz) + bc_q_t_val * dzu(nz+1) (up tp k=nz the prognostic equation for q is solved). }}} |---------------- {{{#!td style="vertical-align:top" [=#bc_s_b '''bc_s_b'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'dirichlet' }}} {{{#!td Bottom boundary condition of the scalar concentration.\\\\ Allowed values are '' 'dirichlet' '' (s(k=0) = const. = [#s_surface s_surface] + [#s_surface_initial_change s_surface_initial_change]; the user may change this value during the run using [#user-defined] code) and '' 'neumann' '' (s(k=0) = s(k=1)). When a constant surface concentration flux is used ([#surface_scalarflux surface_scalarflux]), '''bc_s_b''' = '' 'neumann' '' must be used, because otherwise the resolved scale may contribute to the surface flux so that a constant value cannot be guaranteed. }}} |---------------- {{{#!td style="vertical-align:top" [=#bc_s_t '''bc_s_t'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'neumann' }}} {{{#!td Top boundary condition of the scalar concentration.\\\\ Allowed are the values '' 'dirichlet' '' (s(k=nz) and s(k=nz+1) do not change during the run) and '' 'neumann' ''. With the Neumann boundary condition the value of the scalar concentration gradient at the top is calculated from the initial scalar concentration profile (see [#s_surface s_surface], [#s_vertical_gradient s_vertical_gradient]) by: bc_s_t_val = (s_init(k=nz) - s_init(k=nz-1)) / dzu(nz). Using this value (assumed constant during the run) the concentration boundary values are calculated as s(k=nz+1) = s(k=nz) + bc_s_t_val * dzu(nz+1) (up to k=nz the prognostic equation for the scalar concentration is solved). }}} |---------------- {{{#!td style="vertical-align:top" [=#bc_sa_t '''bc_sa_t'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'neumann' }}} {{{#!td Top boundary condition of the salinity.\\\\ This parameter only comes into effect for ocean runs (see parameter [#ocean ocean]).\\\\ Allowed are the values '' 'dirichlet' '' (sa(k=nz+1) does not change during the run) and '' 'neumann' '' (sa(k=nz+1)=sa(k=nz)).\\\\ When a constant salinity flux is used at the top boundary ([#top_salinityflux top_salinityflux]), '''bc_sa_t''' = '' 'neumann' '' must be used, because otherwise the resolved scale may contribute to the top flux so that a constant value cannot be guaranteed. }}} |---------------- {{{#!td style="vertical-align:top" [=#bc_uv_b '''bc_uv_b'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'dirichlet' }}} {{{#!td Bottom boundary condition of the horizontal velocity components u and v.\\\\ Allowed values are '' 'dirichlet' '' and '' 'neumann' ''. '''bc_uv_b''' = '' 'dirichlet' '' yields the no-slip condition with u=v=0 at the bottom. Due to the staggered grid u(k=0) and v(k=0) are located at z = - 0,5 * [#dz dz] (below the bottom), while u(k=1) and v(k=1) are located at z = +0,5 * dz. u=v=0 at the bottom is guaranteed using mirror boundary condition: u(k=0) = - u(k=1) and v(k=0) = - v(k=1) The Neumann boundary condition yields the free-slip condition with u(k=0) = u(k=1) and v(k=0) = v(k=1). With Prandtl - layer switched on (see [#prandtl_layer prandtl_layer]), the free-slip condition is not allowed (otherwise the run will be terminated). }}} |---------------- {{{#!td style="vertical-align:top" [=#bc_uv_t '''bc_uv_t'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'dirichlet' }}} {{{#!td Top boundary condition of the horizontal velocity components u and v.\\\\ Allowed values are '' 'dirichlet' '', '' 'dirichlet_0' '' and '' 'neumann' ''. The Dirichlet condition yields u(k=nz+1) = ug(nz+1) and v(k=nz+1) = vg(nz+1), Neumann condition yields the free-slip condition with u(k=nz+1) = u(k=nz) and v(k=nz+1) = v(k=nz) (up to k=nz the prognostic equations for the velocities are solved). The special condition '' 'dirichlet_0' '' can be used for channel flow, it yields the no-slip condition u(k=nz+1) = ug(nz+1) = 0 and v(k=nz+1) = vg(nz+1) = 0. In the coupled ocean executable, bc_uv_t is internally set ('neumann') and does not need to be prescribed. }}} |---------------- {{{#!td style="vertical-align:top" [=#bottom_salinityflux '''bottom_salinityflux'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Kinematic salinity flux near the surface (in psu m/s).\\\\ This parameter only comes into effect for ocean runs (see parameter [#ocean ocean]).\\\\ The respective salinity flux value is used as bottom (horizontally homogeneous) boundary condition for the salinity equation. This additionally requires that a Neumann condition must be used for the salinity, which is currently the only available condition. }}} |---------------- {{{#!td style="vertical-align:top" [=#inflow_damping_height '''inflow_damping_height'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" from precursor run }}} {{{#!td Height below which the turbulence signal is used for turbulence recycling (in m).\\\\ In case of a turbulent inflow (see [#turbulent_inflow turbulent_inflow]), this parameter defines the vertical thickness of the turbulent layer up to which the turbulence extracted at the recycling plane (see [#recycling_width recycling_width]) shall be imposed to the inflow. Above this level the turbulence signal is linearly damped to zero. The transition range within which the signal falls to zero is given by the parameter [#inflow_damping_width inflow_damping_width].\\\\ By default, this height is set as the height of the convective boundary layer as calculated from a precursor run. Information about proper settings for getting this CBL height from a precursor run can be found [../examples/turbinf here]. }}} |---------------- {{{#!td style="vertical-align:top" [=#inflow_damping_width '''inflow_damping_width'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.1 * [#inflow_damping_height inflow_damping]\\ [#inflow_damping_height _height] }}} {{{#!td Transition range within which the turbulance signal is damped to zero (in m).\\\\ See [#inflow_damping_height inflow_damping_height] for explanation. }}} |---------------- {{{#!td style="vertical-align:top" [=#inflow_disturbance_begin '''inflow_disturbance_begin'''] }}} {{{#!td style="vertical-align:top" I }}} {{{#!td style="vertical-align:top" MIN(10, [#nx nx]/2 or [#ny ny]/2) }}} {{{#!td Lower limit of the horizontal range for which random perturbations are to be imposed on the horizontal velocity field (gridpoints).\\\\ If non-cyclic lateral boundary conditions are used (see [#bc_lr bc_lr] or [#bc_ns bc_ns]), this parameter gives the gridpoint 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]. }}} |---------------- {{{#!td style="vertical-align:top" [=#inflow_disturbance_end '''inflow_disturbance_end'''] }}} {{{#!td style="vertical-align:top" I }}} {{{#!td style="vertical-align:top" MIN(100, 3/4*[#nx nx] or 3/4*[#ny ny]) }}} {{{#!td Upper limit of the horizontal range for which random perturbations are to be imposed on the horizontal velocity field (gridpoints).\\\\ If non-cyclic lateral boundary conditions are used (see [#bc_lr bc_lr] or [#bc_ns bc_ns]), this parameter gives the gridpoint 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]. }}} |---------------- {{{#!td style="vertical-align:top" [=#outflow_damping_width '''outflow_damping_width'''] }}} {{{#!td style="vertical-align:top" I }}} {{{#!td style="vertical-align:top" MIN(20, [#nx nx]/2 or [#ny ny]/2) }}} {{{#!td Width of the damping range in the vicinity of the outflow (gridpoints).\\\\ When using non-cyclic lateral boundaries (see [#bc_lr bc_lr] or [#bc_ns bc_ns]), a smoothing has to be applied to the velocity field in the vicinity of the outflow in order to suppress any reflections of outgoing disturbances. This parameter controlls the horizontal range to which the smoothing is applied. The range is given in gridpoints counted from the respective outflow boundary. For further details about the smoothing see parameter [#km_damp_max km_damp_max], which defines the magnitude of the damping. }}} |---------------- {{{#!td style="vertical-align:top" [=#prandtl_layer '''prandtl_layer'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .T. }}} {{{#!td Parameter to switch on a Prandtl layer.\\\\ By default, a Prandtl layer is switched on at the bottom boundary between z = 0 and z = 0.5 * [#dz dz] (the first computational grid point above ground for u, v and the scalar quantities). In this case, at the bottom boundary, free-slip conditions for u and v (see [#bc_uv_b bc_uv_b]) are not allowed. Likewise, laminar simulations with constant eddy diffusivities ([#km_constant km_constant]) are forbidden.\\\\ With Prandtl-layer switched off, the TKE boundary condition [#bc_e_b bc_e_b] = '' '(u*){{{**}}}2+neumann' '' must not be used and is automatically changed to '' 'neumann' '' if necessary. Also, the pressure boundary condition [#bc_p_b bc_p_b] = '' 'neumann+inhomo' '' is not allowed.\\\\ If the Prandtl-layer is switched off and fluxes shall be prescribed at the surface (by setting [#surface_heatflux surface_heatflux]), it is required to set the parameter [#use_surface_fluxes use_surface_fluxes] = ''.T.''.\\\\ The roughness length is declared via the parameter [#roughness_length roughness_length]. }}} |---------------- {{{#!td style="vertical-align:top" [=#recycling_width '''recycling_width'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.1 * [#nx nx] * [#dx dx] }}} {{{#!td Distance of the recycling plane from the inflow boundary (in m).\\\\ This parameter sets the horizontal extension (along the direction of the main flow) of the so-called recycling domain which is used to generate a turbulent inflow (see description of [../examples/turbinf turbulent inflow]). '''recycling_width''' must be larger than the grid spacing ([#dx dx]) and smaller than the length of the total domain ([#nx nx] * dx). }}} |---------------- {{{#!td style="vertical-align:top" [=#rif_max '''rif_max'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 1.0 }}} {{{#!td Upper limit of the flux-Richardson number.\\\\ With the Prandtl layer switched on (see [#prandtl_layer prandtl_layer]]), flux-Richardson numbers ('''rif''') are calculated for z=zp (k=1) in the 3d-model (in the [../../tec/1dmodel 1d-model] for all heights). Their values in particular determine the values of the friction velocity (1d- and 3d-model) and the values of the eddy diffusivity (1d-model). With small wind velocities at the Prandtl layer top or small vertical wind shears in the 1d-model, '''rif''' can take up unrealistic large values. They are limited by an upper ('''rif_max''') and lower limit (see [#rif_min rif_min]) for the flux-Richardson number. The condition '''rif_max''' > rif_min must be met. }}} |---------------- {{{#!td style="vertical-align:top" [=#rif_min '''rif_min'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" -5.0 }}} {{{#!td Lower limit of the flux-Richardson number.\\\\ For further explanations see [#rif_max rif_max]. The condition rif_max > '''rif_min''' must be met. }}} |---------------- {{{#!td style="vertical-align:top" [=#roughness_length '''roughness_length'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.1 }}} {{{#!td Roughness length (in m).\\\\ This parameter is effective only in case that a Prandtl layer is switched on (see [#prandtl_layer prandtl_layer]). }}} |---------------- {{{#!td style="vertical-align:top" [=#sa_vertical_gradient '''sa_vertical_gradient'''] }}} {{{#!td style="vertical-align:top" R(10) }}} {{{#!td style="vertical-align:top" 10 * 0.0 }}} {{{#!td Salinity gradient(s) of the initial salinity profile (in psu / 100 m).\\\\ This parameter only comes into effect for ocean runs (see parameter [#ocean ocean]).\\\\ This salinity gradient holds starting from the height level defined by [#sa_vertical_gradient_level sa_vertical_gradient_level] (precisely: for all uv levels k where zu(k) < sa_vertical_gradient_level, sa_init(k) is set: sa_init(k) = sa_init(k+1) - dzu(k+1) * '''sa_vertical_gradient''') down to the bottom boundary or down to the next height level defined by sa_vertical_gradient_level. A total of 10 different gradients for 11 height intervals (10 intervals if sa_vertical_gradient_level(1) = 0.0) can be assigned. The surface salinity at k=[#nzt nzt] is assigned via [#sa_surface sa_surface].\\\\ '''Example:'''\\\\ '''sa_vertical_gradient''' = ''1.0,'' ''0.5,''\\ [#sa_vertical_gradient_level sa_vertical_gradient_level] = ''-500.0,'' ''-1000.0,''\\\\ That defines the salinity to be constant down to z = -500.0 m with a salinity given by sa_surface. For -500.0 m < z <= -1000.0 m the salinity gradient is 1.0 psu / 100 m and for z < -1000.0 m down to the bottom boundary it is 0.5 psu / 100 m (it is assumed that the assigned height levels correspond with uv levels). }}} |---------------- {{{#!td style="vertical-align:top" [=#sa_vertical_gradient_level '''sa_vertical_gradient_level'''] }}} {{{#!td style="vertical-align:top" R(10) }}} {{{#!td style="vertical-align:top" 10 * 0.0 }}} {{{#!td Height level from which on the salinity gradient defined by [#sa_vertical_gradient sa_vertical_gradient] is effective (in m).\\\\ This parameter only comes into effect for ocean runs (see parameter [#ocean ocean]).\\\\ The height levels have to be assigned in descending order. The default values result in a constant salinity profile regardless of the values of sa_vertical_gradient (unless the bottom boundary of the model is lower than -100000.0 m). For the piecewise construction of salinity profiles see [#sa_vertical_gradient sa_vertical_gradient]. }}} |---------------- {{{#!td style="vertical-align:top" [=#surface_heatflux '''surface_heatflux'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" no prescribed\\ heatflux }}} {{{#!td Kinematic sensible heat flux at the bottom surface (in K m/s).\\\\ If a value is assigned to this parameter, the internal two-dimensional surface heat flux field '''shf''' is initialized with the value of '''surface_heatflux''' as bottom (horizontally homogeneous) boundary condition for the temperature equation. This additionally requires that a Neumann condition must be used for the potential temperature (see [#bc_pt_b bc_pt_b]), because otherwise the resolved scale may contribute to the surface flux so that a constant value cannot be guaranteed. Also, changes of the surface temperature (see [#pt_surface_initial_change pt_surface_initial_change]) are not allowed. The parameter [#random_heatflux random_heatflux] can be used to impose random perturbations on the (homogeneous) surface heat flux field '''shf'''.\\\\ '''Attention:'''\\ Setting of '''surface_heatflux''' requires setting of [#use_surface_fluxes use_surface_fluxes] = ''.T.,'' if the Prandtl-layer is switched off ([#prandtl_layer prandtl_layer] = ''.F.'').\\\\ In case of a non-flat topography, the internal two-dimensional surface heat flux field '''shf''' is initialized with the value of '''surface_heatflux''' at the bottom surface and [#wall_heatflux wall_heatflux](0) at the topography top face. The parameter random_heatflux can be used to impose random perturbations on this combined surface heat flux field '''shf'''.\\\\ If no surface heat flux is assigned, '''shf''' is calculated at each timestep by u,,*,, {{{*}}} theta,,*,, (of course only with [#prandtl_layer prandtl_layer] switched on). Here, u,,*,, and theta,,*,, are calculated from the Prandtl law assuming logarithmic wind and temperature profiles between k=0 and k=1. In this case a Dirichlet condition (see [#bc_pt_b bc_pt_b]) must be used as bottom boundary condition for the potential temperature.\\\\ See also [#top_heatflux top_heatflux]. }}} |---------------- {{{#!td style="vertical-align:top" [=#surface_scalarflux '''surface_scalarflux'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" no prescribed\\ heatflux }}} {{{#!td Scalar flux at the surface (in kg/(m^2^ s)).\\\\ If a non-zero value is assigned to this parameter, the respective scalar flux value is used as bottom (horizontally homogeneous) boundary condition for the scalar concentration equation. This additionally requires that a Neumann condition must be used for the scalar concentration (see [#bc_s_b bc_s_b]), because otherwise the resolved scale may contribute to the surface flux so that a constant value cannot be guaranteed. Also, changes of the surface scalar concentration (see [#s_surface_initial_change s_surface_initial_change]) are not allowed.\\\\ If no surface scalar flux is assigned ('''surface_scalarflux''' = ''0.0''), it is calculated at each timestep by u,,*,, {{{*}}} s,,*,, (of course only with [#prandtl_layer prandtl_layer] switched on). Here, s,,*,, is calculated from the Prandtl law assuming a logarithmic scalar concentration profile between k=0 and k=1. In this case a Dirichlet condition (see bc_s_b) must be used as bottom boundary condition for the scalar concentration. }}} |---------------- {{{#!td style="vertical-align:top" [=#surface_waterflux '''surface_waterflux'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" no prescribed\\ heatflux }}} {{{#!td Kinematic water flux near the surface (in m/s).\\\\ If a non-zero value is assigned to this parameter, the respective water flux value is used as bottom (horizontally homogeneous) boundary condition for the humidity equation. This additionally requires that a Neumann condition must be used for the specific humidity / total water content (see [#bc_q_b bc_q_b]), because otherwise the resolved scale may contribute to the surface flux so that a constant value cannot be guaranteed. Also, changes of the surface humidity (see [#q_surface_initial_change q_surface_initial_change]) are not allowed.\\\\ If no surface water flux is assigned ('''surface_waterflux''' = ''0.0''), it is calculated at each timestep by u,,*,, {{{*}}} q,,*,, (of course only with Prandtl layer switched on). Here, q,,*,, is calculated from the Prandtl law assuming a logarithmic temperature profile between k=0 and k=1. In this case a Dirichlet condition (see bc_q_b) must be used as the bottom boundary condition for the humidity. }}} |---------------- {{{#!td style="vertical-align:top" [=#top_heatflux '''top_heatflux'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" no prescribed\\ heatflux }}} {{{#!td Kinematic sensible heat flux at the top boundary (in K m/s).\\\\ If a value is assigned to this parameter, the internal two-dimensional surface heat flux field {{{tswst}}} is initialized with the value of '''top_heatflux''' as top (horizontally homogeneous) boundary condition for the temperature equation. This additionally requires that a Neumann condition must be used for the potential temperature (see [#bc_pt_t bc_pt_t]), because otherwise the resolved scale may contribute to the top flux so that a constant flux value cannot be guaranteed.\\\\ '''Note:'''\\ The application of a top heat flux additionally requires the setting of initial parameter [#use_top_fluxes use_top_fluxes] = ''.T.''.\\\\ No Prandtl-layer is available at the top boundary so far.\\\\ See also [#surface_heatflux surface_heatflux]. }}} |---------------- {{{#!td style="vertical-align:top" [=#top_momentumflux_u '''top_momentumflux_u'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" no prescribed\\ momentumflux }}} {{{#!td Momentum flux along x at the top boundary (in m^2^/s^2^).\\\\ If a value is assigned to this parameter, the internal two-dimensional u-momentum flux field {{{uswst}}} is initialized with the value of '''top_momentumflux_u''' as top (horizontally homogeneous) boundary condition for the u-momentum equation.\\\\ '''Notes:'''\\ The application of a top momentum flux additionally requires the setting of initial parameter [#use_top_fluxes use_top_fluxes] = ''.T.''. Setting of '''top_momentumflux_u''' requires setting of [#top_momentumflux_v top_momentumflux_v] also.\\\\ A Neumann condition should be used for the u velocity component (see [#bc_uv_t bc_uv_t]), because otherwise the resolved scale may contribute to the top flux so that a constant flux value cannot be guaranteed.\\\\ No Prandtl-layer is available at the top boundary so far.\\\\ The coupled ocean parameter file [../iofiles#PARIN_O PARIN_O] should include dummy REAL value assignments to both '''top_momentumflux_u''' and [#top_momentumflux_v top_momentumflux_v] (e.g. '''top_momentumflux_u''' = ''0.0,'' [#top_momentumflux_v top_momentumflux_v] = ''0.0'') to enable the momentum flux coupling. }}} |---------------- {{{#!td style="vertical-align:top" [=#top_momentumflux_v '''top_momentumflux_v'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" no prescribed\\ momentumflux }}} {{{#!td Momentum flux along y at the top boundary (in m^2^/s^2^).\\\\ If a value is assigned to this parameter, the internal two-dimensional v-momentum flux field {{{vswst}}} is initialized with the value of '''top_momentumflux_v''' as top (horizontally homogeneous) boundary condition for the v-momentum equation.\\\\ '''Notes:'''\\ The application of a top momentum flux additionally requires the setting of initial parameter [#use_top_fluxes use_top_fluxes] = ''.T.''. Setting of '''top_momentumflux_v''' requires setting of [#top_momentumflux_u top_momentumflux_u] also.\\\\ A Neumann condition should be used for the v velocity component (see [#bc_uv_t bc_uv_t]), because otherwise the resolved scale may contribute to the top flux so that a constant flux value cannot be guaranteed.\\\\ No Prandtl-layer is available at the top boundary so far.\\\\ The coupled ocean parameter file [../iofiles#PARIN_O PARIN_O] should include dummy REAL value assignments to both [#top_momentumflux_u top_momentumflux_u] and '''top_momentumflux_v''' (e.g. [#top_momentumflux_u top_momentumflux_u] = ''0.0,'' '''top_momentumflux_'''v = ''0.0'') to enable the momentum flux coupling. }}} |---------------- {{{#!td style="vertical-align:top" [=#top_salinityflux '''top_salinityflux'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" no prescribed\\ salinityflux }}} {{{#!td Kinematic salinity flux at the top boundary, i.e. the sea surface (in psu m/s).\\\\ This parameter only comes into effect for ocean runs (see parameter [#ocean ocean]).\\\\ If a value is assigned to this parameter, the internal two-dimensional surface heat flux field {{{saswst}}} is initialized with the value of '''top_salinityflux''' as top (horizontally homogeneous) boundary condition for the salinity equation. This additionally requires that a Neumann condition must be used for the salinity (see [#bc_sa_t bc_sa_t]), because otherwise the resolved scale may contribute to the top flux so that a constant flux value cannot be guaranteed.\\\\ '''Note:'''\\ The application of a salinity flux at the model top additionally requires the setting of initial parameter [#use_top_fluxes use_top_fluxes] = ''.T.''.\\\\ See also [#bottom_salinityflux bottom_salinityflux]. }}} |---------------- {{{#!td style="vertical-align:top" [=#turbulent_inflow '''turbulent_inflow'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Generates a turbulent inflow at side boundaries using a turbulence recycling method.\\\\ Turbulent inflow is realized using the turbulence recycling method from Lund et al. (1998, J. Comp. Phys., 140, 233-258) modified by Kataoka and Mizuno (2002, Wind and Structures, 5, 379-392).\\\\ A turbulent inflow requires Dirichlet conditions at the respective inflow boundary. So far, a turbulent inflow is realized from the left (west) side only, i.e. [#bc_lr bc_lr] = '' 'dirichlet/radiation' '' is required!\\\\ The initial (quasi-stationary) turbulence field should be generated by a precursor run and used by setting [#initializing_actions initializing_actions] = '' 'cyclic_fill'.''\\\\ The distance of the recycling plane from the inflow boundary can be set with parameter [#recycling_width recycling_width]. The heigth above ground above which the turbulence signal is not used for recycling and the width of the layer within the magnitude of the turbulence signal is damped from 100% to 0% can be set with parameters [#inflow_damping_height inflow_damping_height] and [#inflow_damping_width inflow_damping_width].\\\\ The detailed setup for a turbulent inflow is described in [../examples/turbinf here]. }}} |---------------- {{{#!td style="vertical-align:top" [=#use_surface_fluxes '''use_surface_fluxes'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter to steer the treatment of the subgrid-scale vertical fluxes within the diffusion terms at k=1 (bottom boundary).\\\\ By default, the near-surface subgrid-scale fluxes are parameterized (like in the remaining model domain) using the gradient approach. If '''use_surface_fluxes''' = ''.T.,'' the user-assigned surface fluxes are used instead (see [#surface_heatflux surface_heatflux], [#surface_waterflux surface_waterflux] and [#surface_scalarflux surface_scalarflux]) or the surface fluxes are calculated via the Prandtl layer relation (depends on the bottom boundary conditions, see [#bc_pt_b bc_pt_b], [#bc_q_b bc_q_b] and [#bc_s_b bc_s_b]).\\\\ '''use_surface_fluxes''' is automatically set ''.T.,'' if a Prandtl layer is used (see [#prandtl_layer prandtl_layer]).\\\\ The user may prescribe the surface fluxes at the bottom boundary without using a Prandtl layer by setting '''use_surface_fluxes''' = ''.T.'' and [#prandtl_layer prandtl_layer] = ''.F.''. If , in this case, the momentum flux (u,,*,,^2^) should also be prescribed, the user must assign an appropriate value within the [../userint user-defined code]. }}} |---------------- {{{#!td style="vertical-align:top" [=#use_top_fluxes '''use_top_fluxes'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter to steer the treatment of the subgrid-scale vertical fluxes within the diffusion terms at k=nz (top boundary).\\\\ By default, the fluxes at nz are calculated using the gradient approach. If '''use_top_fluxes''' = ''.T.,'' the user-assigned top fluxes are used instead (see [#top_heatflux top_heatflux], [#top_momentumflux_u top_momentumflux_u], [#top_momentumflux_v top_momentumflux_v], [#top_salinityflux top_salinityflux]).\\\\ Currently, no value for the latent heatflux can be assigned. In case of '''use_top_fluxes''' = ''.T.,'' the latent heat flux at the top will be automatically set to zero. }}} |---------------- {{{#!td style="vertical-align:top" [=#wall_adjustment '''wall_adjustment'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .T. }}} {{{#!td Parameter to restrict the mixing length in the vicinity of the bottom boundary (and near vertical walls of a non-flat topography).\\\\ With '''wall_adjustment''' = ''.T.,'' the mixing length is limited to a maximum of 1.8 * z. This condition typically affects only the first grid points above the bottom boundary.\\\\ In case of a non-flat topography the respective horizontal distance from vertical walls is used. }}} [[BR]] [=#ini '''Initialization:]\\ ||='''Parameter Name''' =||='''[../fortrantypes FORTRAN]\\[../fortrantypes Type]''' =||='''Default\\Value''' =||='''Explanation''' =|| |---------------- {{{#!td style="vertical-align:top;width: 150px" [=#damp_level_1d '''damp_level_1d'''] }}} {{{#!td style="vertical-align:top;width: 50px" R }}} {{{#!td style="vertical-align:top;width: 75px" zu(nz+1) }}} {{{#!td Height where the damping layer begins in the [../../tec/1dmodel 1d-model] (in m).\\\\ This parameter is used to switch on a damping layer for the 1d-model, which is generally needed for the damping of inertia oscillations. Damping is done by gradually increasing the value of the eddy diffusivities about 10% per vertical grid level (starting with the value at the height given by '''damp_level_1d''', or possibly from the next grid pint above), i.e. K,,m,,(k+1) = 1.1 * K,,m,,(k). The values of K,,m,, are limited to 10 m^2^/s at maximum.\\\\ This parameter only comes into effect if the 1d-model is switched on for the initialization of the 3d-model using [#initializing_actions initializing_actions] = '' 'set_1d-model_profiles'.'' }}} |---------------- {{{#!td style="vertical-align:top" [=#dissipation_1d '''dissipation_1d'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'as_in_3d_model' }}} {{{#!td Calculation method for the energy dissipation term in the TKE equation of the [../../tec/1dmodel 1d-model].\\\\ By default the dissipation is calculated as in the 3d-model using diss = (0.19 + 0.74 * l / l_grid) * e{{{**}}}1.5 / l.\\\\ Setting '''dissipation_1d''' = '' 'detering' '' forces the dissipation to be calculated as diss = 0.064 * e{{{**}}}1.5 / l. }}} |---------------- {{{#!td style="vertical-align:top" [=#dt '''dt'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" variable }}} {{{#!td Time step for the 3d-model (in s).\\\\ By default, (i.e. if a Runge-Kutta scheme is used, see [#timestep_scheme timestep_scheme]) the value of the time step is calculating after each time step (following the time step criteria) and used for the next step.\\\\ If the user assigns '''dt''' 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 calculated time step meets the condition\\\\ '''dt''' < 0.00001 * [../d3par#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 windspeed speed may be enlarged by using a coordinate transformation (see [#galilei_transformation galilei_transformation]), in order to spare CPU time.\\\\ If the leapfrog timestep scheme is used (see [#timestep_scheme timestep_scheme]) a temporary time step value dt_new is calculated first, with dt_new = [#cfl_factor cfl_factor] * dt_crit where dt_crit is the maximum timestep allowed by the CFL and diffusion condition. Next it is examined whether dt_new exceeds or falls below the value of the previous timestep by at least +5 % / -2%. If it is smaller, '''dt''' = dt_new is immediately used for the next timestep. If it is larger, then '''dt''' = 1.02 * dt_prev (previous timestep) is used as the new timestep, however the time step is only increased if the last change of the time step is dated back at least 30 iterations. If dt_new is located in the interval mentioned above, then '''dt''' does not change at all. By doing so, permanent time step changes as well as large sudden changes (increases) in the time step are avoided. }}} |---------------- {{{#!td style="vertical-align:top" [=#dt_pr_1d '''dt_pr_1d'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 9999999.9 }}} {{{#!td Temporal interval of vertical profile output of the [../../tec/1dmodel 1d-model] (in s).\\\\ Data are written in ASCII format to file [../iofiles#LIST_PROFIL_1D LIST_PROFIL_1D]. This parameter is only in effect if the 1d-model has been switched on for the initialization of the 3d-model with [#initializing_actions initializing_actions] = '' 'set_1d-model_profiles'.'' }}} |---------------- {{{#!td style="vertical-align:top" [=#dt_run_control_1d '''dt_run_control_1d'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 60.0 }}} {{{#!td Temporal interval of runtime control output of the [../../tec/1dmodel 1d-model] (in s).\\\\ Data are written in ASCII format to file [../iofiles#RUN_CONTROL RUN_CONTROL]. This parameter is only in effect if the 1d-model is switched on for the initialization of the 3d-model with [#initializing_actions initializing_actions] = '' 'set_1d-model_profiles'.'' }}} |---------------- {{{#!td style="vertical-align:top" [=#end_time_1d '''end_time_1d'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 864000.0 }}} {{{#!td Time to be simulated for the [../../tec/1dmodel 1d-model] (in s).\\\\ The default value corresponds to a simulated time of 10 days. Usually, after such a period the inertia oscillations have completely decayed and the solution of the 1d-model can be regarded as stationary (see [#damp_level_1d damp_level_1d]). This parameter is only in effect if the 1d-model is switched on for the initialization of the 3d-model with [#initializing_actions initializing_actions] = '' 'set_1d-model_profiles'.'' }}} |---------------- {{{#!td style="vertical-align:top" [=#initializing_actions '''initializing_actions'''] }}} {{{#!td style="vertical-align:top" C*100 }}} {{{#!td style="vertical-align:top" }}} {{{#!td Initialization actions to be carried out.\\\\ This parameter does not have a default value and therefore must be assigned with each model run. For restart runs '''initializing_actions''' = '' 'read_restart_data' '' must be set. For the initial run of a job chain the following values are allowed:\\\\ '' 'set_constant_profiles' ''\\\\ A horizontal wind profile consisting of linear sections (see [#ug_surface ug_surface], [#ug_vertical_gradient ug_vertical_gradient], [#ug_vertical_gradient_level ug_vertical_gradient_level] and [#vg_surface vg_surface], [#vg_vertical_gradient vg_vertical_gradient], [#vg_vertical_gradient_level vg_vertical_gradient_level], respectively) as well as a vertical temperature (humidity) profile consisting of linear sections (see [#pt_surface pt_surface], [#pt_vertical_gradient pt_vertical_gradient], [#q_surface q_surface] and [#q_vertical_gradient q_vertical_gradient]) are assumed as initial profiles. The subgrid-scale TKE is set to 0 but K,,m,, and K,,h,, are set to very small values because otherwise no TKE would be generated.\\\\ '' 'set_1d-model_profiles' ''\\\\ The arrays of the 3d-model are initialized with the (stationary) solution of the [../../tec/1dmodel 1d-model]. These are the variables e, K,,h,,{{{,}}} K,,m,,{{{,}}} u, v and with Prandtl layer switched on rif, us, usws, vsws. The temperature (humidity) profile consisting of linear sections is set as for '' 'set_constant_profiles' '' and assumed as constant in time within the 1d-model. For steering of the 1d-model a set of parameters with suffix "_1d" (e.g. [#end_time_1d end_time_1d], [#damp_level_1d damp_level_1d]) is available.\\\\ '' 'by_user' ''\\\\ The initialization of the arrays of the 3d-model is under complete control of the user and has to be done in routine {{{user_init_3d_model}}} of the [../userint user-interface].\\\\ '' 'initialize_vortex' ''\\\\ The initial velocity field of the 3d-model corresponds to a Rankine-vortex with vertical axis. This setting may be used to test advection schemes. Free-slip boundary conditions for u and v (see [#bc_uv_b bc_uv_b], [#bc_uv_t bc_uv_t]) are necessary. In order not to distort the vortex, an initial horizontal wind profile constant with height is necessary (to be set by [#initializing_actions initializing_actions] = '' 'set_constant_profiles{{{'}}}'') and some other conditions have to be met (neutral stratification, diffusion must be switched off, see [#km_constant km_constant]). The center of the vortex is located at jc = ([#nx nx]+1)/2. It extends from k = 0 to k = [#nz nz]+1. Its radius is 8 * [#dx dx] and the exponentially decaying part ranges to 32 * dx (see {{{init_rankine.f90}}}).\\\\ '' 'initialize_ptanom' ''\\\\ A 2d-Gauss-like shape disturbance (x,y) is added to the initial temperature field with radius 10.0 * [#dx dx] and center at jc = ([#nx nx]+1)/2. This may be used for tests of scalar advection schemes (see [#scalar_advec scalar_advec]). Such tests require a horizontal wind profile constant with hight and diffusion switched off (see '' 'initialize_vortex' ''). Additionally, the buoyancy term must be switched of in the equation of motion for w (this requires the user to comment out the call of buoyancy in the source code of {{{prognostic_equations.f90}}}).\\\\ '' 'cyclic_fill' ''\\\\ Here, 3d-data from a precursor run are read by the initial (main) run. The precursor run is allowed to have a smaller domain along x and y compared with the main run. Also, different numbers of processors can be used for these two runs. Limitations are that the precursor run must use cyclic horizontal boundary conditions and that the number of vertical grid points, [#nz nz], must be same for the precursor run and the main run. If the total domain of the main run is larger than that of the precursor run, the domain is filled by cyclic repetition of the (cyclic) precursor data. This initialization method is recommended if a turbulent inflow is used (see [#turbulent_inflow turbulent_inflow]). 3d-data must be made available to the run by activating an appropriate file connection statement for local file [../iofiles#BININ BININ]. The usage of a turbulent inflow is explained [../examples/turbinf here].\\\\ Values may be combined, e.g. '''initializing_actions''' = '' 'set_constant_profiles initialize_vortex' '', but the values of '' 'set_constant_profiles' '', '' 'set_1d-model_profiles' '' , and '' 'by_user' '' must not be given at the same time. }}} |---------------- {{{#!td style="vertical-align:top" [=#mixing_length_1d '''mixing_length_1d'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'as_in_3d_model' }}} {{{#!td Mixing length used in the [../../tec/1dmodel 1d-model].\\\\ By default the mixing length is calculated as in the 3d-model (i.e. it depends on the grid spacing).\\\\ By setting '''mixing_length_1d''' = '' 'blackadar','' the so-called Blackadar mixing length is used (l = kappa * z / ( 1 + kappa * z / lambda ) with the limiting value lambda = 2.7E-4 * u_g / f). }}} |---------------- {{{#!td style="vertical-align:top" [=#pt_surface '''pt_surface'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 300.0 }}} {{{#!td Surface potential temperature (in K).\\\\ This parameter assigns the value of the potential temperature '''pt''' at the surface (k=0). Starting from this value, the initial vertical temperature profile is constructed with [#pt_vertical_gradient pt_vertical_gradient] and [#pt_vertical_gradient_level pt_vertical_gradient_level]. This profile is also used for the [../../tec/1dmodel 1d-model] as a stationary profile.\\\\ '''Attention:'''\\ In case of ocean runs (see [#ocean ocean]), this parameter gives the temperature value at the sea surface, which is at k=[#nzt nzt]. The profile is then constructed from the surface down to the bottom of the model. }}} |---------------- {{{#!td style="vertical-align:top" [=#pt_surface_initial_change '''pt_surface_initial_change'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Change in surface temperature to be made at the beginning of the 3d run (in K).\\\\ If '''pt_surface_initial_change''' is set to a non-zero value, the near surface sensible heat flux is not allowed to be given simultaneously (see [#surface_heatflux surface_heatflux]). }}} |---------------- {{{#!td style="vertical-align:top" [=#pt_vertical_gradient '''pt_vertical_gradient'''] }}} {{{#!td style="vertical-align:top" R(10) }}} {{{#!td style="vertical-align:top" 10*0.0 }}} {{{#!td Temperature gradient(s) of the initial temperature profile (in K / 100 m).\\\\ This temperature gradient holds starting from the height level defined by [#pt_vertical_gradient_level pt_vertical_gradient_level] (precisely: for all uv levels k where zu(k) > pt_vertical_gradient_level, pt_init(k) is set: pt_init(k) = pt_init(k-1) + dzu(k) * '''pt_vertical_gradient''') up to the top boundary or up to the next height level defined by pt_vertical_gradient_level. A total of 10 different gradients for 11 height intervals (10 intervals if pt_vertical_gradient_level(1) = 0.0) can be assigned. The surface temperature is assigned via [#pt_surface pt_surface].\\\\ '''Example:'''\\\\ '''pt_vertical_gradient''' = ''1.0'', ''0.5'',\\ [#pt_vertical_gradient_level pt_vertical_gradient_level] = ''500.0'', ''1000.0'',\\\\ That defines the temperature profile to be neutrally stratified up to z = 500.0 m with a temperature given by [#pt_surface pt_surface]. For 500.0 m < z <= 1000.0 m the temperature gradient is 1.0 K / 100 m and for z > 1000.0 m up to the top boundary it is 0.5 K / 100 m (it is assumed that the assigned height levels correspond with uv levels).\\\\ '''Attention:'''\\ In case of ocean runs (see [#ocean ocean]), the profile is constructed like described above, but starting from the sea surface (k=[#nzt nzt]) down to the bottom boundary of the model. Height levels have then to be given as negative values, e.g. pt_vertical_gradient_level = ''-500.0,'' ''-1000.0.'' }}} |---------------- {{{#!td style="vertical-align:top" [=#pt_vertical_gradient_level '''pt_vertical_gradient_level'''] }}} {{{#!td style="vertical-align:top" R(10) }}} {{{#!td style="vertical-align:top" 10*0.0 }}} {{{#!td Height level from which on the temperature gradient defined by [#pt_vertical_gradient pt_vertical_gradient] is effective (in m).\\\\ The height levels have to be assigned in ascending order. The default values result in a neutral stratification regardless of the values of pt_vertical_gradient (unless the top boundary of the model is higher than 100000.0 m). For the piecewise construction of temperature profiles see [#pt_vertical_gradient pt_vertical_gradient].\\\\ '''Attention:'''\\ In case of ocean runs (see [#ocean ocean]), the (negative) height levels have to be assigned in descending order. }}} |---------------- {{{#!td style="vertical-align:top" [=#q_surface '''q_surface'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Surface specific humidity / total water content (kg/kg).\\\\ This parameter assigns the value of the specific humidity '''q''' at the surface (k=0). Starting from this value, the initial humidity profile is constructed with [#q_vertical_gradient q_vertical_gradient] and [#q_vertical_gradient_level q_vertical_gradient_level]. This profile is also used for the [../../tec/1dmodel 1d-model] as a stationary profile. }}} |---------------- {{{#!td style="vertical-align:top" [=#q_surface_initial_change '''q_surface_initial_change'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Change in surface specific humidity / total water content to be made at the beginning of the 3d run (kg/kg).\\\\ If '''q_surface_initial_change''' is set to a non-zero value the near surface latent heat flux (water flux) is not allowed to be given simultaneously (see [#surface_waterflux surface_waterflux]). }}} |---------------- {{{#!td style="vertical-align:top" [=#q_vertical_gradient '''q_vertical_gradient'''] }}} {{{#!td style="vertical-align:top" R(10) }}} {{{#!td style="vertical-align:top" 10 * 0.0 }}} {{{#!td Humidity gradient(s) of the initial humidity profile (in 1/100 m).\\\\ This humidity gradient holds starting from the height level defined by [#q_vertical_gradient_level q_vertical_gradient_level] (precisely: for all uv levels k, where zu(k) > q_vertical_gradient_level, q_init(k) is set: q_init(k) = q_init(k-1) + dzu(k) * '''q_vertical_gradient''') up to the top boundary or up to the next height level defined by q_vertical_gradient_level. A total of 10 different gradients for 11 height intervals (10 intervals if q_vertical_gradient_level(1) = 0.0) can be asigned. The surface humidity is assigned via [#q_surface q_surface].\\\\ '''Example:'''\\\\ '''q_vertical_gradient''' = ''0.001,'' ''0.0005,''\\ [#q_vertical_gradient_level q_vertical_gradient_level] = ''500.0,'' ''1000.0,''\\\\ That defines the humidity to be constant with height up to z = 500.0 m with a value given by q_surface. For 500.0 m < z <= 1000.0 m the humidity gradient is 0.001 / 100 m and for z > 1000.0 m up to the top boundary it is 0.0005 / 100 m (it is assumed that the assigned height levels correspond with uv levels). }}} |---------------- {{{#!td style="vertical-align:top" [=#q_vertical_gradient_level '''q_vertical_gradient_level'''] }}} {{{#!td style="vertical-align:top" R(10) }}} {{{#!td style="vertical-align:top" 10 * 0.0 }}} {{{#!td Height level from which on the humidity gradient defined by [#q_vertical_gradient q_vertical_gradient] is effective (in m).\\\\ The height levels are to be assigned in ascending order. The default values result in a humidity constant with height regardless of the values of q_vertical_gradient (unless the top boundary of the model is higher than 100000.0 m). For the piecewise construction of humidity profiles see [#q_vertical_gradient q_vertical_gradient]. }}} |---------------- {{{#!td style="vertical-align:top" [=#sa_surface '''sa_surface'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 35.0 }}} {{{#!td Surface salinity (in psu).\\\\ This parameter only comes into effect for ocean runs (see parameter [#ocean ocean]).\\\\ This parameter assigns the value of the salinity '''sa''' at the sea surface (k=[#nzt nzt]). Starting from this value, the initial vertical salinity profile is constructed from the surface down to the bottom of the model (k=0) by using [#sa_vertical_gradient sa_vertical_gradient] and [#sa_vertical_gradient_level sa_vertical_gradient_level]. }}} |---------------- {{{#!td style="vertical-align:top" [=#surface_pressure '''surface_pressure'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 1013.25 }}} {{{#!td Atmospheric pressure at the surface (in hPa).\\\\ Starting from this surface value, the vertical pressure profile is calculated once at the beginning of the run assuming a neutrally stratified atmosphere. This is needed for converting between the liquid water potential temperature and the potential temperature (see [#cloud_physics cloud_physics]). }}} |---------------- {{{#!td style="vertical-align:top" [=#s_surface '''s_surface'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Surface value of the passive scalar (in kg/m^3^).\\\\ This parameter assigns the value of the passive scalar '''s''' at the surface (k=0). Starting from this value, the initial vertical scalar concentration profile is constructed with [#s_vertical_gradient s_vertical_gradient] and [#s_vertical_gradient_level s_vertical_gradient_level]. }}} |---------------- {{{#!td style="vertical-align:top" [=#s_surface_initial_change '''s_surface_initial_change'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Change in surface scalar concentration to be made at the beginning of the 3d run (in kg/m^3^).\\\\ If '''s_surface_initial_change''' is set to a non-zero value, the near surface scalar flux is not allowed to be given simultaneously (see [#surface_scalarflux surface_scalarflux]). }}} |---------------- {{{#!td style="vertical-align:top" [=#s_vertical_gradient '''s_vertical_gradient'''] }}} {{{#!td style="vertical-align:top" R(10) }}} {{{#!td style="vertical-align:top" 10 * 0.0 }}} {{{#!td Scalar concentration gradient(s) of the initial scalar concentration profile (in kg/m^3^ / 100 m).\\\\ The scalar gradient holds starting from the height level defined by [#s_vertical_gradient_level s_vertical_gradient_level] (precisely: for all uv levels k, where zu(k) > s_vertical_gradient_level, s_init(k) is set: s_init(k) = s_init(k-1) + dzu(k) * '''s_vertical_gradient''') up to the top boundary or up to the next height level defined by s_vertical_gradient_level. A total of 10 different gradients for 11 height intervals (10 intervals if s_vertical_gradient_level(1) = 0.0) can be assigned. The surface scalar value is assigned via [#s_surface s_surface].\\\\ '''Example:'''\\\\ '''s_vertical_gradien'''t = ''0.1,'' ''0.05,''\\ [#s_vertical_gradient_level s_vertical_gradient_level] = ''500.0,'' ''1000.0,''\\\\ That defines the scalar concentration to be constant with height up to z = 500.0 m with a value given by. For 500.0 m < z <= 1000.0 m the scalar gradient is 0.1 kg/m^3^ / 100 m and for z > 1000.0 m up to the top boundary it is 0.05 kg/m^3^ / 100 m (it is assumed that the assigned height levels correspond with uv levels). }}} |---------------- {{{#!td style="vertical-align:top" [=#s_vertical_gradient_level '''s_vertical_gradient_level'''] }}} {{{#!td style="vertical-align:top" R(10) }}} {{{#!td style="vertical-align:top" 10 * 0.0 }}} {{{#!td Height level from which on the scalar gradient defined by [#s_vertical_gradient s_vertical_gradient] is effective (in m).\\\\ The height levels are to be assigned in ascending order. The default values result in a scalar concentration constant with height regardless of the values of s_vertical_gradient (unless the top boundary of the model is higher than 100000.0 m). For the piecewise construction of scalar concentration profiles see [#s_vertical_gradient s_vertical_gradient]. }}} |---------------- {{{#!td style="vertical-align:top" [=#ug_surface '''ug_surface'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td u-component of the geostrophic wind at the surface (in m/s).\\\\ This parameter assigns the value of the u-component of the geostrophic wind ('''ug''') at the surface (k=0). Starting from this value, the initial vertical profile of the u-component of the geostrophic wind is constructed with [#ug_vertical_gradient ug_vertical_gradient] and [#ug_vertical_gradient_level ug_vertical_gradient_level]. The profile constructed in that way is used for creating the initial vertical velocity profile of the 3d-model. Either it is applied, as it has been specified by the user ([#initializing_actions initializing_actions] = '' 'set_constant_profiles' '') or it is used for calculating a stationary boundary layer wind profile ([#initializing_actions initializing_actions] = '' 'set_1d-model_profiles' ''). If '''ug''' is constant with height (i.e. '''ug'''(k) = '''ug_surface''') and has a large value, it is recommended to use a Galilei-transformation of the coordinate system, if possible (see [#galilei_transformation galilei_transformation]), in order to obtain larger time steps.\\\\ '''Attention:'''\\ In case of ocean runs (see [#ocean ocean]), this parameter gives the geostrophic velocity value (i.e. the pressure gradient) at the sea surface, which is at k=[#nzt nzt]. The profile is then constructed from the surface down to the bottom of the model. }}} |---------------- {{{#!td style="vertical-align:top" [=#ug_vertical_gradient '''ug_vertical_gradient'''] }}} {{{#!td style="vertical-align:top" R(10) }}} {{{#!td style="vertical-align:top" 10 * 0.0 }}} {{{#!td Gradient(s) of the initial profile of the u-component of the geostrophic wind (in 1/100s).\\\\ The gradient holds starting from the height level defined by [#ug_vertical_gradient_level ug_vertical_gradient_level] (precisely: for all uv levels k where zu(k) > ug_vertical_gradient_level, ug(k) is set: ug(k) = ug(k-1) + dzu(k) * '''ug_vertical_gradient''') up to the top boundary or up to the next height level defined by ug_vertical_gradient_level. A total of 10 different gradients for 11 height intervals (10 intervals if ug_vertical_gradient_level(1) = 0.0) can be assigned. The surface geostrophic wind is assigned by [#ug_surface ug_surface].\\\\ '''Attention:'''\\ In case of ocean runs (see [#ocean ocean]), the profile is constructed like described above, but starting from the sea surface (k=[#nzt nzt]) down to the bottom boundary of the model. Height levels have then to be given as negative values, e.g. [#ug_vertical_gradient_level ug_vertical_gradient_level] = ''-500.0,'' ''-1000.0.'' }}} |---------------- {{{#!td style="vertical-align:top" [=#ug_vertical_gradient_level '''ug_vertical_gradient_level'''] }}} {{{#!td style="vertical-align:top" R(10) }}} {{{#!td style="vertical-align:top" 10 * 0.0 }}} {{{#!td Height level from which on the gradient defined by [#ug_vertical_gradient ug_vertical_gradient] is effective (in m).\\\\ The height levels have to be assigned in ascending order. For the piecewise construction of a profile of the u-component of the geostrophic wind component (ug) see [#ug_vertical_gradient ug_vertical_gradient].\\\\ '''Attention:'''\\ In case of ocean runs (see [#ocean ocean]), the (negative) height levels have to be assigned in descending order. }}} |---------------- {{{#!td style="vertical-align:top" [=#vg_surface '''vg_surface'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td v-component of the geostrophic wind at the surface (in m/s).\\\\ This parameter assigns the value of the v-component of the geostrophic wind ('''vg''') at the surface (k=0). Starting from this value, the initial vertical profile of the v-component of the geostrophic wind is constructed with [#vg_vertical_gradient vg_vertical_gradient] and [#vg_vertical_gradient_level vg_vertical_gradient_level]. The profile constructed in that way is used for creating the initial vertical velocity profile of the 3d-model. Either it is applied, as it has been specified by the user ([#initializing_actions initializing_actions] = '' 'set_constant_profiles' '') or it is used for calculating a stationary boundary layer wind profile ([#initializing_actions initializing_actions] = '' 'set_1d-model_profiles' ''). If '''vg''' is constant with height (i.e. '''vg'''(k)='''vg_surface''') and has a large value, it is recommended to use a Galilei-transformation of the coordinate system, if possible (see [#galilei_transformation galilei_transformation]), in order to obtain larger time steps.\\\\ '''Attention:'''\\ In case of ocean runs (see [#ocean ocean]), this parameter gives the geostrophic velocity value (i.e. the pressure gradient) at the sea surface, which is at k=[#nzt nzt]. The profile is then constructed from the surface down to the bottom of the model. }}} |---------------- {{{#!td style="vertical-align:top" [=#vg_vertical_gradient '''vg_vertical_gradient'''] }}} {{{#!td style="vertical-align:top" R(10) }}} {{{#!td style="vertical-align:top" 10 * 0.0 }}} {{{#!td Gradient(s) of the initial profile of the v-component of the geostrophic wind (in 1/100s).\\\\ The gradient holds starting from the height level defined by [#vg_vertical_gradient_level vg_vertical_gradient_level] (precisely: for all uv levels k where zu(k) > vg_vertical_gradient_level, vg(k) is set: vg(k) = vg(k-1) + dzu(k) * '''vg_vertical_gradient''') up to the top boundary or up to the next height level defined by vg_vertical_gradient_level. A total of 10 different gradients for 11 height intervals (10 intervals if vg_vertical_gradient_level(1) = 0.0) can be assigned. The surface geostrophic wind is assigned by [#vg_surface vg_surface].\\\\ '''Attention:'''\\ In case of ocean runs (see [#ocean ocean]), the profile is constructed like described above, but starting from the sea surface (k=[#nzt nzt]) down to the bottom boundary of the model. Height levels have then to be given as negative values, e.g. [#vg_vertical_gradient_level vg_vertical_gradient_level] = ''-500.0,'' ''-1000.0.'' }}} |---------------- {{{#!td style="vertical-align:top" [=#vg_vertical_gradient_level '''vg_vertical_gradient_level'''] }}} {{{#!td style="vertical-align:top" R(10) }}} {{{#!td style="vertical-align:top" 10 * 0.0 }}} {{{#!td Height level from which on the gradient defined by [#vg_vertical_gradient vg_vertical_gradient] is effective (in m).\\\\ The height levels have to be assigned in ascending order. For the piecewise construction of a profile of the v-component of the geostrophic wind component (vg) see [#vg_vertical_gradient vg_vertical_gradient].\\\\ '''Attention:'''\\ In case of ocean runs (see [#ocean ocean]), the (negative) height levels have to be assigned in descending order. }}} [[BR]] [=#topo '''Topography:]\\ ||='''Parameter Name''' =||='''[../fortrantypes FORTRAN]\\[../fortrantypes Type]''' =||='''Default\\Value''' =||='''Explanation''' =|| |---------------- {{{#!td style="vertical-align:top; text-align:left;width: 150px" [=#building_height '''building_height'''] }}} {{{#!td style="vertical-align:top; text-align:left;style="width: 50px" R }}} {{{#!td style="vertical-align:top; text-align:left;style="width: 75px" 50.0 }}} {{{#!td Height of a single building in m.\\\\ '''building_height''' must be less than the height of the model domain. This parameter requires the use of [#topography topography] = '' 'single_building'.'' }}} |---------------- {{{#!td style="vertical-align:top" [=#building_length_x '''building_length_x'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 50.0 }}} {{{#!td Width of a single building in m.\\\\ Currently, '''building_length_x''' must be at least 3 * [#dx dx] and no more than ( [#nx nx] - 1 ) * dx - [#building_wall_left building_wall_left]. This parameter requires the use of [#topography topography] = '' 'single_building'.'' }}} |---------------- {{{#!td style="vertical-align:top" [=#building_length_y '''building_length_y'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 50.0 }}} {{{#!td Depth of a single building in m.\\\\ Currently, '''building_length_y''' must be at least 3 * [#dy dy] and no more than ( [#ny ny] - 1 ) * dy - [#building_wall_south building_wall_south]. This parameter requires the use of [#topography topography] = '' 'single_building'.'' }}} |---------------- {{{#!td style="vertical-align:top" [=#building_wall_left '''building_wall_left'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" building centered in x-direction }}} {{{#!td x-coordinate of the left building wall (distance between the left building wall and the left border of the model domain) in m.\\\\ Currently, '''building_wall_left''' must be at least 1 * [#dx dx] and less than ( [#nx nx] - 1 ) * dx - [#building_length_x building_length_x]. This parameter requires the use of [#topography topography] = '' 'single_building'.''\\\\ The default value '''building_wall_left''' = ( ( nx + 1 ) * dx - building_length_x ) / 2 centers the building in x-direction. Due to the staggered grid the building will be displaced by -0.5 dx in x-direction and -0.5 [#dy dy] in y-direction. }}} |---------------- {{{#!td style="vertical-align:top" [=#building_wall_south '''building_wall_south'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" building centered in y-direction }}} {{{#!td y-coordinate of the South building wall (distance between the South building wall and the South border of the model domain) in m.\\\\ Currently, '''building_wall_south''' must be at least 1 * [#dy dy] and less than ( [#ny ny] - 1 ) * dy - [#building_length_y building_length_y]. This parameter requires the use of [#topography topography] = '' 'single_building'.''\\\\ The default value '''building_wall_south''' = ( ( ny + 1 ) * dy - building_length_y ) / 2 centers the building in y-direction. Due to the staggered grid the building will be displaced by -0.5 [#dx dx] in x-direction and -0.5 dy in y-direction. }}} |---------------- {{{#!td style="vertical-align:top" [=#canyon_height '''canyon_height'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 50.0 }}} {{{#!td Street canyon height in m.\\\\ '''canyon_height''' must be less than the height of the model domain. This parameter requires [#topography topography] = '' 'single_street_canyon'.'' }}} |---------------- {{{#!td style="vertical-align:top" [=#canyon_width_x '''canyon_width_x'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 9999999.9 }}} {{{#!td Street canyon width in x-direction in m.\\\\ Currently, '''canyon_width_x''' must be at least 3 * [#dx dx] and no more than ( [#nx nx] - 1 ) * dx - [#canyon_wall_left canyon_wall_left]. This parameter requires [#topography topography] = '' 'single_street_canyon'.'' A non-default value implies a canyon orientation in y-direction. }}} |---------------- {{{#!td style="vertical-align:top" [=#canyon_width_y '''canyon_width_y'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 9999999.9 }}} {{{#!td Street canyon width in y-direction in m.\\\\ Currently, '''canyon_width_y''' must be at least 3 * [#dy dy] and no more than ( [#ny ny] - 1 ) * dy - [#canyon_wall_south canyon_wall_south]. This parameter requires [#topography topography] = '' 'single_street_canyon'.'' A non-default value implies a canyon orientation in x-direction. }}} |---------------- {{{#!td style="vertical-align:top" [=#canyon_wall_left '''canyon_wall_left'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" canyon centered in x-direction }}} {{{#!td x-coordinate of the left canyon wall (distance between the left canyon wall and the left border of the model domain) in m.\\\\ Currently, '''canyon_wall_left''' must be at least 1 * [#dx dx] and less than ( [#nx nx] - 1 ) * dx - [#canyon_width_x canyon_width_x]. This parameter requires [#topography topography] = '' 'single_street_canyon'.''\\\\ The default value '''canyon_wall_left''' = ( ( nx + 1 ) * dx - canyon_width_x ) / 2 centers the canyon in x-direction. }}} |---------------- {{{#!td style="vertical-align:top" [=#canyon_wall_south '''canyon_wall_south'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" canyon centered in y-direction }}} {{{#!td y-coordinate of the South canyon wall (distance between the South canyon wall and the South border of the model domain) in m.\\\\ Currently, '''canyon_wall_south''' must be at least 1 * [#dy dy] and less than ( [#ny ny] - 1 ) * dy - [#canyon_width_y canyon_width_y]. This parameter requires [#topography topography] = '' 'single_street_canyon'.''\\\\ The default value '''canyon_wall_south''' = ( ( ny + 1 ) * dy - canyon_width_y ) / 2 centers the canyon in y-direction. }}} |---------------- {{{#!td style="vertical-align:top" [=#topography '''topography'''] }}} {{{#!td style="vertical-align:top" C*40 }}} {{{#!td style="vertical-align:top" '' 'flat' '' }}} {{{#!td Topography mode.\\\\ The user can choose between the following modes:\\\\ '' 'flat' '' Flat surface. '' 'single_building' '' Flow around a single rectangular building mounted on a flat surface. The building size and location can be specified by the parameters [#building_height building_height], [#building_length_x building_length_x], [#building_length_y building_length_y], [#building_wall_left building_wall_left] and [#building_wall_south building_wall_south]. '' 'single_street_canyon' '' Flow over a single, quasi-2D street canyon of infinite length oriented either in x- or in y-direction. The canyon size, orientation and location can be specified by the parameters [#canyon_height canyon_height] plus '''either''' [#canyon_width_x canyon_width_x] and [#canyon_wall_left canyon_wall_left] '''or''' [#canyon_width_y canyon_width_y] and [#canyon_wall_south canyon_wall_south]. '' 'read_from_file' '' Flow around arbitrary topography. This mode requires the input file [#TOPOGRAPHY_DATA TOPOGRAPHY_DATA]. This file contains the arbitrary topography height information in m. These data must exactly match the horizontal grid.\\\\ Alternatively, the user may add code to the user interface subroutine [#user_init_grid user_init_grid] to allow further topography modes. These require to explicitly set the [#topography_grid_convention topography_grid_convention] to either '' 'cell_edge' '' or '' 'cell_center' ''.\\\\ Non-flat '''topography''' modes may assign a kinematic sensible [#wall_heatflux wall_heatflux] and a kinematic [#wall_humidityflux wall_humidityflux] (requires [#humidity humidity] = .T.) or a [#wall_scalarflux wall_scalarflux] (requires [#passive_scalar passive_scalar] = .T.) at the five topography faces.\\\\ All non-flat '''topography''' modes require the use of [#momentum_advec momentum_advec] = [#scalar_advec scalar_advec] = '' 'pw-scheme' '', [#psolver psolver] /= '' 'sor' '', [#alpha_surface alpha_surface] = 0.0, [#galilei_transformation galilei_transformation] = ''.F.'', [#cloud_physics cloud_physics] = ''.F.'', [#cloud_droplets cloud_droplets] = ''.F.'', and [#prandtl_layer prandtl_layer] = ''.T.''.\\\\ Note that an inclined model domain requires the use of [#topography topography] = '' 'flat' '' and a nonzero alpha_surface. }}} |---------------- {{{#!td style="vertical-align:top" [=#topography_grid_convention '''topography_grid_convention'''] }}} {{{#!td style="vertical-align:top" C*11 }}} {{{#!td style="vertical-align:top" default depends on value of [#topography topography]; see text for details }}} {{{#!td Convention for defining the topography grid.\\\\ Possible values are\\\\ '' 'cell_edge' ''\\\\ The distance between cell edges defines the extent of topography. This setting is normally for generic topographies, i.e. topographies that are constructed using length parameters. For example, [#topography topography] = '' 'single_building' '' is constructed using [#building_length_x building_length_x] and [#building_length_y building_length_y]. The advantage of this setting is that the actual size of generic topography is independent of the grid size, provided that the length parameters are an integer multiple of the grid lengths [#dx dx] and [#dy dy]. This is convenient for resolution parameter studies.\\\\ '' 'cell_center' ''\\\\ The number of topography cells define the extent of topography. This setting is normally for rastered real topographies derived from digital elevation models. For example, [#topography topography] = '' 'read_from_file' '' is constructed using the input file [../iofiles#TOPOGRAPHY_DATA TOPOGRAPHY_DATA]. The advantage of this setting is that the rastered topography cells of the input file are directly mapped to topography grid boxes in PALM.\\\\ The example files {{{example_topo_file}}} and {{{example_building}}} in trunk/EXAMPLES/ illustrate the difference between both approaches. Both examples simulate a single building and yield the same results. The former uses a rastered topography input file with '' 'cell_center' '' convention, the latter applies a generic topography with '' 'cell_edge' '' convention.\\\\ The default value is\\\\ * '' 'cell_edge' '' if [#topography topography] = '' 'single_building' '' or '' 'single_street_canyon',''\\ * '' 'cell_center' '' if [#topography topography] = '' 'read_from_file',''\\ * none (' ' ) otherwise, leading to an abort if '''topography_grid_convention''' is not set.\\\\ This means that\\\\ * For PALM simulations using a user-defined topography, the '''topography_grid_convention''' must be explicitly set to either '' 'cell_edge' '' or '' 'cell_center'.''\\ * For PALM simulations using a standard topography ('' 'single_building','' '' 'single_street_canyon' '' or '' 'read_from_file' ''), it is possible but not required to set the '''topography_grid_convention''' because appropriate default values apply. }}} |---------------- {{{#!td style="vertical-align:top" [=#wall_heatflux '''wall_heatflux'''] }}} {{{#!td style="vertical-align:top" R(5) }}} {{{#!td style="vertical-align:top" 5 * 0.0 }}} {{{#!td Prescribed kinematic sensible heat flux in K m/s at the five topography faces:\\\\ '''wall_heatflux'''(0) top face\\ '''wall_heatflux'''(1) left face\\ '''wall_heatflux'''(2) right face\\ '''wall_heatflux'''(3) south face\\ '''wall_heatflux'''(4) north face\\\\ This parameter applies only in case of a non-flat topography. The parameter [#random_heatflux random_heatflux] can be used to impose random perturbations on the internal two-dimensional surface heat flux field '''shf''' that is composed of [#surface_heatflux surface_heatflux] at the bottom surface and '''wall_heatflux'''(0) at the topography top face. }}} |---------------- {{{#!td style="vertical-align:top" [=#wall_humidityflux '''wall_humidityflux'''] }}} {{{#!td style="vertical-align:top" R(5) }}} {{{#!td style="vertical-align:top" 5 * 0.0 }}} {{{#!td Prescribed kinematic humidity flux in m/s at the five topography faces:\\\\ '''wall_humidityflux'''(0) top face\\ '''wall_humidityflux'''(1) left face\\ '''wall_humidityflux'''(2) right face\\ '''wall_humidityflux'''(3) south face\\ '''wall_humidityflux'''(4) north face\\\\ This parameter applies only in case of a non-flat topography and [#humidity humidity] = ''.T.''. }}} |---------------- {{{#!td style="vertical-align:top" [=#wall_scalarflux '''wall_scalarflux'''] }}} {{{#!td style="vertical-align:top" R(5) }}} {{{#!td style="vertical-align:top" 5 * 0.0 }}} {{{#!td Prescribed scalar flux in kg/(m^2^ s) at the five topography faces:\\\\ '''wall_scalarflux'''(0) top face\\ '''wall_scalarflux'''(1) left face\\ '''wall_scalarflux'''(2) right face\\ '''wall_scalarflux'''(3) south face\\ '''wall_scalarflux'''(4) north face\\\\ This parameter applies only in case of a non-flat topography and [#passive_scalar passive_scalar] = ''.T.''. }}} [[BR]] [=#canopy '''Canopy:]\\ ||='''Parameter Name''' =||='''[../fortrantypes FORTRAN]\\[../fortrantypes Type]''' =||='''Default\\Value''' =||='''Explanation''' =|| |---------------- {{{#!td style="vertical-align:top;width: 150px" [=#canopy_mode '''canopy_mode'''] }}} {{{#!td style="vertical-align:top;width: 50px" C*20 }}} {{{#!td style="vertical-align:top;width: 75px" 'block' }}} {{{#!td Canopy mode.\\\\ Besides using the default value, that will create a horizontally homogeneous plant canopy that extends over the total horizontal extension of the model domain, the user may add code to the user interface (see [#3.5.1 3.5.1]) subroutine {{{user_init_plant_canopy}}} to allow further canopy modes.\\\\ The setting of '''canopy_mode''' becomes only active, if [#plant_canopy plant_canopy] has been set ''.T.'' and a non-zero [#drag_coefficient drag_coefficient] has been defined. }}} |---------------- {{{#!td style="vertical-align:top" [=#cthf '''cthf'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Average heat flux that is prescribed at the top of the plant canopy.\\\\ If [#plant_canopy plant_canopy] is set ''.T.'', the user can prescribe a heat flux at the top of the plant canopy. It is assumed that solar radiation penetrates the canopy and warms the foliage which, in turn, warms the air in contact with it.\\\\ '''Note:'''\\ Instead of using the value prescribed by [#surface_heatflux surface_heatflux], the near surface heat flux is determined from an exponential function that is dependent on the cumulative leaf_area_index (Shaw and Schumann (1992, Boundary Layer Meteorol., 61, 47-64)). }}} |---------------- {{{#!td style="vertical-align:top" [=#drag_coefficient '''drag_coefficient'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Drag coefficient used in the {{{plant_canopy_model}}}.\\\\ This parameter has to be non-zero, if the parameter [#plant_canopy plant_canopy] is set ''.T.''. }}} |---------------- {{{#!td style="vertical-align:top" [=#lad_surface '''lad_surface'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Surface value of the leaf area density (in m^2^/m^3^).\\\\ This parameter assigns the value of the leaf area density '''lad''' at the surface (k=0). Starting from this value, the leaf area density profile is constructed with [#lad_vertical_gradient lad_vertical_gradient] and [#lad_vertical_gradient_level lad_vertical_gradient_level]. }}} |---------------- {{{#!td style="vertical-align:top" [=#lad_vertical_gradient '''lad_vertical_gradient'''] }}} {{{#!td style="vertical-align:top" R(10) }}} {{{#!td style="vertical-align:top" 10 * 0.0 }}} {{{#!td Gradient(s) of the leaf area density (in m^2^/m^4^).\\\\ This leaf area density gradient holds starting from the height level defined by [#lad_vertical_gradient_level lad_vertical_gradient_level] (precisely: for all uv levels k where zu(k) > lad_vertical_gradient_level, lad(k) is set: lad(k) = lad(k-1) + dzu(k) * '''lad_vertical_gradient''') up to the level defined by [#pch_index pch_index]. Above that level lad(k) will automatically be set to 0.0. A total of 10 different gradients for 11 height intervals (10 intervals if lad_vertical_gradient_level(1) = 0.0) can be assigned. The leaf area density at the surface is assigned via [#lad_surface lad_surface]. }}} |---------------- {{{#!td style="vertical-align:top" [=#lad_vertical_gradient_level '''lad_vertical_gradient_level'''] }}} {{{#!td style="vertical-align:top" R(10) }}} {{{#!td style="vertical-align:top" 10 * 0.0 }}} {{{#!td Height level from which on the gradient of the leaf area density defined by [#lad_vertical_gradient lad_vertical_gradient] is effective (in m).\\\\ The height levels have to be assigned in ascending order. The default values result in a leaf area density that is constant with height up to the top of the plant canopy layer defined by [#pch_index pch_index]. For the piecewise construction of temperature profiles see [#lad_vertical_gradient lad_vertical_gradient]. }}} |---------------- {{{#!td style="vertical-align:top" [=#leaf_surface_concentration '''leaf_surface_concentration'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Concentration of a passive scalar at the surface of a leaf (in K m/s).\\\\ This parameter is only of importance in cases in that both, [#plant_canopy plant_canopy] and [#passive_scalar passive_scalar], are set ''.T..'' The value of the concentration of a passive scalar at the surface of a leaf is required for the parametrisation of the sources and sinks of scalar concentration due to the canopy. }}} |---------------- {{{#!td style="vertical-align:top" [=#pch_index '''pch_index'''] }}} {{{#!td style="vertical-align:top" I }}} {{{#!td style="vertical-align:top" 0 }}} {{{#!td Grid point index (scalar) of the upper boundary of the plant canopy layer.\\\\ Above '''pch_index''' the arrays of leaf area density and [#drag_coeffient drag_coeffient] are automatically set to zero in case of [#plant_canopy plant_canopy] = ''.T.''. Up to '''pch_index''' a leaf area density profile can be prescribed by using the parameters [#lad_surface lad_surface], [#lad_vertical_gradient lad_vertical_gradient] and [#lad_vertical_gradient_level lad_vertical_gradient_level]. }}} |---------------- {{{#!td style="vertical-align:top" [=#plant_canopy '''plant_canopy'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Switch for the plant canopy model.\\\\ If '''plant_canopy''' is set ''.T.'', the plant canopy model of Watanabe (2004, BLM 112, 307-341) is used.\\ The impact of a plant canopy on a turbulent flow is considered by an additional drag term in the momentum equations and an additional sink term in the prognostic equation for the subgrid-scale TKE. These additional terms are dependent on the leaf drag coefficient (see [#drag_coefficient drag_coefficient]) and the leaf area density (see [#lad_surface lad_surface], [#lad_vertical_gradient lad_vertical_gradient], [#lad_vertical_gradient_level lad_vertical_gradient_level]). The top boundary of the plant canopy is determined by the parameter [#pch_index pch_index]. For all heights equal to or larger than zw(k=pch_index) the leaf area density is 0 (i.e. there is no canopy at these heights!).\\ By default, a horizontally homogeneous plant canopy is prescribed, if '''plant_canopy''' is set ''.T.''. However, the user can define other types of plant canopies (see [#canopy_mode canopy_mode]).\\\\ If '''plant_canopy''' and [#passive_scalar passive_scalar] are set ''.T.'', the canopy acts as an additional source or sink, respectively, of scalar concentration. The source/sink strength is dependent on the scalar concentration at the leaf surface, which is generally constant with time in PALM and which can be specified by specifying the parameter [#leaf_surface_concentration leaf_surface_concentration].\\\\ Additional heating of the air by the plant canopy is taken into account, when the default value of the parameter [#cthf cthf] is altered in the parameter file. In that case the value of [#surface_heatflux surface_heatflux] specified in the parameter file is not used in the model. Instead the near-surface heat flux is derived from an exponential function that is dependent on the cumulative leaf area index.\\\\ '''plant_canopy''' = ''.T.'' is only allowed together with a non-zero [#drag_coefficient drag_coefficient]. }}} |---------------- {{{#!td style="vertical-align:top" [=#scalar_exchange_coefficient '''scalar_exchange_coefficient'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Scalar exchange coefficient for a leaf (dimensionless).\\\\ This parameter is only of importance in cases in that both, [#plant_canopy plant_canopy] and [#passive_scalar passive_scalar], are set ''.T.''. The value of the scalar exchange coefficient is required for the parametrisation of the sources and sinks of scalar concentration due to the canopy. }}} |---------------- [[BR]] [=#others '''Others:]\\ ||='''Parameter Name''' =||='''[../fortrantypes FORTRAN]\\[../fortrantypes Type]''' =||='''Default\\Value''' =||='''Explanation''' =|| |---------------- {{{#!td style="vertical-align:top;width: 150px" [=#alpha_surface '''alpha_surface'''] }}} {{{#!td style="vertical-align:top;width: 50px" R }}} {{{#!td style="vertical-align:top;width: 75px" 0.0 }}} {{{#!td Inclination of the model domain with respect to the horizontal (in degrees).\\\\ By means of '''alpha_surface''' the model domain can be inclined in x-direction with respect to the horizontal. In this way flows over inclined surfaces (e.g. drainage flows, gravity flows) can be simulated. In case of '''alpha_surface''' /= ''0'' the buoyancy term appears both in the equation of motion of the u-component and of the w-component.\\\\ An inclination is only possible in case of cyclic horizontal boundary conditions along x '''AND''' y (see [#bc_lr bc_lr] and [#bc_ns bc_ns]) and [#topography topography] = '' 'flat'.''\\\\ Runs with inclined surface still require additional [../userint user-defined code] as well as modifications to the default code. Please ask the PALM developer group ([[contact details]]). }}}