Runtime parameters

Output steering

Run steering

Output steering:

Parameter Name	FORTRAN Type	Default Value	Explanation
averaging_interval	R	0.0	Averaging interval for all output of temporally averaged data (in s). This parameter defines the time interval length for temporally averaged data (vertical profiles, spectra, 2d cross-sections, 3d volume data). By default, data are not subject to temporal averaging. The interval length is limited by the parameter dt_data_output_av. In any case, averaging_interval <= dt_data_output_av must hold. If an interval is defined, then by default the average is calculated from the data values of all timesteps lying within this interval. The number of time levels entering into the average can be reduced with the parameter dt_averaging_input?. If an averaging interval can not be completed at the end of a run, it will be finished at the beginning of the next restart run. Thus for restart runs, averaging intervals do not necessarily begin at the beginning of the run. Parameters averaging_interval_pr and averaging_interval_sp? can be used to define different averaging intervals for vertical profile data and spectra, respectively.
averaging_interval_pr	R	value of averaging_interval	Averaging interval for output of vertical profiles to local file DATA_1D_PR_NETCDF? (in s). If this parameter is given a non-zero value, temporally averaged vertical profile data are output. By default, profile data data are not subject to temporal averaging. The interval length is limited by the parameter dt_dopr?. In any case averaging_interval_pr <= dt_dopr must hold. If an interval is defined, then by default the average is calculated from the data values of all timesteps lying within this interval. The number of time levels entering into the average can be reduced with the parameter dt_averaging_input_pr?. If an averaging interval can not be completed at the end of a run, it will be finished at the beginning of the next restart run. Thus for restart runs, averaging intervals do not necessarily begin at the beginning of the run.
data_output	C * 10 (100)	100 * ' '	Quantities for which 2d cross section and/or 3d volume data are to be output. PALM allows the output of instantaneous data as well as of temporally averaged data which is steered by the strings assigned to this parameter (see below). By default, cross section data are output (depending on the selected cross sections(s), see below) to local files DATA_2D_XY_NETCDF?, DATA_2D_XZ_NETCDF? and/or DATA_2D_YZ_NETCDF?. Volume data are output to file DATA_3D_NETCDF?. If the user has switched on the output of temporally averaged data, these are written seperately to local files DATA_2D_XY_AV_NETCDF?, DATA_2D_XZ_AV_NETCDF?, DATA_2D_YZ_AV_NETCDF?, and DATA_3D_AV_NETCDF?, respectively. The filenames already suggest that all files have netCDF format. Informations about the file content (kind of quantities, array dimensions and grid coordinates) are part of the self describing netCDF format and can be extracted from the netCDF files using the command "ncdump -c <filename>". See netCDF data about processing the PALM netCDF data. The following quantities are available for output by default (quantity names ending with '*' are only allowed for the output of horizontal cross sections): quantity name meaning unit remarks e SGS m2/s2 lwp* liquid water path m only horizontal cross section is allowed, requires cloud_physics? = .T. p perturpation pressure N/m2, Pa pc particle/droplet concentration #/gridbox requires that particle advection is switched on by mrun-option "-p particles" pr mean particle/droplet radius m requires that particle advection is switched on by mrun-option "-p particles" pra* precipitation amount mm only horizontal cross section is allowed, requires precipitation? = .T., time interval on which amount refers to is defined by precipitation_amount_interval? prr* precipitation rate mm/s only horizontal cross section is allowed, requires precipitation? = .T. pt potential temperature K q specific humidity (or total water content, if cloud physics is switched on) kg/kg requires humidity? = .T. ql liquid water content kg/kg requires cloud_physics? = .T. or cloud_droplets? = .T. ql_c change in liquid water content due to condensation/evaporation during last timestep kg/kg requires cloud_droplets? = .T. ql_v volume of liquid water m3/gridbox requires cloud_droplets? = .T. ql_vp weighting factor requires cloud_droplets? = .T. qsws* latent surface heatflux kg/kg * m/s only horizontal cross section is allowed, requires humidity? = .T. qv water vapor content (specific humidity) kg/kg requires cloud_physics? = .T. rho potential density kg/m3 requires ocean? = .T. s concentration of the scalar 1/m3 requires passive_scalar? = .T. sa salinity psu requires ocean? = .T. shf* sensible surface heatflux K m/s only horizontal cross section is allowed t* (near surface) characteristic temperature K only horizontal cross section is allowed u u-component of the velocity m/s u* (near surface) friction velocity m/s only horizontal cross section is allowed v v-component of the velocity m/s vpt virtual potential temperature K requires humidity? = .T. w w-component of the velocity m/s z0* roughness length m Multiple quantities can be assigned, e.g. data_output = 'e', 'u', 'w' . By assigning the pure strings from the above table, 3d volume data is output. Cross section data can be output by appending the string '_xy', '_xz', or '_yz' to the respective quantities. Time averaged output is created by appending the string '_av' (for cross section data, this string must be appended after the cross section string). Cross section data can also be (additionally) averaged along the direction normal to the respective section (see below). Assignments of quantities can be given in arbitrary order: Example: data_output = 'u', 'pt_xz_av', 'w_xy', 'u_av' . This example will create the following output: instantaneous 3d volume data of u-velocity component (by default on file DATA_3D_NETCDF?), temporally averaged 3d volume data of u-velocity component (by default on file DATA_3D_AV_NETCDF?), instantaneous horizontal cross section data of w-velocity component (by default on file DATA_2D_XY_NETCDF?), and temporally averaged vertical cross section data of potential temperature (by default on file DATA_2D_XZ_AV_NETCDF?). The user is allowed to extend the above list of quantities by defining his own output quantities (see the user-parameter data_output_user). The time interval of the output times is determined via dt_data_output?. This is valid for all types of output quantities by default. Individual time intervals for instantaneous(!) 3d and section data can be declared using dt_do3d?, dt_do2d_xy?, dt_do2d_xz?, and dt_do2d_yz?. Also, an individual time interval for output of temporally averaged data can be assigned using parameter [dt_data_output_av]. This applies to both 3d volume and cross section data. The length of the averaging interval is controlled via parameter averaging_interval. The parameter skip_time_data_output? can be used to shift data output activities for a given time interval. Individual intervals can be set using skip_time_do3d?, skip_time_do2d_xy?, skip_time_do2d_xz?, skip_time_do2d_yz?, and skip_time_data_output_av?. With the parameter nz_do3d? the output can be limited in the vertical direction up to a certain grid point. Cross sections extend through the total model domain. In the two horizontal directions all grid points with 0 <= i <= nx?+1 and 0 <= j <= ny?+1 are output so that in case of cyclic boundary conditions the complete total domain is represented. The location(s) of the cross sections can be defined with parameters section_xy?, section_xz?, and section_yz?. Assigning section_.. = -1 causes the output data to be averaged along the direction normal to the respective section. Output of user defined quantities: Beside the standard quantities from the above list, the user can output any other quantities. These have to be defined and calculated within the user-defined code (see LINK?). They can be selected for output with the user-parameter data_output_user for which the same rules apply as for data_output. Output of the user defined quantities (time interval, averaging, selection of cross sections, etc.) is controlled with the parameters listed above and data are written to the same file(s) as the standard quantities. Output on parallel machines:
dt_data_output_av	R	0.0
dummy	dummy	dummy	dummy
dummy	dummy	dummy	dummy
dummy	dummy	dummy	dummy
dummy	dummy	dummy	dummy
dummy	dummy	dummy	dummy
dummy	dummy	dummy	dummy
dummy	dummy	dummy	dummy
dummy	dummy	dummy	dummy
dummy	dummy	dummy	dummy
dummy	dummy	dummy	dummy
dummy	dummy	dummy	dummy

Run steering:

Parameter Name	FORTRAN Type	Default Value	Explanation
call_psolver_at_all_substeps	L	.T.	Switch to steer the call of the pressure solver. In order to speed-up performance, the Poisson equation for perturbation pressure (see psolver?) can be called only at the last substep of multistep Runge-Kutta timestep schemes (see 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, call_psolver_at_all_timesteps = .T. should be used.
cfl_factor	R	0.1, 0.8 or 0.9 (see right)	Time step limiting factor. In the model, the maximum allowed time step according to CFL and diffusion-criterion dt_max is reduced by dt? = dt_max * cfl_factor in order to avoid stability problems which may arise in the vicinity of the maximum allowed timestep. The condition 0.0 < cfl_factor < 1.0 applies. The default value of cfl_factor depends on the timestep_scheme? used: For the third order Runge-Kutta scheme it is cfl_factor = 0.9. In case of the leapfrog scheme a quite restrictive value of cfl_factor = 0.1 is used because for larger values the velocity divergence significantly effects the accuracy of the model results. Possibly larger values may be used with the leapfrog scheme but these are to be determined by appropriate test runs. The default value for the Euler scheme is cfl_factor = 0.8 .
create_disturbances	L	.T.	Switch to impose random perturbations to the horizontal velocity field. With create_disturbances = .T., random perturbations can be imposed to the horizontal velocity field at certain times e.g. in order to trigger off the onset of convection, etc.. The temporal interval between these times can be steered with dt_disturb?, the vertical range of the perturbations with disturbance_level_b? and disturbance_level_t?, and the perturbation amplitude with disturbance_amplitude?. In case of non-cyclic lateral boundary conditions (see bc_lr? and bc_ns?), the horizontal range of the perturbations is determined by inflow_disturbance_begin? and inflow_disturbance_end?. A perturbation is added to each grid point with its individual value determined by multiplying the disturbance amplitude with a uniformly distributed random number. After this, the arrays of u and v are smoothed by applying a Shuman-filter twice and made divergence-free by applying the pressure solver. The random number generator to be used can be chosen with random_generator?. As soon as the desired flow features have developed (e.g. convection has started), further imposing of perturbations is not necessary and can be omitted (this does not hold for non-cyclic lateral boundaries!). This can be steered by assigning an upper limit value for the perturbation energy (the perturbation energy is defined by the deviation of the velocity from the mean flow) using the parameter disturbance_energy_limit?. As soon as the perturbation energy has exceeded this energy limit, no more random perturbations are assigned. Timesteps where a random perturbation has been imposed are marked in the local file RUN_CONTROL? by the character "D" appended to the values of the maximum horizontal velocities.
cycle_mg	C*1	'w'	Type of cycle to be used with the multi-grid method. This parameter determines which type of cycle is applied in the multi-grid method used for solving the Poisson equation for perturbation pressure (see psolver?). 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.
dummy	dummy	dummy	dummy
dummy	dummy	dummy	dummy
dummy	dummy	dummy	dummy
dummy	dummy	dummy	dummy
dummy	dummy	dummy	dummy }}} dummy dummy dummy dummy dummy dummy dummy dummy