= Initialization parameters = [[TracNav(doc/app/partoc|nocollapse)]] ==== [#mode Mode] ==== ==== [#grid Grid] ==== ==== [#num Numerics] ==== ==== [#phys Physics] ==== ==== [#bc Boundary conditions] ==== ==== [#ini Initialization] ==== ==== [#topo Topography] ==== ==== [#others Others] ==== \\\\ '''NAMELIST group name:''' [=#initialization_parameters '''{{{initialization_parameters}}}'''] ---- [=#mode '''Mode:]\\ ||='''Parameter Name''' =||='''[../fortrantypes FORTRAN]\\[../fortrantypes Type]''' =||='''Default\\Value''' =||='''Explanation''' =|| |---------------- {{{#!td style="vertical-align:top;width: 150px" [=#approximation '''approximation'''] }}} {{{#!td style="vertical-align:top;width: 50px" C*20 }}} {{{#!td style="vertical-align:top;width: 75px" 'boussinesq' }}} {{{#!td Parameter to choose the approximation of the model equations. Currently two approximations are available:\\\\ '' 'boussinesq' ''\\ The Boussinesq approximation assumes an incompressible fluid. The density is is assumed to be spatially and temporally constant. The constant density is calculated in accordance with the values given for the parameters [#surface_pressure surface_pressure] and [#pt_surface pt_surface]. \\\\ '' 'anelastic' '' \\ The anelastic approximation allows for a density decrease with height. The density is however still horizontally and temporally constant. The vertical profile of the density is computed based on the [#surface_pressure surfaces_pressure] and the vertical profile of the potential temperature. The anelastic approximation requires [#momentum_advec momentum_advec] = "ws-scheme". Furthermore, [#conserve_volume_flow conserve_volume_flow] = .TRUE. is not supported.\\\\ Note, that the default flux representation for input and output depends on the approximation. For details, please see [#flux_input_mode flux_input_mode] and [#flux_output_mode flux_output_mode]. Be aware that fluxes that are given e.g. by parameter [#surface_heatflux surface_heatflux] are interpreted differently by default. In case of Boussinesq approximation, the flux is interpreted as a kinematic flux, in the anelastic case as a dynamic flux, which means that you need to adjust {{{surface_heatflux}}} (and other surface fluxes) depending on the approximation that you have chosen. \\\\ }}} |---------------- {{{#!td style="vertical-align:top" [=#check_realistic_q '''check_realistic_q'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .T. }}} {{{#!td Parameter to switch on/off check if simulation is allowed to start with supersaturated envrionment. }}} |---------------- {{{#!td style="vertical-align:top" [=#cloud_droplets '''cloud_droplets'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter to switch on the Lagrangian cloud model (LCM).\\\\ In this case the embedded particle model is used as a cloud model. Therefore, particles are representing droplets and aerosols. However, at present it is computationally not feasible to simulate a realistic amount of particles. A single Lagrangian particle thus represents an ensemble of identical particles (i.e., same radius, velocity, mass of solute aerosol) and is referred to as "super-droplet". The number of particles in this ensemble is referred to as the "weighting factor". The LCM must be steered with the list of [../parpar Particle Parameters]. }}} |---------------- {{{#!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 bc_lr] = '' 'cyclic' '' and [#bc_ns bc_ns] = '' 'cyclic{{{'}}}'') [#conserve_volume_flow 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 bc_lr] /= '' 'cyclic' '' or [#bc_ns 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 conserve_volume_flow] = ''.T.'' requires [#dp_external dp_external] = ''.F.''. In case of [../../tec/noncyclic non-cyclic lateral boundary conditions], detailed information about the conservation of volume flow can be found in the documentation. }}} |---------------- {{{#!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 Mode 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 bc_lr] /= '' 'cyclic' '' or [#bc_ns bc_ns] /= '' 'cyclic{{{'}}}'') because the (spanwise averaged) inflow profiles do not vary with time and are identical with the initial profiles.\\\\ '' '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 [[app/examples/coupled#precursur_runs| coupled runs]] 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(nzt). 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;width: 150px" [=#flux_input_mode '''flux_input_mode'''] }}} {{{#!td style="vertical-align:top;width: 50px" C*40 }}} {{{#!td style="vertical-align:top;width: 75px" 'approximation-specific' }}} {{{#!td Parameter to choose the flux unit for input data. Currently three choices are available:\\\\ '' 'kinematic' ''\\ The flux input data is assumed to be given as kinematic fluxes with the unit K m/s for sensible heat fluxes, kg/kg m/s for latent heat fluxes and m2/s2 for momentum fluxes. \\\\ '' 'dynamic' '' \\ The flux input data is assumed to be given as dynamic fluxes with the unit W/m2 for sensible and latent heat fluxes and N/m2 for momentum fluxes.\\\\ '' 'approximation-specific' '' \\ The flux input representation is chosen depending on the approximation. For [#approximation approximation] = "boussinesq" the fluxes are represented as "kinematic". For [#approximation approximation] = "anelastic" the fluxes are represented as "dynamic".\\\\ }}} |---------------- {{{#!td style="vertical-align:top;width: 150px" [=#flux_output_mode '''flux_output_mode'''] }}} {{{#!td style="vertical-align:top;width: 50px" C*40 }}} {{{#!td style="vertical-align:top;width: 75px" 'approximation-specific' }}} {{{#!td Parameter to choose the flux unit for output data. Currently three choices are available:\\\\ '' 'kinematic' ''\\ The flux output data is given as kinematic fluxes with the unit K m/s for sensible heat fluxes, kg/kg m/s for latent heat fluxes and m2/s2 for momentum fluxes. \\\\ '' 'dynamic' '' \\ The flux output data is given as dynamic fluxes with the unit W/m2 for sensible and latent heat fluxes and N/m2 for momentum fluxes.\\\\ '' 'approximation-specific' '' \\ The flux output representation is chosen depending on the approximation. For [#approximation approximation] = "boussinesq" the fluxes are represented as "kinematic". For [#approximation approximation] = "anelastic" the fluxes are represented as "dynamic".\\\\ }}} |---------------- {{{#!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 geostrophic 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 Piacsek - 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 geostrophic 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 geostrophic 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 the water vapor mixing ratio 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 bulk cloud model is switched on (see [../bulk_cloud_parameters#bulk_cloud_model bulk_cloud_model] = ''.T.''), q becomes the total water mixing ratio (sum of water vapor and liquid water). The bulk cloud model physics must be steered via [../bulk_cloud_parameters bulk cloud parameters]. }}} |---------------- {{{#!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 constant flux layer ([#constant_flux_layer constant_flux_layer]) switched off. }}} |---------------- {{{#!td style="vertical-align:top" [=#large_scale_forcing '''large_scale_forcing'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter to choose large-scale forcing from an external file. By means of '''large_scale_forcing''' = ''.T.'' the time-dependent surface heat flux '''shf''', surface water flux '''qsws''', surface temperature '''pt_surface''', surface humidity and surface pressure '''surface_pressure''' as well as vertical profiles of the geostrophic wind components '''ug''' and '''vg''', the large-scale vertical subsidence profile '''w_subs''', the horizontal large-scale advection tendencies of temperature '''td_lsa_thetal''' and humidity '''td_lsa_q''' and the large-scale subsidence tendencies of temperature '''td_sub_thetal''' and humidity '''td_sub_q''' are provided in the simulation. An example can be found [../examples/lsf here].\\ '''large_scale_forcing''' = ''.T.'' requires [#humidity humidity] = .T.. It is not implemented for the ocean mode, and it does also not work for non-cyclic lateral boundary conditions and non-flat topography. It is possible to drive the simulations either by means of surface fluxes or by means of prescribed surface values for temperature and humidity.\\ In case of simulating moderately tall buildings on otherwise flat terrain, the user might choose to nevertheless apply large_scale_forcing. This can be done by setting [#lsf_exception lsf_exception] = ''.T.''. However, it has not been tested so far and thus should be handled with care. \\ If '''large_scale_forcing''' = ''.T.'', the input file [../iofiles#LSF_DATA LSF_DATA] is required. This file has to contain two kinds of information: time-dependent surface values and time-dependent profile information which can be provided by measurements or larger scale models.\\ In case large-scale forcing shall be used without nudging ([#nudging nudging] = .F.) initial profiles of potential temperature, humidity, and horizontal wind components have to be provided by means of [#pt_surface pt_surface], [#pt_vertical_gradient pt_vertical_gradient], [#pt_vertical_gradient_level pt_vertical_gradient_level] and so forth. }}} |---------------- {{{#!td style="vertical-align:top" [=#large_scale_subsidence '''large_scale_subsidence'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter to enable large-scale subsidence/ascent for atmospheric simulations. With '''large_scale_subsidence''' = ''.T.'', an additional tendency term, tend_subs, is calculated for the scalar quantities, e.g. for potential temperature it is tend_subs(k,j,i) = - w_subs(k)* dpt(k,j,i) / dz. \\ The profile for the subsidence velocity w_subs can either be set via [#subs_vertical_gradient subs_vertical_gradient] and [#subs_vertical_gradient_level subs_vertical_gradient_level] or by reading it from the large-scale forcing data set [../iofiles#LSF_DATA LSF_DATA]. \\ If [#use_subsidence_tendencies use_subsidence_tendencies] is set to .T., the subsidence velocity w_subs is not used. Instead, subsidence tendencies for temperature and humidity are read in from the large-scale forcing data set [../iofiles#LSF_DATA LSF_DATA] and applied to the prognostic variables in the subroutine {{{ls_advec}}}. '''large_scale_subsidence''' is not implemented for the ocean mode. \\ '''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.''). It should not be applied to the momentum equations due to incompressibility. Applying it also to the horizontal velocity components would result in mass inconsistencies. '''Important:'''\\ The application of a large-scale subsidence in the stably stratified free atmosphere leads to a general temperature increase which may result in a positive mean vertical velocity due to a positive mean buoyancy, if '''reference_state''' = '' 'initial_profile' ''. This is an unphysical result and may cause undesired effects (e.g. heat flux) at the domain top. It is recommended to use '''reference_state''' = '' 'horizontal_average' '' to avoid a positive mean buoyancy inside the domain. Setting the pressure boundary condition at the domain top to '''bc_p_t''' = '' 'neumann' '' ensures that the vertical acceleration and hence also the vertical velocity at the domain top is zero. Using '''psolver''' = '' 'poisfft' '' instead of '' 'multigrid' '' is also a solution to this problem. }}} |---------------- {{{#!td style="vertical-align:top" [=#lsf_exception '''lsf_exception'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter to explicitly allow large-scale forcing in case of [#topography topography] /= '' 'flat' ''. \\ So far, [#large_scale_forcing large_scale_forcing] is not implemented to be used together with topography. However, in case of simulating moderately tall buildings on otherwise flat terrain, the user might choose to nevertheless apply large_scale_forcing. This can be done by setting '''lsf_exception''' = ''.T.''. '''Attention:'''\\ This has not been tested so far and thus should be handled with care. }}} |---------------- {{{#!td style="vertical-align:top" [=#neutral '''neutral'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter to switch off calculation of temperature equation. For simulating flows with pure neutral stratification, solving the temperature equation can be switched off with '''neutral''' = ''.T.'' in order to save CPU time. Additionally, this will also switch off the calculation of all buoyancy related terms. \\\\ In case of '''neutral''' = ''.T.'' non-zero values for parameters [#surface_heatflux surface_heatflux] and [#top_heatflux top_heatflux] are not allowed. }}} |---------------- {{{#!td style="vertical-align:top" [=#nudging '''nudging'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter to choose nudging. Nudging is a relaxation technique which adjusts the large-eddy simulation to a given, larger scale flow situation. It can, for example, be used to simulate an observed situation. Further information can be found [../../tec/nudging here]. \\\\ With '''nudging''' = ''.T.'', additional tendencies are calculated for the prognostic variable u, v, lpt, and q. It requires [#humidity humidity] = .T. as well as [#large_scale_forcing large_scale forcing] = .T.. So far, it is not implemented for the ocean mode and non-cyclic lateral boundary conditions. An example can be found [../examples/lsf here]. \\\\ Additionally, if ''nudging''' is set to ''.T.'', the input file [../iofiles#NUDGING_DATA NUDGING_DATA] has to be provided. This file contains profile information at several time steps about the relaxation time scale tau and the prognostic variables u, v, w, lpt, q which must be provided by a larger scale model or by measurements. }}} |---------------- {{{#!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 mode 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]] * The 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 time step, 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 mode 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 necessary for ocean mode runs. }}} |---------------- {{{#!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]. }}} |---------------- {{{#!td style="vertical-align:top" [=#pt_reference '''pt_reference'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" value of [#pt_surface pt_surface] }}} {{{#!td Reference temperature to be used in the buoyancy term (in K).\\\\ This parameter only becomes effective if [#reference_state reference_state] = '' 'single_value' '' has been chosen for the reference state to be used in the buoyancy term.\\\\ '''Attention:'''\\ This parameter has no effect in case of the ocean mode switched on, where potential density is used in the buoyancy term (see [#reference_state reference_state] for more details). }}} |---------------- {{{#!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 a 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 time step.\\\\ 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" [=#reference_state '''reference_state'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" '' 'initial_profile' '' }}} {{{#!td This parameter defines what is used as reference state in the buoyancy term. There are three options: '' 'initial_profile' ''\\ The initial vertical potential temperature profile will be used. See [#pt_surface pt_surface] and [#pt_vertical_gradient pt_vertical_gradient] for how to set the initial profile. In case of runs with humidity, the virtual potential temperature will be used instead (see [#q_surface q_surface] and [#q_vertical_gradient q_vertical_gradient] for how to set the initial water vapor mixing ratio profile). In ocean mode runs, potential density is used instead of temperature (calculated from the initial potential temperature and salinity profile, see [#sa_surface sa_surface] and [#sa_vertical_gradient sa_vertical_gradient] for how to set the initial salinity profile). In case of [#initializing_actions initializing_actions]= '' 'cyclic_fill','' the main run uses the initial profile of the precursor run. '' 'horizontal_average' ''\\ The instantaneous horizontally averaged potential temperature profile will be used. Please be aware that this causes the reference state to change in time. In case of runs with humidity, the virtual potential temperature will be used instead. In ocean mode runs, potential density is used. '' 'single_value' ''\\ A constant single potential temperature value is used as reference state. The respective value can be defined with parameter [#pt_reference pt_reference]. '''Warning:''' In case of runs with humidity, the virtual potential temperature is used. The reference value is then calculated from [#pt_reference pt_reference] and the surface water vapor mixing ratio (see [#q_surface q_surface]), i.e. it cannot be explicitly set by the user. In ocean mode runs, the reference value cannot be explicitly set by the user. Instead, it is calculated as the vertical average of the initial potential density profile. }}} |---------------- {{{#!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. }}} |---------------- {{{#!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_subsidence_tendencies '''use_subsidence_tendencies'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td This control parameter determines how the large-scale subsidence is computed for runs with large-scale forcing. If it is set to .F., the large-scale subsidence velocity w_subs is used to advect the prognostic variables (subroutine {{{subsidence}}}). If it is set to .T., the subroutine {{{subsidence}}} is not called and the subsidence tendencies from [../../app/iofiles#LSF_DATA LSF_DATA] are applied to the prognostic variables in the new subroutine {{{ls_advec}}}. The usage of use_subsidence_tendencies requires [#large_scale_forcing large_scale_forcing] = .T. as well as [#large_scale_subsidence large_scale_subsidence] = .T.. }}} |---------------- {{{#!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 the 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 the same (same model domain length in y-direction). }}} |---------------- {{{#!td style="vertical-align:top" [=#dz '''dz'''] }}} {{{#!td style="vertical-align:top" R(10) }}} {{{#!td style="vertical-align:top" 10 * -1.0 }}} {{{#!td Vertical grid spacing (in m).\\\\ At least one value must be assigned by the user because no realistic value is given. dz must not be set to the default value of [#dz_max dz_max] = 999.0.\\\\ By default, the model uses constant grid spacing along the z-direction, but it can be stretched using either the old parameters [#dz_stretch_level dz_stretch_level], [#dz_stretch_factor dz_stretch_factor], [#dz_max dz_max] or the new ones [#dz_stretch_level_start dz_stretch_level_start], [#dz_stretch_level_end dz_stretch_level_end] which allow grid stretching to a finer or coarser grid and the definition of several stretching regions. If the new stretching method is used different dz values have to be specified by the user (equal to the number of defined [#dz_stretch_level_end dz_stretch_level_end] + 1). In that way PALM knows which grid spacing shall be used before and after the grid stretching region limited through [#dz_stretch_level_start dz_stretch_level_start] and [#dz_stretch_level_end dz_stretch_level_end].\\\\ Assuming a constant dz, the scalar levels (zu) are calculated directly by:\\\\ zu(0) = 0.0,\\\\ zu(1) = dz(1) * 0.5,\\\\ zu(k) = zu(k-1) + dz(1).\\\\ The w-levels lie half between them:\\\\ zw(k) = ( zu(k) + zu(k+1) ) * 0.5,\\\\ except for k=0, where zw(0) = 0.0 }}} |---------------- {{{#!td style="vertical-align:top" [=#dz_max '''dz_max'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 999.0 }}} {{{#!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. The default value is 999.0 to prevent unrealistic high vertical grid spacings. }}} |---------------- {{{#!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 anymore. (refer Kalnay de Rivas, 1972: https://doi.org/10.1016/0021-9991(72)90060-5) }}} |---------------- {{{#!td style="vertical-align:top" [=#dz_stretch_level '''dz_stretch_level'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" -9999999.9 }}} {{{#!td Height level above/below which the grid is to be stretched vertically (in m).\\\\ For atmospheric runs (which is the default) '''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 mode runs '''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" [=#dz_stretch_level_end '''dz_stretch_level_end'''] }}} {{{#!td style="vertical-align:top" R(9) }}} {{{#!td style="vertical-align:top" 9 * 9999999.9 }}} {{{#!td Height level until which the grid is to be stretched vertically (in m). Up to 9 heights/separate stretching regions are possible.\\\\ For atmospheric runs (which is the default) '''dz_stretch_level_end''' is the height level (in m) until which the grid is to be stretched vertically. The vertical grid spacings [#dz dz] between this level and the corresponding [#dz_stretch_level_start dz_stretch_level_start] are calculated as\\\\ dz(k+1) = dz(k) * dz_stretch_factor_array\\\\ 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 mode runs '''dz_stretch_level_end''' is also the height level (in m) until which the grid is to be stretched vertically but it is defined negative. The vertical grid spacings [#dz dz] between this level and the corresponding [#dz_stretch_level_start dz_stretch_level_start] are calculated as\\\\ dz(k-1) = dz(k) * dz_stretch_factor_array.\\\\ For each '''dz_stretch_level_end''' a corresponding [#dz_stretch_level_start dz_stretch_level_start] must be defined. \\\\ '''Hint:'''\\ dz_stretch_factor_array is an array in the code which accounts for different stretching factors due to different stretching regions that are possible. The factors are calculated internally except for the case when the old stretching for the free atmosphere with [#dz_stretch_factor dz_stretch_factor], [#dz_stretch_level dz_stretch_level] and [#dz_max dz_max] is used. }}} |---------------- {{{#!td style="vertical-align:top" [=#dz_stretch_level_start '''dz_stretch_level_start'''] }}} {{{#!td style="vertical-align:top" R(9) }}} {{{#!td style="vertical-align:top" 9 * -9999999.9 }}} {{{#!td Height level above/below which the grid is to be stretched vertically (in m). Up to 9 heights/separate stretching regions are possible.\\\\ For atmospheric runs (which is the default) '''dz_stretch_level_start''' is the height level (in m) above which the grid is to be stretched vertically. The vertical grid spacings [#dz dz] between this level and the corresponding [#dz_stretch_level_end dz_stretch_level_end] are calculated as\\\\ dz(k+1) = dz(k) * dz_stretch_factor_array\\\\ 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 mode runs '''dz_stretch_level_start''' is the height level (in m, negative) below which the grid is to be stretched vertically. The vertical grid spacings [#dz dz] between this level and the corresponding [#dz_stretch_level_end dz_stretch_level_end] are calculated as\\\\ dz(k-1) = dz(k) * dz_stretch_factor_array.\\\\ For each '''dz_stretch_level_start''' a corresponding [#dz_stretch_level_end dz_stretch_level_end] must be defined except for the last level. Here, it is possible to omit the value for [#dz_stretch_level_end dz_stretch_level_end] to consider 'endless' stretching until the value of [#dz_max dz_max] is reached. In that case the stretching factor can not be calculated and is set to the value of [#dz_stretch_factor dz_stretch_factor]. \\\\ '''Hint:'''\\ dz_stretch_factor_array is an array in the code which accounts for different stretching factors due to different stretching regions that can be defined. The factors are calculated internally except for the case when the old stretching for the free atmosphere with [#dz_stretch_factor dz_stretch_factor], [#dz_stretch_level dz_stretch_level] and [#dz_max dz_max] is used. }}} |---------------- {{{#!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 '''nx+1''' must be an integral multiple of the number of processors along x-direction (see [../runtime_parameters#npex npex]). If the fft-solver is used for calculating the Poisson equation (see [#psolver psolver]), it must be an integral multiple of the number of processors along y-direction, too (see [../runtime_parameters#npey npey]), due to data transposition restrictions.\\\\ For coupled runs ([../examples/coupled see details]) the product of '''dx''' and '''nx''' in both parameter files [../iofiles#PARIN PARIN] and [../iofiles#PARIN_O PARIN_O] has to be same (same model domain length in x-direction). }}} |---------------- {{{#!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 '''ny+1''' must be an integral multiple of the number of processors along y-direction. (see [../runtime_parameters#npey npey]). If the fft-solver is used for calculating the Poisson equation (see [#psolver psolver]), it must be an integral multiple of the number of processors along x-direction, too (see [../runtime_parameters#npex npex]), due to data transposition restrictions.\\\\ For coupled runs ([../examples/coupled see details]) the product of '''dy''' and '''ny''' in both parameter files [../iofiles#PARIN PARIN] and [../iofiles#PARIN_O PARIN_O] has to be same (same model domain length in y-direction). }}} |---------------- {{{#!td 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, scalar quantities) or up to '''nz-1''' (w). The top boundary for u, v and scalar quantities is at k = '''nz+1''' (u, v) while at k = '''nz''' for w.\\\\ For parallel runs, and if the fft-solver is used for calculating the Poisson equation (see [#psolver psolver]), '''nz''' must be an integral multiple of the number of processors in x-direction (due to data transposition restrictions). }}} [[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 time step 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.\\\\ Pressure solver must be called at each RK3 substep when [#momentum_advec momentum_advec] = 'ws-scheme'. }}} |---------------- {{{#!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 [../runtime_parameters#dt_max dt_max] is reduced by [#dt dt] = dt_max * '''cfl_factor''' in order to avoid stability problems which may arise in the vicinity of the maximum allowed time step. The condition ''0.0'' < '''cfl_factor''' < ''1.0'' applies.\\\\ The default value of '''cfl_factor''' depends on the [#timestep_scheme timestep_scheme] used:\\\\ For the third order Runge-Kutta scheme it is '''cfl_factor''' = ''0.9.'', for the second-order Runge-Kutta scheme a value of ''0.8'' is applied.\\\\ The default value for the Euler scheme is '''cfl_factor''' = ''0.9.'' }}} |---------------- {{{#!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 speed up the code, e.g. by a few percent on SGI-ICE-systems with Infiniband fat tree, but only for a larger number of PEs (>= 2048) and if dual rail mode is switched on (default on SGI-systems at HLRN). Therefore, {{{collective_wait}}} is {{{.TRUE.}}} by default on SGI-systems (if hostname(3:5) = "{{{sgi}}}", given with [wiki:doc/app/palmrun palmrun]-option {{{-c}}}), 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 multigrid method.\\\\ This parameter determines which type of cycle is applied in the multigrid 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" 'temperton-algorithm' }}} {{{#!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]).\\\\ There are two 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 (ECMWF) which is computationally very fast and switched on with '''fft_method''' = '' 'temperton-algorithm'.'' The number of horizontal grid points ([#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 grid points to be used with, switched on with '''fft_method''' = '' 'singleton-algorithm'.''\\\\ Furthermore, the fftw (see http://www.fftw.org ) can be used by setting '''fft_method''' = '' 'fftw' ''. This also requires to set the cpp-preprocessor switch {{{-D__fftw}}} in the {{{%cpp_options}}}-line of the configuration file, and to give the paths to the respective fftw include file and library by a {{{%fftw_inc}}} and {{{%fftw_lib}}} line, respectively. The fftw-routines are more than two times faster than the Temperton-fft.\\ Finally, '''fft_method''' can also be set to '' 'system-specific' '' to account for fft routines from IBM or NEC. This also requires to set the cpp-preprocessor switch {{{-D__ibm}}} or {{{-D__nec}}} in the {{{%cpp_options}}}-line of the configuration file }}} |---------------- {{{#!td style="vertical-align:top" [=#loop_optimization '''loop_optimization'''] }}} {{{#!td style="vertical-align:top" C*16 }}} {{{#!td style="vertical-align:top" 'cache' }}} {{{#!td Method used to optimize loops for solving the prognostic equations.\\\\ If set to '' 'cache' '', all prognostic equations are solved within one big loop over the two horizontal indices {{{i}}} and {{{j}}} giving a good cache utilization. In case of '''loop_optimization''' = '' 'vector' '', single 3d-loops are used to calculate each tendency term of each prognostic equation. Adjust this parameter for optimal use of your hardware ressources. }}} |---------------- {{{#!td style="vertical-align:top" [=#masking_method '''masking_method'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Switch for topography boundary conditions in 'multigrid_noopt' solver.\\\\ By default, Neumann boundary conditions for perturbation pressure are used in the multigrid solver at all wall boundaries. In case of '''masking_method''' = ''.TRUE.'', the masking method is used instead (i.e. the solver runs through the topography). \\\\ '''Note: ''' '''masking_method''' has only an effect if [#psolver psolver] = 'multigrid_noopt', otherwise, if [#psolver psolver] = 'multigrid', masking is always used, so that setting '''masking_method''' has no effect on the simulation at all. Moreover, if you use older revisions (<1931), it is noted that the naming convention for the multigrid solvers was different, 'multigrid_noopt' (now) was 'multigrid' (<1931), and 'multigrid' (now) was 'multigrid_fast' (<1931). \\ \\ '''Remark 1''' \\ In case of very complex topography, including narrow street canyons or complex shapes resolved by only a few grid points, the use of [#psolver psolver] = 'multigrid_noopt' in combination with [#masking_method masking_method] = .F. can lead to a blow up of wind velocity. So far, this never happened if masking_method = .T. or [#psolver psolver] = 'multigrid' (where topography is always masked). A possible workaround to prevent such velocity blow-up is to preprocess the topography by filling holes and removing complex shapes on the small scale before running the LES. (This approach should have no significant effect on the flow field, as in LES the flow in such regions is poorly resolved and do not yield to reliable physical information.) The reason for this velocity blow-up is unclear so far. '''Remark 2''' \\ If topography is prescribed and [#psolver psolver] = 'multigrid_noopt', the mean velocity-divergence reduction (see RUN_CONTROL) is smaller in case of [#masking_method masking_method] = .T. compared to [#masking_method masking_method] = .F. (about one-order of magnitude). This smaller reduction can be attributed to wall-bounded grid points, where the divergence after pressure correction remains significantly larger in case of masking, while the divergence reduction for non-wall-bounded grid points is similar in both cases. However, validation tests revealed that this smaller divergence reduction has no effect on the resulting flow. }}} |---------------- {{{#!td style="vertical-align:top" [=#mg_cycles '''mg_cycles'''] }}} {{{#!td style="vertical-align:top" I }}} {{{#!td style="vertical-align:top" 4 }}} {{{#!td Number of cycles to be used with the multigrid scheme.\\\\ This parameter determines the number of cycles to be carried out in the multigrid 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''' = ''4''), a fixed number of cycles (4) is carried out. This number of cycles might not be sufficient for every simulation! 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.\\\\ If set '''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. }}} |---------------- {{{#!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" -1 }}} {{{#!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. If '''mg_switch_to_pe0_level''' = ''0'', 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 necessary to determine this level.\\\\ Default setting is '''mg_switch_to_pe0_level''' = -''1'', which prevents that data are collected on PE0 at all, i.e. coarsening of grids is limited by the subdomains. \\\\ '''Remark:''' The default setting is significantly faster compared to automatically determining or explicitly prescribing '''mg_switch_to_pe0_level'''. Even though the divergence reduction of the multigrid solver is slightly smaller with the default setting, gathering on PE0 does not justify the additional cost so far. }}} |---------------- {{{#!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 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 scheme implies a small numerical dissipation that stabilizes the solution. To assure a stable numerical solution the time integration has to be carried out with [#timestep_scheme timestep_scheme] = '' 'runge-kutta-3' '' . This scheme is based on a formulation 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] = '' .T. '' has to be used. '''Note''': Due to the larger stencil of this scheme vertical grid stretching should be handled with care. The computation of turbulent fluxes takes place inside the advection routines to get a statistical evaluation consistent to the numerical solution. '''Important''': The number of ghost layers for 2d and 3d arrays changed. This affects also the user interface. Please adapt the allocation of 2d and 3d arrays in your user interface like [../userint/output#Allocate here]. Furthermore, the exchange of ghost layers for 3d variables changed, so calls of exchange_horiz in the user interface have to be modified. Here an example for the u-component of the velocity: CALL exchange_horiz( u , nbgp ). \\\\ '' 'pw-scheme' ''\\\\ The scheme of Piacsek and Williams (1970, J. Comp. Phys., 6, 392-405) with central differences in the form C3 is used. '' 'up-scheme' ''\\\\ First-order upstream scheme. The upstream scheme is guarantees only a stable solution in combination with [#timestep_scheme timestep_scheme] = '' 'euler' ''. Note, this scheme is very diffusive, and hence, not well-suited for turbulence-resolving simulations. }}} |---------------- {{{#!td style="vertical-align:top" [=#monotonic_limiter_z '''monotonic_limiter_z'''] }}} {{{#!td style="vertical-align:top" C*10 }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Control flag that enables a monotonic flux limiter for the vertical advection of passive scalars according to Skamarock (2006, Mon. Wea. Rev 134, 2241-2250). If the limiter is enabled, vertical scalar advection will be monotone and positive definite but strong gradients may be smoothed. This will avoid numerical oscillation that can cause unrealistically high concentrations within poorly resolved cavities within urban environments, e.g. narrow street canyons, which can spoil the entire simulation results. Please note, the limiter is only effective up to the height of the highest topography. Please note, this parameter becomes only effective if [#scalar_advec scalar_advec] = 'ws-scheme' is set. Moreover, please note that the monontonic limiter is currently only implemented for [#loop_optimization loop_optimization] = 'cache'. }}} |---------------- {{{#!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 default 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 time steps 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 the 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 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.\\\\ '' 'multigrid' ''\\\\ Multigrid 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]. The smaller this limit is, the more cycles have to be carried out in this case and the number of cycles may vary from time step to time step.\\\\ If [#mg_cycles mg_cycles] is set to its optimal value, the computing time of the multigrid 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 multigrid 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 used) along each of the directions can, at least, be divided 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].\\\\ 'multigrid' is highly optimized for better performance. Data along the {{{k}}} index (vertical direction) is sorted from alternate even and odd indices into two blocks of completely even and odd indices respectively, which allows vectorization on INTEL processors of loops in the red/black scheme. Additionally, topography flags are completely ignored (i.e. not used) in case of [#masking_method masking_method] switched off. On fine grid levels only even or odd data are send for the lateral ghost point exchange. Speedup of the multigrid solver for medium sized cases (1024*1024*192 grid points) can be about 40% compared to 'multigrid_noopt'. \\ In contrast to 'multigrid_noopt', masking is always used, i.e. the solver runs through the topography similar to the FFT. '' 'multigrid_noopt' ''\\\\ Similar as 'multigrid', but less optimized. However, in contrast to 'multigrid', 'multigrid_noopt' allows [#masking_method masking_method]=.FALSE., i.e. setting of Neumann boundary conditions for the perturbation pressure at all wall boundaries. '''Please note,''' in combination with [#masking_method masking_method], the 'multigrid_noopt' solver can lead to a blow-up of wind velocity in case of narrow street canyons or complex shapes resolved by only a few grid points. Please see further [../../tec/bugs/#remark1 remarks].\\\\ '''Please note:''' In former revisions (<1931), the naming convention for the multigrid solvers was different, 'multigrid_noopt' (now) was 'multigrid' (<1931), and 'multigrid' (now) was 'multigrid_fast' (<1931). '' '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 multigrid 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 time step 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_damping_factor '''pt_damping_factor'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Factor for damping the potential temperature.\\\\ In case of non-cyclic lateral boundary conditions (see [#bc_lr bc_lr] or [#bc_ns bc_ns]), a damping is applied to the potential temperature if a non-zero value is assigned to '''pt_damping_factor'''. If switched on, the temperature is forced towards the value of its basic state (defined by the initial profile of the temperature). The intensity of damping is controlled by the value '''pt_damping_factor'''. The damping starts weakly at a distance from the inflow boundary defined by [#pt_damping_width pt_damping_width] and rises according to a sin^2^-function to its maximum value at the inflow.\\\\ This method effectively damps gravity waves at the inflow boundary in case of non-cyclic lateral boundary conditions (see [#bc_lr bc_lr] or [#bc_ns bc_ns]). If the damping factor is too low, gravity waves can develop within the damping domain and if the damping factor is too high, gravity waves can develop in front of the damping domain. Note that the method has no effect if [#recycling_method_for_thermodynamic_quantities recycling_method_for_thermodynamic_quantities] = 'absolute_value'. Detailed information about the damping can be found in the documentation of the [../../tec/noncyclic non-cyclic lateral boundary conditions]. }}} |---------------- {{{#!td style="vertical-align:top" [=#pt_damping_width '''pt_damping_width'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Width of the damping domain of the potential temperature (in m).\\\\ In case of non-cyclic lateral boundary conditions (see [#bc_lr bc_lr] or [#bc_ns bc_ns]), this parameter determines the range where damping of the potential temperature is applied. The damping domain starts at the inflow boundary and ranges to the value of '''pt_damping_width'''. The intensity of the damping is applied by [#pt_damping_factor pt_damping_factor]. Detailed information about the damping can be found in the documentation of the [../../tec/noncyclic non-cyclic lateral boundary conditions]. }}} |---------------- {{{#!td style="vertical-align:top" [=#random_generator '''random_generator'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'random-\\parallel' }}} {{{#!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 [../runtime_parameters#create_disturbances create_disturbances] and [#random_heatflux random_heatflux]). By default, the "parallel" random number generator is used. \\\\ By setting ( '''random_generator''' = '' 'numerical-recipes' '') PALM provides exactly the same order of random numbers on all different machines and should be used in particular for comparison runs.\\\\ By setting ( '''random_generator''' = '' 'random-parallel' '') a fully parallelized random number generator can be chosen. Like the default, this generator creates random numbers in a reproducible order. The parallel random number generator also provides ensemble run capability, which can be steered by specifying the parameter [#ensemble_member_nr ensemble_member_nr]\\\\ 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 compare one-to-one if they have used different random number generators, or if they are different members of an ensemble of runs (see parameter [#ensemble_member_nr ensemble_member_nr]). }}} |---------------- {{{#!td style="vertical-align:top" [=#rans_const_c '''rans_const_c'''] }}} {{{#!td style="vertical-align:top" R(5) }}} {{{#!td style="vertical-align:top" 0.55, 1.44, 1.92, 0.0, 0.0 }}} {{{#!td Model parameter used in the turbulence closure for RANS mode. Constants are {{{ #!Latex \begin{align*} \mathrm{rans\_const\_c(0)} &= c_0 = \sqrt[4]{c_\mu}\\ \mathrm{rans\_const\_c(1)} &= c_1\\ \mathrm{rans\_const\_c(2)} &= c_2\\ \mathrm{rans\_const\_c(3)} &= c_3\\ \mathrm{rans\_const\_c(4)} &= c_4\\ \end{align*} }}} Default values are according to the standard TKE-e turbulence closure (see [#turbulence_closure turbulence_closure]). }}} |---------------- {{{#!td style="vertical-align:top" [=#rans_const_sigma '''rans_const_sigma'''] }}} {{{#!td style="vertical-align:top" R(2) }}} {{{#!td style="vertical-align:top" 1.0, 1.3 }}} {{{#!td Model parameter used in the turbulence closure for RANS mode. Constants are {{{ #!Latex \begin{align*} \mathrm{rans\_const\_sigma(1)} &= \sigma_e\\ \mathrm{rans\_const\_sigma(2)} &= \sigma_\epsilon. \end{align*} }}} Default values are according to the standard TKE-e turbulence closure (see [#turbulence_closure turbulence_closure]). }}} |---------------- {{{#!td style="vertical-align:top" [=#rayleigh_damping_factor '''rayleigh_damping_factor'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!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, horizontal velocities, temperature, humidity/scalar (if switched on) and salinity (in case of ocean mode) are forced towards the value of their respective basic states (defined by the initial profiles of the geostrophic wind, temperature, etc., or in case of offline nesting, defined by the current mean of wind components, temperature, etc. of the mesoscale model). In case of large-scale subsidence (see [#subs_vertical_gradient subs_vertical_gradient]) the basic state of temperature and humidity is adjusted with respect to the subsidence. Scalar quantities can be excluded from the damping (see [#scalar_rayleigh_damping scalar_rayleigh_damping]). 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.\\\\ 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(nzt)\\ (ocean:\\ 2/3*zu(nzb)) }}} {{{#!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-4 }}} {{{#!td Largest residual permitted for the multigrid scheme (in s^-2^m^-3^).\\\\ This is a parameter to steer the accuracy of the multigrid scheme (see [#psolver psolver]). The divergence of the 3D velocity field will be reduced iteratively as long as the calculated residual is greater than '''residual_limit'''. After a maximum number of 1000 iterative cycles, 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 multigrid 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 scheme implies a small numerical dissipation that stabilizes the solution. To assure a stable numerical solution the time integration has to be carried out with [#timestep_scheme timestep_scheme] = '' 'runge-kutta-3' '' . This scheme is based on a formulation 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] = '' .T. '' has to be used. '''Note''': Due to the larger stencil of this scheme vertical grid stretching should be handled with care. The computation of turbulent fluxes takes place inside the advection routines to get a statistical evaluation consistent to the numerical solution. \\\\ '''Note''', in case of large gradients close to poorly-resolved cavities, e.g. narrow street canyons, numerical oscillation can occur which might built-up if the flow is almost completely blocked. In this case it is recommended to apply a monotonic flux limiter ([#monotonic_limiter_z monotonic_limiter_z] = .T.) which guarantees monotone and positive definite vertical advection of passive scalars (only). '' 'pw-scheme' ''\\\\ The scheme of Piacsek and Williams (1970, J. Comp. Phys., 6, 392-405) with central differences in the form C3 is used.\\\\ '' 'bc-scheme' ''\\\\ The Bott scheme modified by Chlond (1994, Mon. Wea. Rev., 122, 111-125). This is a conservative monotonous scheme with very small numerical diffusion and therefore very good conservation of scalar flow features. The scheme, however, is computationally very expensive both because it is expensive itself and because it does (so far) not allow specific code optimizations (e.g. cache optimization). Choice of this scheme forces the Euler time step scheme to be used for the scalar quantities. For output of horizontally averaged profiles of the resolved / total heat flux, [../runtime_parameters#data_output_pr data_output_pr] = '' 'w*theta*BC' '' / '' 'wthetaBC' '' should be used, instead of the standard profiles ('' 'w*theta*' '' and '' 'wtheta' '') because these are too inaccurate with this scheme. However, for subdomain analysis (see [#statistic_regions statistic_regions]) exactly the reverse holds: here '' 'w*theta*BC' '' and '' 'wthetaBC' '' show very large errors and should not be used.\\\\ This scheme is not allowed for non-cyclic lateral boundary conditions (see [#bc_lr bc_lr] and [#bc_ns bc_ns]) and requires that [#loop_optimization loop_optimization] = '' 'vector' '' is set.\\\\ '' 'up-scheme' ''\\\\ First-order upstream scheme. The upstream scheme is guarantees only a stable solution in combination with [#timestep_scheme timestep_scheme] = '' 'euler' ''. Note, this scheme is very diffusive, and hence, not well-suited for turbulence-resolving simulations. \\\\ Remark: Independent on the choice of 'scalar_advec' and [#timestep_scheme timestep_scheme], a different 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" [=#scalar_rayleigh_damping '''scalar_rayleigh_damping'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .T. }}} {{{#!td Application of Rayleigh damping to scalars.\\\\ With Rayleigh damping switched on (see [#rayleigh_damping_factor rayleigh_damping_factor]), this parameter determines if the damping is applied also to scalars (temperature, humidity/scalar, salinity) or to the horizontal velocity components only. }}} |---------------- {{{#!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] = '' 'ws-scheme' '' or '' 'pw-scheme'.'' For further information see [../../tec/rk3 here]. \\\\ '' 'runge-kutta-2' ''\\\\ Second order Runge-Kutta scheme.\\ For special features see '''timestep_scheme''' = '' 'runge-kutta-3'.''\\\\ '' 'euler' ''\\\\ First order Euler scheme.\\\\ A differing time step scheme can be chosen for the subgrid-scale TKE using parameter [#use_upstream_for_tke use_upstream_for_tke]. }}} |---------------- {{{#!td style="vertical-align:top" [=#transpose_compute_overlap '''transpose_compute_overlap'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter to switch on parallel execution of fft and transpositions (with {{{MPI_ALLTOALL}}}).\\\\ If the fft-Poisson-solver is used (see [#psolver psolver]), '''transpose_compute_overlap''' = ''.T.'' causes the fft to be executed in parallel to the transposition (done by {{{MPI_ALLTOALL}}}). For larger grids, this method may speed up the fft-solver significantly. }}} |---------------- {{{#!td style="vertical-align:top" [=#turbulence_closure '''turbulence_closure'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" '' '1.5-order' '' }}} {{{#!td Parameter to choose between different turbulence closures.\\\\ The following values are allowed:\\\\ '' '1.5-order' ''\\\\ Turbulence closure according to a modified version of Deardorff's subgrid-scale model (Deardorff 1980, Moeng & Wyngaard) as described by Saiki et al. (2000). See details in the [wiki:doc/tec/sgs#deardorff-sgs documentation].\\\\ '' '1.5-order-dai' ''\\\\ Turbulence closure according to a modified version of Deardorff's subgrid-scale model described by Dai et al. (2020). '''The implementation is still not thoroughly tested and should be used with extra care'''. See details in the [wiki:doc/tec/sgs#deardorff-sgs-mod documentation].\\\\ '' 'dynamic' ''\\\\ Use a dynamic subgrid-scale model according to Germano et al. (1991) and Heinz (2008). See details in the [wiki:doc/tec/sgs#Dynamicsubgrid-scalemodel documentation].\\\\ '' 'tke-l' '' \\\\ Turbulence closure utilising the Prandtl-Kolmogorov relation. See details in the [wiki:/doc/tec/turbulence_parameterization#tkel_model documentation].\\ This option puts PALM into RANS mode.\\\\ '' 'tke-e' '' \\\\ Standard TKE-e closure for Reynolds-averaged Navier-Stokes equations. The used constants can be changed using parameters [#rans_const_c rans_const_c] and [#rans_const_sigma rans_const_sigma]. See details in the [wiki:/doc/tec/turbulence_parameterization#tkee_model documentation].\\ This option puts PALM into RANS mode.\\\\ }}} |---------------- {{{#!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/time step scheme to be used for the subgrid-scale TKE.\\\\ By default, the advection scheme and the time step 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 time step scheme and advection scheme, respectively. By these methods, strong artificial near-surface vertical gradients of the subgrid-scale TKE, as they will be caused by non-diffusive advection schemes, are avoided. '''use_upstream_for_tke''' = ''.T.'' 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]) and [#scalar_advec scalar_advec] /= 'ws-scheme'. }}} [[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([#latitude latitude])\\ f* = 2.0 * '''omega''' * cos([#latitude latitude]) }}} |---------------- {{{#!td style="vertical-align:top" [=#latitude '''latitude'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 55.0 }}} {{{#!td Geographical latitude (in degrees north).\\\\ 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. Note that at equator the horizontal component of the Coriolis force is zero, while its vertical component has its maximum; and vice versa at the poles. For switching off the Coriolis force, it is thus recommended to set [#omega omega] = 0.0 instead.\\\\ If a [/wiki/doc/app/iofiles/pids/static static driver] is used, this parameter will be overwritten by the value given in the static driver. }}} |---------------- {{{#!td style="vertical-align:top" [=#longitude '''longitude'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Geographical longitude (in degrees east).\\\\ The value is used by the radiation model to determine the position of the sun.\\\\ If a [/wiki/doc/app/iofiles/pids/static static driver] is used, this parameter will be overwritten by the value given in the static driver. }}} |---------------- {{{#!td style="vertical-align:top" [=#rotation_angle '''rotation_angle'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Rotation angle of the model's North direction relative to geographical North (in degrees, clockwise rotation).\\\\ The rotation angle affects the Coriolis force as well as the solar radiation wihin the model domain. Further, it is used for correct geo-referencing each model grid point to real-world coordinates.\\\\ If a [/wiki/doc/app/iofiles/pids/static static driver] is used, this parameter will be overwritten by the value given in the static driver. }}} |---------------- {{{#!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,,). }}} |---------------- {{{#!td style="vertical-align:top" [=#use_fixed_date '''use_fixed_date'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Switch to fix the calendar day within a simulation.\\\\ If **use_fixed_date** = .TRUE., the calendar day does not change during a simulation. When the simulated time in PALM reaches 24:00:00 UTC, the time is set to 00:00:00 UTC without the calendar day being changed. This affects, e.g., the solar position during the simulation.\\\\ Example:\\ If [#origin_date_time origin_date_time] = '2020-07-15 20:00:00 +00', then after 5h simulation time, PALM's clock would be at '2020-07-15 01:00:00 +00'. }}} |---------------- {{{#!td style="vertical-align:top" [=#use_fixed_time '''use_fixed_time'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Switch to fix the time of day within a simulation.\\\\ If **use_fixed_time** = .TRUE., the time of day does not change during a simulation, i.e. PALM's internal clock would always show the value given by [#origin_date_time origin_date_time]. This results in the sun having a fixed position during the simulation. }}} [[BR]] [=#bc '''Boundary conditions:]\\ ||='''Parameter Name''' =||='''[../fortrantypes FORTRAN]\\[../fortrantypes Type]''' =||='''Default\\Value''' =||='''Explanation''' =|| |---------------- {{{#!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''' should be set to '' 'neumann' '' i.e. e(k=0)=e(k=1) (Neumann boundary condition), where e(k=1) is calculated via the prognostic TKE equation. '''bc_e_b''' = '' {{{'(u*)**2+neumann'}}} '' can be set as an alternative. In that case, e(k=1) = u*/0.1 is assumed. This alternative is just a test option and should be used with care.\\\\ 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'\\\\ ('nested' for nest domains except if [#nesting_mode nesting_mode]='vertical') }}} {{{#!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 multigrid method to be used for solving the Poisson equation for perturbation pressure (see [#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 e, to which a Neumann (zero gradient) condition is applied. At the outflow, a radiation condition is used for all velocity components. A constant phase velocity is used, which is set to the maximum velocity allowed by the CFL criterion (i.e. for a Courant number of one). For scalars, a Neumann condition is used. For the perturbation pressure, Neumann conditions are assumed both at the inflow and at the outflow.\\\\ In order to maintain a turbulent state of the flow, it may be necessary to continuously impose perturbations on the horizontal velocity field in the vicinity of the inflow throughout the whole run. This can be switched on using [../runtime_parameters#create_disturbances create_disturbances]. The horizontal range to which these perturbations are applied is controlled by the parameters [#inflow_disturbance_begin inflow_disturbance_begin] and [#inflow_disturbance_end inflow_disturbance_end]. The vertical range and the perturbation amplitude are given by [../runtime_parameters#disturbance_level_b disturbance_level_b], [../runtime_parameters#disturbance_level_t disturbance_level_t], and [../runtime_parameters#disturbance_amplitude disturbance_amplitude]. The time interval at which perturbations are to be imposed is set by [../runtime_parameters#dt_disturb dt_disturb]. Note that these inflow perturbances are added '''in addition''' to the standard perturbances that are activated with [../runtime_parameters#create_disturbances create_disturbances]. The standard perturbances can be deactivated by setting the d3par-parameter [../runtime_parameters#disturbance_energy_limit disturbance_energy_limit] = 0.0 .\\\\ In case of non-cyclic horizontal boundaries [#call_psolver_at_all_substeps call_psolver_at_all_substeps] = ''.T.'' should be used.\\\\ In case of nested run, except if [#nesting_mode nesting_mode]='' 'vertical' '', the default value of '' 'bc_lr' '' in the nest domains is not '' 'cyclic' '' but '' 'nested' '' instead. For the root domain of a nested run the default is '' 'cyclic' '' as usually.\\ In case of [../nestofflpar offline nesting] 'bc_lr' is set internally to Dirichlet boundary conditions. \\ '''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. Detailed information can be found in the documentation of the [../../tec/noncyclic non-cyclic lateral boundary conditions].\\\\ '''Note 2:'''\\ In case of cyclic boundary conditions in both horizontal directions, a y-shift at the left/right boundary can be introduced using the parameter [#y_shift y_shift]. }}} |---------------- {{{#!td style="vertical-align:top" [=#bc_ns '''bc_ns'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'cyclic'\\\\ ('nested' for nest domains except if [#nesting_mode nesting_mode]='vertical') }}} {{{#!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 multigrid method to be used for solving the Poisson equation for perturbation pressure (see [#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 e, to which a Neumann (zero gradient) condition is applied. At the outflow, a radiation condition is used for all velocity components. A constant phase velocity is used, which is set to the maximum velocity allowed by the CFL criterion (i.e. for a Courant number of one). For scalars, a Neumann (zero gradient) condition is used. For the perturbation pressure, Neumann (zero gradient) conditions are assumed both at the inflow and at the outflow.\\\\ In case of nested run, except if [#nesting_mode nesting_mode]='' 'vertical' '', the default value of '' 'bc_lr' '' in the nest domains is not '' 'cyclic' '' but '' 'nested' '' instead. For the root domain of a nested run the default is '' 'cyclic' '' as usually.\\ In case of [../nestofflpar offline nesting] 'bc_ns' is set internally to Dirichlet boundary conditions. \\ 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' '' and '' 'neumann' ''. '' 'dirichlet' '' sets p(k=0)=0.0, '' 'neumann' '' sets p(k=0)=p(k=1).\\\\ Since vertical velocity is zero at the rigid lower boundary (w(k=0) = 0.0), the consistent Neumann condition ('' 'neumann' '') 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]) is allowed. }}} |---------------- {{{#!td style="vertical-align:top" [=#bc_p_t '''bc_p_t'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'dirichlet'\\\\ ('neumann' for nest domains) }}} {{{#!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]) yields no consistent solution for the perturbation pressure in case that the multigrid method is used for solving the Poisson equation (see [#psolver psolver]), and should be avoided. Since at the bottom boundary the Neumann condition is a good choice (see [#bc_p_b bc_p_b]), in that case, a Dirichlet condition should be set at the top boundary.\\\\ In case of nested run, the default value of '''bc_p_t''' in the nest domains is not '' 'dirichlet' '' but '' 'neumann' '' instead. For the root domain of a nested run the default is '' 'dirichlet' '' as usually.\\ '''Note:'''\\ The nest-domain default boundary conditions for perturbation pressure lead to Poisson problem with all-Neumann boundary condition. This means that the solution is only determined up to a constant. In other words, the average value of the pressure remains arbitrary. This implies that the convergence rate is usually somewhat lower than when Dirichlet condition is used at least on one of the boundaries. The average perturbation pressure can be forced to a given value, say zero, but according to the tests, it does not improve the convergence rate at all. Users using the nesting system should pay attention to this and adjust the steering parameters of the multigrid solver carefully to achieve sufficient convergence without sacrificing too much computing time for the perturbation-pressure solution. }}} |---------------- {{{#!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) = [#pt_surface pt_surface] + [#pt_surface_initial_change pt_surface_initial_change] + [#pt_surface_heating_rate pt_surface_heating_rate] * time_since_3d_model_start (the user may change this value during the run using [../userint#user-defined 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'\\\\ ('nested' for nest domains) }}} {{{#!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.\\\\ In case of nested run, the default value of '''bc_pt_t''' in the nest domains is not '' 'initial_gradient' '' but '' 'nested' '' instead. For the root domain of a nested run the default is '' 'initial_gradient' '' as usually.\\ In case of [../nestofflpar offline nesting] 'bc_pt_t' is set internally to Dirichlet boundary conditions. }}} |---------------- {{{#!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 water vapor / total water mixing ratio.\\\\ 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 [../userint#user-defined 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'\\\\ ('nested' for nest domains) }}} {{{#!td Top boundary condition of the water vapor / total water mixing ratio.\\\\ Allowed are the values '' 'dirichlet' '' (q(k=nz+1) does 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 to k=nz the prognostic equation for q is solved).\\\\ In case of nested run, the default value of '''bc_q_t''' in the nest domains is not '' 'neumann' '' but '' 'nested' '' instead. For the root domain of a nested run the default is '' 'neumann' '' as usually.\\ In case of [../nestofflpar offline nesting] 'bc_q_t' is set internally to Dirichlet boundary conditions. }}} |---------------- {{{#!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" 'initial_gradient'\\\\ ('nested' for nest domains) }}} {{{#!td Top boundary condition of the scalar concentration.\\\\ Allowed are the values '' 'dirichlet' '' (s(k=nz+1) does not change during the run), '' 'neumann' '' (s(k=nz+1) = s(k=nz)), and '' 'initial_gradient' ''. With the '' 'initial_gradient' '' 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). When a constant scalar flux is used at the top boundary ([#top_scalarflux top_scalarflux]), bc_s_t = 'neumann' must be used, because otherwise the resolved scale may contribute to the top flux so that a constant value cannot be guaranteed.\\\\ In case of nested run, the default value of '''bc_s_t''' in the nest domains is not '' 'initial_gradient' '' but '' 'nested' '' instead. For the root domain of a nested run the default is '' 'initial_gradient' '' as usually.\\\\ }}} |---------------- {{{#!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. The Neumann boundary condition yields the free-slip condition with u(k=0) = u(k=1) and v(k=0) = v(k=1). With a constant flux layer switched on (see [#constant_flux_layer constant_flux_layer]) at the bottom boundary, 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'\\\\ ('nested' for nest domains) }}} {{{#!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.\\\\ In case of nested run the default value of '''bc_uv_t''' in the nest domains is not '' 'dirichlet' '' but '' 'nested' '' instead. For the root domain of a nested run the default is '' 'dirichlet' '' as usually.\\\\ }}} |---------------- {{{#!td style="vertical-align:top" [=#constant_flux_layer '''constant_flux_layer'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .T. }}} {{{#!td Parameter to switch on a constant flux layer at the bottom boundary.\\\\ By default, a constant flux 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 a constant flux layer switched off at the bottom, the pressure boundary condition [#bc_p_b bc_p_b] = '' 'neumann+inhomo' '' is not allowed.\\\\ If the constant flux 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" [=#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 turbulence signal is damped to zero (in m).\\\\ See [#inflow_damping_height inflow_damping_height] for an 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 (grid points).\\\\ If non-cyclic lateral boundary conditions are used (see [#bc_lr bc_lr] or [#bc_ns bc_ns]), this parameter gives the grid point number (counted horizontally from the inflow) from which on perturbations are imposed on the horizontal velocity field. Perturbations must be switched on with parameter [../runtime_parameters#create_disturbances create_disturbances]. Note that these inflow perturbances are added '''in addition''' to the standard perturbances that are activated with [../runtime_parameters#create_disturbances create_disturbances]. }}} |---------------- {{{#!td 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 (grid points).\\\\ If non-cyclic lateral boundary conditions are used (see [#bc_lr bc_lr] or [#bc_ns bc_ns]), this parameter gives the grid point number (counted horizontally from the inflow) up to which perturbations are imposed on the horizontal velocity field. Perturbations must be switched on with parameter [../runtime_parameters#create_disturbances create_disturbances]. }}} |---------------- {{{#!td style="vertical-align:top" [=#outflow_source_plane '''outflow_source_plane'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" - }}} {{{#!td Horizintal position (in m) of the vertical source plane from where instantaneous values of u, v, w, pt, q, s, and e are copied to the outflow boundary in case of [#turbulent_outflow turbulent_outflow]=.TRUE.. The position needs to be given as the distance from the inflow boundary. The source plane must be positioned inside the model domain. }}} |---------------- {{{#!td style="vertical-align:top" [=#recycling_method_for_thermodynamic_quantities '''recycling_method_for_thermodynamic_quantities'''] }}} {{{#!td style="vertical-align:top" C*80 }}} {{{#!td style="vertical-align:top" 'turbulent_fluctuation' }}} {{{#!td If [#turbulent_inflow turbulent_inflow] = .TRUE., two recycling methods for the thermodynamic quantities theta and q are available:\\\\ 'turbulent_fluctuation': Turbulent fluctuations of theta (and q if humidity = .TRUE.) are recycled and added to the inflow profile, see [#turbulent_inflow turbulent_inflow] for a detailed description. This method is the default method and is also used for all other prognostic quantities. If surface heating/cooling or a surface waterflux is applied, a horizontal temperature (humidity) gradient inside the boundary layer will develop, because the temperature/humidity profiles at the inflow are constant. The resulting horizontal differences in buoyancy can trigger an undesired circulation inside the entire domain and instabilities at the inflow boundary (see [#pt_damping_factor pt_damping_factor]).\\\\ 'absolute_value': The absolute instantaneous values of theta (and q if humidity = .TRUE.) are recycled, so that the potential temperature (humidity) values at the inflow boundary and the recycling plane are identical. With this method there is no horizontal temperature (humidity) gradient and thus the circulation and the instabilities at the inflow boundary will not occur. Note that the mean inflow profile of the potential temperature (humidity) will now change in time (growing boundary layer), in contrast to the inflow profile of all other quantities (e.g. u,v,w) that are constant. In order to avoid this mismatch, the boundary layer height should be kept constant by applying a [#large_scale_subsidence large_scale_subsidence] to scalar quantities. }}} |---------------- {{{#!td style="vertical-align:top" [=#recycling_width '''recycling_width'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" - }}} {{{#!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" [=#roughness_length '''roughness_length'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.1 }}} {{{#!td Roughness length (in m).\\\\ The roughness length for scalars can be given a value different from the one for momentum (see [#z0h_factor z0h_factor]). \\\\ This parameter is effective only in case that a constant flux layer is switched on at the bottom boundary (see [#constant_flux_layer constant_flux_layer]). }}} |---------------- {{{#!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 the 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 constant flux layer is switched off ([#constant_flux_layer constant_flux_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 time step by u,,*,, {{{*}}} theta,,*,, (of course only with [#constant_flux_layer constant_flux_layer] switched on). Here, u,,*,, and theta,,*,, are calculated from Monin-Obukhov similarity theory 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.\\\\ Non-zero values must not be given for '''surface_heatflux''' in case of simulations with pure neutral stratification (see parameter [#neutral neutral]).\\\\ 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" 9999999.9 }}} {{{#!td Scalar flux at the surface (in kg m^-2^ s^-1^ (particle flux) or ppm m s^-1^ (gaseous flux)).\\\\ If a 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''' = ''9999999.9 ''), it is calculated at each time step by u,,*,, {{{*}}} s,,*,, (of course only with [#constant_flux_layer constant_flux_layer] switched on). Here, s,,*,, is calculated from Monin-Obukhov similarity theory 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\\ waterflux }}} {{{#!td Kinematic water flux near the surface (in kg/kg 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 water vapor / total water mixing ratio (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 time step by u,,*,, {{{*}}} q,,*,, (of course only with a constant flux layer switched on). Here, q,,*,, is calculated from Monin-Obukhov similarity theory 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 top boundary sensible heat flux is initialized with the value of '''top_heatflux''' as the 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 constant flux layer is available at the top boundary so far.\\\\ Non-zero values must not be given for '''top_heatflux''' in case of simulations with pure neutral stratification (see parameter [#neutral neutral]).\\\\ 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 the 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 constant flux 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 the 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 constant flux 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_scalarflux '''top_scalarflux'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" no prescribed\\ scalarflux }}} {{{#!td Scalar flux at the top boundary (in kg m^-2^ s^-1^ (particle flux) or ppm m s^-1^ (gaseous flux)).\\\\ If a value is assigned to this parameter, the internal two-dimensional surface scalar flux field {{{sswst}}} is initialized with the value of '''top_scalarflux''' as the top (horizontally homogeneous) boundary condition for the scalar equation. This additionally requires that a Neumann condition must be used for the scalar (see [#bc_s_t bc_s_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 scalar flux additionally requires the setting of initial parameter [#use_top_fluxes use_top_fluxes] = ''.T.''.\\\\ No constant flux layer is available at the top boundary so far. }}} |---------------- {{{#!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 must 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 height 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].\\\\ For thermodynamic quantities it is also possible to recycle the absolute values instead of the turbulent fluctuations by setting [#recycling_method_for_thermodynamic_quantities recycling_method_for_thermodynamic_quantities] to 'absolute_value'.\\\\ The detailed setup for a turbulent inflow is described in [../examples/turbinf here]. }}} |---------------- {{{#!td style="vertical-align:top" [=#turbulent_outflow '''turbulent_outflow'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td When set true, a turbulent outflow condition is used at the outflow boundary. This outflow condition works similar to the turbulent recycling method, but instantaneous values are copied from a vertical source plane (see [#outflow_source_plane outflow_source_plane]) from inside the domain to the outflow boundary. This prevents numerical errors which can occur if negative velocity values appear at the outflow boundary while using the radiation boundary condition.\\\\ For using this outflow method [#bc_lr bc_lr] = '' 'dirichlet/radiation' '' is required. This method can only be used for an outflow boundary at the right model boundary, so far.\\\\ The vertical source plane from where to copy the values of u, v, w, pt, q, s, and e should be placed not too close to the outflow boundary. }}} |---------------- {{{#!td style="vertical-align:top" [=#use_free_convection_scaling '''use_free_convection_scaling'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter to switch on the use of the local free convection velocity scale {{{w_lfc}}}. When switched on, {{{w_lfc}}} is added to the horizontal wind velocity for use in the constant flux layer parameterization to calculate the Obukhov length and the friction velocity {{{u_*}}} over horizontally-aligned surfaces. The horizontal velocity {{{u_h}}} at height of the first vertical grid level {{{z_mo}}} is then calculated as: {{{ #!Latex $$u_\mathrm{h} = \left(u(z_\mathrm{mo})^2 + v(z_\mathrm{mo})^2 + w_\mathrm{lfc}^2\right)^{1/2}$$ }}} with {{{ #!Latex $$w_\mathrm{lfc} = \left( \frac{g}{\theta(z_\mathrm{mo})} * z_\mathrm{mo} * \overline{w'\theta'}_0\right)^{1/3}$$ }}} This is particularly useful in simulations of convective boundary layers where the local near-surface wind is expected to close to zero, e.g. in urban environments when the present buildings create spots of stagnant air. {{{w_lfc}}} accounts for the dominant eddies close to the surface that cannot be resolved by the LES model and increases {{{u_h}}} by a small amount. When using the land surface scheme, this might prevent the surface sensible heat flux from dropping to zero under no-wind conditions. }}} |---------------- {{{#!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 Monin-Obukhov similarity theory (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 constant flux layer is used (see [#constant_flux_layer constant_flux_layer]).\\\\ The user may prescribe the surface fluxes at the bottom boundary without using a constant flux layer by setting '''use_surface_fluxes''' = ''.T.'' and [#constant_flux_layer constant_flux_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. }}} |---------------- {{{#!td style="vertical-align:top" [=#y_shift '''y_shift'''] }}} {{{#!td style="vertical-align:top" I }}} {{{#!td style="vertical-align:top" 0 }}} {{{#!td '''In case of cyclic boundary conditions:'''\\ Shifts the left/right boundary by multiples of a subdomain size along y.\\ Requires [#bc_lr bc_lr] = 'cyclic', [#bc_ns bc_ns] = 'cyclic' and [#psolver psolver] = 'multigrid'.\\\\ This parameter introduces a shift by multiples of a subdomain size in y-direction at the left/right domain boundary. The shift is such that a point (coordinate y=yr) on the right domain boundary no longer corresponds with the point with the same y-coordinate on the left boundary, but instead with the point with the coordinate {{{y=yr+y_shift*(ny+1)/npey}}}. Conversely, a point on the left boundary with coordinate {{{y=yl}}} corresponds with the point on the right boundary with the coordinate {{{y=yl-y_shift*(ny+1)/npey}}}.\\ Negative values and also those that exceed npey are allowed. They are transformed to the range {{{[0,npey-1]}}} internally.\\\\ This feature has been implemented to alleviate the occurrence of streak-like structures that appear during simulations with neutral stratification, cyclic boundary conditions, and driving velocity with no v-component. For a description of these structures, see Munters (2016; ​http://www.dx.doi.org/10.1063/1.4941912).\\\\ '''Schematic of the y_shift method:'''\\ (Model domain with [#npex npex] = [#npey npey] = 5 and y_shift = 1)\\ [[Image(y_shift_pic.png,260px)]]\\\\ '''In case of [#bc_lr bc_lr] = 'dirichlet/radiation' and [#turbulent_inflow turbulent_inflow] = .TRUE.:'''\\ Parameter to define a y-shift for the recycled inflow turbulence, given in multiples of PE. E.g. with y_shift = 3 the turbulent fluctuations, obtained at the recycling plane, will be shifted by 3 processors in positive y-direction before being imposed on the inflow. The parameter y_shift replaces the deprecated parameter recycling_yshift since revision r4301. }}} |---------------- {{{#!td style="vertical-align:top" [=#z0h_factor '''z0h_factor'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 1.0 }}} {{{#!td Factor for calculating the roughness length for scalars.\\\\ This parameter can be used to define a value for the roughness length for scalars (potential temperature, humidity/scalar) which differs from the one for momentum. The roughness length for scalars z0h is calculated as: \\ z0h = z0h_factor * [#roughness_length roughness_length]. \\ This parameter is effective only in case that a constant flux layer is switched on at the bottom boundary (see [#constant_flux_layer constant_flux_layer]). }}} |---------------- {{{#!td style="vertical-align:top" [=#zeta_max '''zeta_max'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 20.0 }}} {{{#!td Upper limit of the stability parameter {{{[zeta = z_mo/L}}}, with {{{z_mo}}} being the height of the constant flux layer, and {{{L}}} being the Obukhov length.\\\\ With a constant flux layer switched on (see [#constant_flux_layer constant_flux_layer]), the Obukhov length ('''ol''') is calculated for {{{z=z_mo (k=1)}}} in the 3d-model (in the [../../tec/1dmodel 1d-model] for all heights) for each horizontal grid point. Its particular values 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 top of the constant flux layer or small vertical wind shears in the 1d-model, the stability parameter '''zeta = z_mo/ol''' can take up unrealistic values. They are limited by an upper ('''zeta_max''') and lower limit (see [#zeta_min zeta_min]). The condition '''zeta_max''' > zeta_min must be met. }}} |---------------- {{{#!td style="vertical-align:top" [=#zeta_min '''zeta_min'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" -20.0 }}} {{{#!td Lower limit of the stability parameter {{{[zeta = z_mo/L}}}, with {{{z_mo}}} being the height of the constant flux layer, and {{{L}}} being the Obukhov length.\\\\ For further explanations see [#zeta_max zeta_max]. The condition zeta_max > '''zeta_min''' must be met. }}} [[BR]] [=#ini '''Initialization:]\\ ||='''Parameter Name''' =||='''[../fortrantypes FORTRAN]\\[../fortrantypes Type]''' =||='''Default\\Value''' =||='''Explanation''' =|| |---------------- {{{#!td style="vertical-align:top" [=#calc_soil_moisture_during_spinup '''calc_soil_moisture_during_spinup'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter for switching on water transport equation in the soil model during the spinup phase (see [#spinup_time spinup_time]). If set to .TRUE. an additional prognostic equation for the volumetric moisture content of the soil layer is solved. }}} |---------------- {{{#!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(nzt+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 point 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" [=#data_output_during_spinup '''data_output_during_spinup'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter for switching on data output in the spinup phase (see [#spinup_time spinup_time]). If set to .TRUE. timeseries and profile data will be output at regular intervals as prescribed by the user. Note that there will be no output of 2D/3D/masked data during the spinup phase. For radiation calculations during spinup, a starting time is calculated based on the setting of [#origin_date_time origin_date_time], so that the spinup starts at {{{origin_date_time - spinup_time}}}. The coupled run then starts at {{{origin_date_time}}}. In the output data, the timestamps during spinup will show negative values in the output data so that the coupled model system starts at timestamp 0 s. }}} |---------------- {{{#!td style="vertical-align:top" [=#dissipation_1d '''dissipation_1d'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'detering' }}} {{{#!td Calculation method for the energy dissipation term in the TKE equation of the [../../tec/1dmodel 1d-model].\\\\ By default (since r1691) '''dissipation_1d''' = '' 'detering' '' forces the dissipation to be calculated as diss = 0.064 * e^1.5^ / l.\\\\ When setting '''dissipation_1d''' = '' 'as_in_3d_model' '' (default before r1691), the dissipation is calculated as in the 3d-model using diss = (0.19 + 0.74 * l / l_grid) * e^1.5^ / l. Since r2918, this option requires that [#mixing_length_1d mixing_length_1d] = '' 'as_in_3d_model'.'' }}} |---------------- {{{#!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 automatically calculated after each time step in order to follow the Courant Friedrichs Levy (CFL) criterion. This value is then used for the next step.\\\\ If '''dt''' is assigned a value, then the time step is fixed to this value throughout the whole run (whether it fulfills the time step criteria or not). However, changes are allowed for restart runs, because '''dt''' can also be used as a [../runtime_parameters run parameter].\\\\ In case that the automatically calculated time step meets the condition\\\\ '''dt''' < 0.00001 * [../runtime_parameters#dt_max dt_max] (with dt_max = 20.0)\\\\ the simulation will be aborted. Such situations usually arise in case of any numerical problem / instability which causes a non-realistic increase of the wind speed.\\\\ A small time step due to a large mean horizontal wind speed may be enlarged by using a coordinate transformation (see [#galilei_transformation galilei_transformation]), in order to spare CPU time.\\\\ '''Warning:''' The simulation will crash in case of a fixed '''dt''', if the given value violates the CFL criterion at any time throughout the run. Even worse, the simulation may continue to run up to the end, producing NaN data, if you have not switched on the floating point error detection by setting a respective compiler option (e.g. {{{-fpe0}}} for the Intel compiler). You should run the case without setting '''dt''' first, and check how small the timestep can become. }}} |---------------- {{{#!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" [=#dt_spinup '''dt_spinup'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 5.0 }}} {{{#!td Time step during integration of the land surface, urban surface, and radiation models during the spinup phase (see [#spinup_time spinup_time]). Longer time steps than the default value of 60 s can be considered, depending on the precise configuration of the respective surface models. Please note, we have recurrently experienced that the soil/wall spinup becomes unstable when the timestep is chosen too large. Hence, we recommend to use smaller values of dt_spinup <= 10 s. }}} |---------------- {{{#!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" [=#ensemble_member_nr '''ensemble_member_nr'''] }}} {{{#!td style="vertical-align:top" I }}} {{{#!td style="vertical-align:top" 0 }}} {{{#!td By setting the initialization parameter [#ensemble_member_nr ensemble_member_nr] to an integer between 1 and 2000, palm will produce statistically independent members of a simulation.\\ \\ This parameter can only be used, if '''[#random_generator random_generator]''' = '' 'random-parallel' '' is set. }}} |---------------- {{{#!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 (or horizontal current profile in case of ocean mode runs) 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.\\\\ Instead of using the geostrophic wind for constructing the initial u,v-profiles, these profiles can also be directly set using parameters [#u_profile u_profile], [#v_profile v_profile], and [#uv_heights uv_heights], e.g. if observed profiles shall be used as initial values. In runs with non-cyclic horizontal boundary conditions these profiles are also used as fixed mean inflow profiles.\\\\ '' '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 a constant flux layer switched on ol, 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 and surface-related quantities 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 a 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 height and diffusion switched off (see '' 'initialize_vortex' ''). Additionally, the buoyancy term must be switched off 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}}}).\\\\ '' 'initialize_bubble' ''\\\\ A 2d-Gauss-like shaped perturbation (y,z) of 0.4K is added to the initial temperature field at a height of 150m and in the middle concerning the y-direction. The temperature perturbation decreases with a standard deviation of 300m and 150m in y-direction and z-direction, respectively. This method might be very helpful to induce a rising warm air bubble producing clouds in a humid environment.\\\\ '' '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 required 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]. \\ Note that in case of [#reference_state reference_state]='' 'initial_profile','' the main run uses the initial profile of the precursor run. \\\\ '' 'inifor' ''\\\\ Initialization with provided input data derived from larger-scale model (COSMO data). \\\\ Values may be combined, e.g. '''initializing_actions''' = '' 'set_constant_profiles initialize_vortex' '', but the values of '' 'set_constant_profiles' '', '' 'set_1d-model_profiles' '' , '' 'cyclic_fill' '', '' 'read_restart_data' '', '' 'inifor' '' 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" 'blackadar' }}} {{{#!td Mixing length used in the [../../tec/1dmodel 1d-model].\\\\ By default, '''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).\\\\ By setting '''mixing_length_1d''' = '' 'as_in_3d_model','' the mixing length is calculated as in the 3d-model (i.e. it depends on the grid spacing). }}} |---------------- {{{#!td style="vertical-align:top" [=#origin_date_time '''origin_date_time'''] }}} {{{#!td style="vertical-align:top" C }}} {{{#!td style="vertical-align:top" '2019-06-21 12:00:00 +00' }}} {{{#!td Date and time at model start. The default is set to 21st of June 2019 at 12UTC (noon). Further examples:\\ Setting model-start time to 14th May 1995 at 16:30 CEST: '''1995-05-14 16:30:00 +02'''\\ Same time, but using UTC: '''1995-05-14 14:30:00 +00'''\\ Same time, but using PST (American Pacific Standard Time): '''1995-05-14 06:30:00 -08'''\\ Same time, but using AEST (Australian Eastern Standard Time): '''1995-05-15 02:30:00 +10''' Note, that PALM always uses UTC internally. If you specify a time zone different from UTC, the time is converted internally to UTC. Output will always use UTC. See [#use_fixed_date use_fixed_date] and [#use_fixed_time use_fixed_time] for further time-related options. Please see also possible side effects concerning the time-coordinates in the [../iofiles/pids/dynamic dynamic input file]. }}} |---------------- {{{#!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 mode runs, 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_heating_rate '''pt_surface_heating_rate'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Linear surface temperature increase in K/h.\\ Instead of prescribing a [#surface_heatflux surface_heatflux] also a surface heating rate can be prescribed by setting '''pt_surface_heating_rate''' to a non-zero value. Surface cooling can be achieved by assigning a negative value.\\ Set [#bc_pt_b bc_pt_b] = '' 'dirichlet' ''.\\ The surface heating can be combined with [#pt_surface_initial_change pt_surface_initial_change]. }}} |---------------- {{{#!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. Below the first prescribed height level, the temperature is automatically set constant with height. 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 mode runs, 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 above which 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 mode runs, 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 water vapor / total water mixing ratio (kg/kg).\\\\ This parameter assigns the value of the mixing ratio '''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 water vapor / total water mixing ratio 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" [=#spinup_pt_amplitude '''spinup_pt_amplitude'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Representative amplitude of the diurnal near-surface temperature variation during the spinup phase (see [#spinup_time spinup_time]). Note that this amplitude does not match the true temperature amplitude during spinup. The true amplitude depends also on the incoming shortwave radiation and thus depends on the day of the year and the geographic location. }}} |---------------- {{{#!td style="vertical-align:top" [=#spinup_pt_mean '''spinup_pt_mean'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" value of [#pt_surface pt_surface] }}} {{{#!td Mean near-surface air temperature during the spinup phase (see [#spinup_time spinup_time]). If no value is provided, the mean will be inferred from the setting of [#pt_surface pt_surface]. }}} |---------------- {{{#!td style="vertical-align:top" [=#spinup_time '''spinup_time'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 0.0 }}} {{{#!td Parameter for steering the length of the soil/wall spinup phase (in s). The soil/wall spinup allows for the adjustment of the inert soil- and wall-layer temperatures to the prevailing atmospheric conditions, prior to the actual 3D atmosphere simulation. This saves a significant amount of computational time because during the spinup phase, the soil and wall models run without an interactive atmosphere. Currently, this mechanism is implemented for the land surface and the urban surface model. In the spinup phase, these models predict the skin and soil/wall temperatures. All window temperatures (surface and deeper layers) are not calculated during spinup. For using the spinup mechanism it is required to have a radiation model activated. Forcing is achieved by radiation and optionally a varying near-surface air temperature (steered via [#spinup_pt_mean spinup_pt_mean], [#spinup_pt_amplitude spinup_pt_amplitude], and the incoming solar radiation. After completion of the spinup, the atmospheric code is switched on and runs coupled to the surface models. On the timeline, the spinup phase has negative times counting towards 0 s, which is when the atmosphere is activated. Note that the near-surface temperatures are reset before coupling to their initial values prescribed by the user. The spinup mechanism can be steered via the additional parameters [#dt_spinup dt_spinup] and [#data_output_during_spinup data_output_during_spinup]. }}} |---------------- {{{#!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 [../bulk_cloud_parameters#bulk_cloud_model bulk_cloud_model] = ''.T.''). }}} |---------------- {{{#!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^ (particles) or ppm (gases)).\\\\ 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^ (particles) or ppm (gases)).\\\\ 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 (particles) or ppm / 100m (gases)).\\\\ 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" [=#u_profile '''u_profile'''] }}} {{{#!td style="vertical-align:top" R(100) }}} {{{#!td style="vertical-align:top" 100 * 9999999.9 }}} {{{#!td Values of u-velocity component to be used as initial profile (in m/s).\\\\ The corresponding height levels have to be provided by parameter [#uv_heights uv_heights]. The first velocity value always has to be assigned to the surface and must be zero, i.e. {{{u_profile(1)}}} = 0.0. Velocity values for the model grid levels are calculated from the given values by linear interpolation. If the uppermost value is given for a height smaller than the domain height, this value will be used for all grid points above this level. In runs with non-cyclic horizontal boundary conditions this profile will be used as fixed mean inflow profile.\\\\ '''Note:''' Simultaneous use of forcing by geostrophic wind is not allowed, since this could lead to inconsistencies in the flow forcing. Hence, [#omega omega] = 0.0 must be set when using '''u_profile''' and [#v_profile v_profile]. The latter flow forcing is typically used for simulating wind-tunnel applications (effect of Coriolis force negligible) in order to fairly reproduce the measured wind-tunnel profiles within the LES. }}} |---------------- {{{#!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 mode runs, this parameter gives the u-component of 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/100 m/s*1/m).\\\\ 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 mode runs, 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 mode runs, the (negative) height levels have to be assigned in descending order. }}} |---------------- {{{#!td style="vertical-align:top" [=#uv_heights '''uv_heights'''] }}} {{{#!td style="vertical-align:top" R(100) }}} {{{#!td style="vertical-align:top" 100 * 9999999.9 }}} {{{#!td Height levels in ascending order (in m), for which prescribed u,v-velocities are given (see [#u_profile u_profile], [#v_profile v_profile]. The first height level must always be zero, i.e. uv_heights(1) = 0.0. }}} |---------------- {{{#!td style="vertical-align:top" [=#v_profile '''v_profile'''] }}} {{{#!td style="vertical-align:top" R(100) }}} {{{#!td style="vertical-align:top" 100 * 9999999.9 }}} {{{#!td Values of v-velocity component to be used as initial profile (in m/s).\\\\ The corresponding height levels have to be provided by parameter [#uv_heights uv_heights]. The first velocity value always has to be given for the surface and must be zero, i.e. {{{v_profile(1)}}} = 0.0. Velocity values for the model grid levels are calculated from the given values by linear interpolation. If the uppermost value is given for a height smaller than the domain height, this value will be used for all grid points above this level. In runs with non-cyclic horizontal boundary conditions this profile will be used as fixed mean inflow profile.\\\\ '''Note:''' Simultaneous use of forcing by geostrophic wind is not allowed, since this could lead to inconsistencies in the flow forcing. Hence, [#omega omega] = 0.0 must be set when using '''v_profile''' and [#u_profile u_profile]. The latter flow forcing is typically used for simulating wind-tunnel applications (effect of Coriolis force negligible) in order to fairly reproduce the measured wind-tunnel profiles within the LES. }}} |---------------- {{{#!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 mode runs, this parameter gives the v-component of 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 mode runs, 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 mode runs, 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" [=#complex_terrain '''complex_terrain'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td Parameter to enable simulations featuring complex topography. If the run is initialized using the cyclic fill method ([#initializing_actions initializing_actions]= '' 'cyclic_fill' ''), the initial 3D-data is shifted vertically for each grid point in the horizontal plane according to local surface height. The mean inflow profiles of the turbulence recycling method (see [#turbulent_inflow turbulent_inflow]) can be prescribed at an elevated position by setting the topography height to a non-zero value inside the recycling plane. However, the topography height must exhibit a constant value within the entire recycling plane! If '''complex_terrain''' = .T., it is not allowed to use vertical grid stretching. The topography mode must be set to '' 'read_from_file' '' (see [#topography topography]). }}} |---------------- {{{#!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 [../iofiles#TOPOGRAPHY_DATA TOPOGRAPHY_DATA]. This file contains the arbitrary topography height information in m. These data must exactly match the horizontal grid. '' 'tunnel' '' Flow within a tunnel of finite or infinite length oriented either in x- or in y-direction. The height of the tunnel outer top wall can be specified by [#tunnel_height tunnel_height]. The tunnel length and width can be specified via [#tunnel_length tunnel_length] and either [#tunnel_width_x tunnel_width_x] or [#tunnel_width_y tunnel_width_y]. Furthermore, the depth of tunnel walls can be specified by [#tunnel_wall_depth tunnel_wall_depth]. Note, tunnels are always centered in the model domain along x- and y-direction. '' 'closed_channel' '' Flow within a closed channel with walls at both the lower (w(k=0) and scalar(k=0)) and upper boundary (w(k=nzt) and scalar(k=nzt+1)). Note that PALM's default grid structure (see [../../tec/discret#Spatialdiscretization spatial discretization]) is modified in a closed channel (w(k=nzt) and scalar(k=nzt+1) are defined at the same height) because investigating this flow requires a symmetric model domain. For this special topography [#constant_flux_layer constant_flux_layer] = ''.T.'', [#momentum_advec momentum_advec] /= '' 'ws-scheme' '' and [#scalar_advec scalar_advec] /= '' 'ws-scheme' '' are not allowed. \\\\ 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 [#psolver psolver] /= '' 'sor' '', [#alpha_surface alpha_surface] = 0.0, [#galilei_transformation galilei_transformation] = ''.F.'', [#cloud_droplets cloud_droplets] = ''.F.'' (has not been tested), and [#constant_flux_layer constant_flux_layer] = ''.T.'' (except closed channel flow).\\\\ '''Note: ''' In case there are holes in the topography that are resolved by only one grid point, the topography array in filtered so that such holes are filled up to the minimum topography height of the directly adjoining grid points in the x- and the y-direction. This is necessary, because for such chimney-like features resolved by one grid point, the continuity equation is not fulfilled on a discrete grid, as the only degree of freedom for the pressure solver is the vertical. Such holes are suspected to lead to unrealistic velocity blow-ups, hence, they are filled up. \\ 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 defines 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','' or '' 'tunnel',''\\ * 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', '' '' 'tunnel', '' 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" [=#tunnel_height '''tunnel_height'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" zw(INT(0.2*nz)) }}} {{{#!td Height of tunnel top (outer wall). }}} |---------------- {{{#!td style="vertical-align:top" [=#tunnel_length '''tunnel_length'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 9999999.9 }}} {{{#!td Length of the tunnel. ''tunnel_length'' can be smaller (open tunnel) or larger (infinite tunnel) than the model-domain extents along the tunnel axis. }}} |---------------- {{{#!td style="vertical-align:top" [=#tunnel_width_x '''tunnel_width_x'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 9999999.9 }}} {{{#!td Width of the tunnel along x-direction with respect to the tunnel outer walls. A non-default value indicates a tunnel orientation along y. The tunnel width must be at least larger than 2 * [#dx dx] + 2 * [#tunnel_wall_depth tunnel_wall_depth]. }}} |---------------- {{{#!td style="vertical-align:top" [=#tunnel_width_y '''tunnel_width_y'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" 9999999.9 }}} {{{#!td Width of the tunnel along y-direction with respect to the tunnel outer walls. A non-default value indicates a tunnel orientation along x. The tunnel width must be at least larger than 2 * [#dy dy] + 2 * [#tunnel_wall_depth tunnel_wall_depth]. }}} |---------------- {{{#!td style="vertical-align:top" [=#tunnel_wall_depth '''tunnel_wall_depth'''] }}} {{{#!td style="vertical-align:top" R }}} {{{#!td style="vertical-align:top" max( dx, dy, dz ) }}} {{{#!td Depth of the tunnel walls. }}} |---------------- {{{#!td style="vertical-align:top" [=#wall_heatflux '''wall_heatflux'''] }}} {{{#!td style="vertical-align:top" R(0:5) }}} {{{#!td style="vertical-align:top" 6 * 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\\ '''wall_heatflux'''(5) bottom face\\\\ This parameter applies only in case of a non-flat topography. Prescribing wall_heatflux additionally requires setting of [#surface_heatflux surface_heatflux]. Furthermore, please note that wall_heatflux(0) only describes the kinematic flux at non-zero height. At zero-height (surface) the kinematic flux is given by [#surface_heatflux surface_heatflux] instead. \\\\ 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\\ '''wall_humidityflux'''(5) bottom face\\\\ This parameter applies only in case of a non-flat topography and [#humidity humidity] = ''.T.''. Prescribing wall_humidityflux additionally requires setting of [#surface_waterflux surface_waterflux]. Furthermore, please note that wall_humidityflux(0) only describes the kinematic flux at non-zero height. At zero-height (surface) the kinematic flux is given by [#surface_waterflux surface_waterflux] instead. }}} |---------------- {{{#!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 at the five topography faces (in kg m^-2^ s^-1^ (particle flux) or ppm m s^-1^ (gaseous flux)):\\\\ '''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\\ '''wall_scalarflux'''(5) bottom face\\\\ This parameter applies only in case of a non-flat topography and [#passive_scalar passive_scalar] = ''.T.''. Prescribing wall_scalarflux additionally requires setting of [#surface_scalarflux surface_scalarflux]. Furthermore, please note that wall_scalarflux(0) only describes the kinematic flux at non-zero height. At zero-height (surface) the kinematic flux is given by [#surface_scalarflux surface_scalarflux] instead. }}} [[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 setting '''alpha_surface''' unequal to zero 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'.''\\\\ In the case of [#alpha_surface alpha_surface] /= 0.0 the simultaneous use of [#humidity humidity] = ''.TRUE.'' is not allowed.\\\\ 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. }}} |---------------- {{{#!td style="vertical-align:top" [=#netcdf_precision '''netcdf_precision'''] }}} {{{#!td style="vertical-align:top" C*20 (10) }}} {{{#!td style="vertical-align:top" single precision for all output quantities }}} {{{#!td Defines the accuracy of the netCDF output.\\\\ By default, all netCDF output data have single precision (4 byte) accuracy. Double precision (8 byte) can be choosen alternatively.\\ Accuracy for the different output data (cross sections, 3d-volume data, spectra, etc.) can be set independently.\\ '' '_NF90_REAL4' '' (single precision) or '' '_NF90_REAL8' '' (double precision) are the two principally allowed values for netcdf_precision, where the string '' '' '' can be chosen out of the following list:\\ ||'' 'xy' '' ||horizontal cross section || ||'' 'xz' '' ||vertical (xz) cross section || ||'' 'yz' '' ||vertical (yz) cross section || ||'' '2d' '' ||all cross sections|| ||'' '3d' '' ||volume data || ||'' 'pr' '' ||vertical profiles || ||'' 'ts' '' ||time series, particle time series || ||'' 'sp' '' ||spectra || ||'' 'prt' '' ||particles || ||'' 'all' '' ||all output quantities || \\ '''Example:'''\\ If all cross section data and the particle data shall be output in double precision and all other quantities in single precision, then '''netcdf_precision''' = '' '2d_NF90_REAL8' '', '' 'prt_NF90_REAL8' '' has to be assigned. }}} |---------------- {{{#!td style="vertical-align:top" [=#restart_data_format '''restart_data_format'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" 'fortran_binary' }}} {{{#!td Binary format of the input and output restart files.\\\\ Allowed values are '' 'fortran_binary' '', '' 'mpi' '', and '' 'mpi_shared_memory' ''. In case of '' 'fortran_binary' '' each core reads/writes its own file. In case of '' 'mpi' '', the I/O is done using a single file. This method can also be used in serial mode (when PALM has been compiled without {{{-D__parallel}}} option). In such a case, restart I/O is carried out using POSIX calls.\\\\ On many-core processors the I/O speed can be increased by setting '''restart_data_format''' = '' 'mpi_shared_memory' ''. With this setting, I/O is performed only by a limited number of cores on each of the nodes. With mpi every core writes and reads its relevant data. With mpi_shared_memory, only every 4th (or any other multiple integer of the cores per node) reads and writes data and distributes it to the other cores. This is possible since all processes on a node can share their memory. With this, the IO rates might increase. This parameter can also be used in the runtime parameter NAMELIST. }}} |---------------- {{{#!td style="vertical-align:top" [=#restart_data_format_input '''restart_data_format_input'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" value of [#restart_data_format restart_data_format] }}} {{{#!td Binary format of the input restart file.\\\\ See [#restart_data_format restart_data_format] for allowed values. This parameter can also be used in the runtime parameter NAMELIST. }}} |---------------- {{{#!td style="vertical-align:top" [=#restart_data_format_output '''restart_data_format_output'''] }}} {{{#!td style="vertical-align:top" C*20 }}} {{{#!td style="vertical-align:top" value of [#restart_data_format restart_data_format] }}} {{{#!td Binary format of the output restart file.\\\\ See [#restart_data_format restart_data_format] for allowed values. This parameter can also be used in the runtime parameter NAMELIST. }}} |---------------- {{{#!td style="vertical-align:top" [=#statistic_regions '''statistic_regions'''] }}} {{{#!td style="vertical-align:top" I }}} {{{#!td style="vertical-align:top" 0 }}} {{{#!td Number of additional user-defined subdomains for which statistical analysis and corresponding output (profiles, time series) shall be made.\\\\ By default, vertical profiles and other statistical quantities are calculated as horizontal and/or volume average of the total model domain. Beyond that, these calculations can also be carried out for subdomains which can be defined using the field '''rmask''' within the user-defined software (see [../userint/subd User-defined domains]). The number of these subdomains is determined with the parameter '''statistic_regions'''. Maximum 9 additional subdomains are allowed. The parameter [../userpar#region region] can be used to assign names (identifier) to these subdomains which are then used in the headers of the output files and plots.\\\\ Data for the total domain and all defined subdomains are output to the same file(s) ([../iofiles#DATA_1D_PR_NETCDF DATA_1D_PR_NETCDF], [../iofiles#DATA_1D_TS_NETCDF DATA_1D_TS_NETCDF]). In case of '''statistic_regions''' > 0, data on the file for the different domains can be distinguished by a suffix which is appended to the quantity names. Suffix 0 means data for the total domain, suffix 1 means data for subdomain 1, etc. }}} |---------------- {{{#!td style="vertical-align:top" [=#vdi_checks '''vdi_checks'''] }}} {{{#!td style="vertical-align:top" L }}} {{{#!td style="vertical-align:top" .F. }}} {{{#!td To switch the internal controls according to VDI 3873 Part 9 on.\\\\ More information are described in the [wiki:doc/tec/evaluation Evaluation of PALM]\\\\ }}}