| 39 | | 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 dt_dopr]. In any case '''averaging_interval_pr <= dt_dopr''' must hold.\\\\ |
| 40 | | If an interval is defined, then by default the average is calculated from the data values of all time |
| | 39 | If this parameter is given a non-zero value, temporally averaged vertical profile data are output. By default, profile data are not subject to temporal averaging. The interval length is limited by the parameter [#dt_dopr dt_dopr]. In any case '''averaging_interval_pr <= dt_dopr''' must hold.\\\\ |
| | 40 | If an interval is defined, then by default the average is calculated from the data values of all time steps lying within this interval. The number of time levels entering into the average can be reduced with the parameter [#dt_averaging_input_pr dt_averaging_input_pr].\\\\ |
| 67 | | In this case |
| 68 | | Whether the coordinate systems are actually drawn, depends on whether data of the appropriate profiles were output during the run (profiles to be output have to be selected with the parameter [#data_output_pr data_output_pr]). For example |
| | 67 | In this case, the plot consists of two coordinate systems (panels) with the first panel containing the profiles of the horizontal velocity components ('' 'u' '' and '' 'v' '') of all output times (see [#dt_dopr dt_dopr]) and the second one containing the profiles of the potential temperature ('' 'pt' '').\\\\ |
| | 68 | Whether the coordinate systems are actually drawn, depends on whether data of the appropriate profiles were output during the run (profiles to be output have to be selected with the parameter [#data_output_pr data_output_pr]). For example, if '''data_output_pr''' = '' 'u', 'v' '' was assigned, then the plot only consists of one panel, since no profiles of the potential temperature were output. On the other hand, if profiles were assigned to '''data_output_pr''' whose names do not appear in '''cross_profiles''', this profiles will be plotted separately behind the profiles defined in [#cross_profiles cross_profiles].\\\\ |
| 84 | | By default, cross section data are output (depending on the selected cross sections(s), see below) to local files [[../iofiles#DATA_2D_XY_NETCDF|DATA_2D_XY_NETCDF]], [[../iofiles#DATA_2D_XZ_NETCDF|DATA_2D_XZ_NETCDF]] and/or [[../iofiles#DATA_2D_YZ_NETCDF|DATA_2D_YZ_NETCDF]]. Volume data are output to file [[../iofiles#DATA_3D_NETCDF|DATA_3D_NETCDF]]. If the user has switched on the output of temporally averaged data, these are written seperately to local files [[../iofiles#DATA_2D_XY_AV_NETCDF|DATA_2D_XY_AV_NETCDF]], [[../iofiles#DATA_2D_XZ_AV_NETCDF|DATA_2D_XZ_AV_NETCDF]], [[../iofiles#DATA_2D_YZ_AV_NETCDF|DATA_2D_YZ_AV_NETCDF]], and [[../iofiles#DATA_3D_AV_NETCDF|DATA_3D_AV_NETCDF]], respectively.\\\\ |
| 85 | | 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 netCDF data output] about processing the PALM netCDF data.\\\\ |
| | 84 | By default, cross section data are output (depending on the selected cross sections(s), see below) to local files [[../iofiles#DATA_2D_XY_NETCDF|DATA_2D_XY_NETCDF]], [[../iofiles#DATA_2D_XZ_NETCDF|DATA_2D_XZ_NETCDF]] and/or [[../iofiles#DATA_2D_YZ_NETCDF|DATA_2D_YZ_NETCDF]]. Volume data are output to file [[../iofiles#DATA_3D_NETCDF|DATA_3D_NETCDF]]. If the user has switched on the output of temporally averaged data, these are written separately to local files [[../iofiles#DATA_2D_XY_AV_NETCDF|DATA_2D_XY_AV_NETCDF]], [[../iofiles#DATA_2D_XZ_AV_NETCDF|DATA_2D_XZ_AV_NETCDF]], [[../iofiles#DATA_2D_YZ_AV_NETCDF|DATA_2D_YZ_AV_NETCDF]], and [[../iofiles#DATA_3D_AV_NETCDF|DATA_3D_AV_NETCDF]], respectively.\\\\ |
| | 85 | The filenames already suggest that all files are in netCDF format. Information 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 netCDF data output] about processing the PALM netCDF data.\\\\ |
| 166 | | '''Output of user defined quantities:'''\\\\ |
| 167 | | 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 [[../userint/output|User-defined output quantities]]). They can be selected for output with the user-parameter [[../userpar#data_output_user|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.\\\\ |
| | 166 | '''Output of user-defined quantities:'''\\\\ |
| | 167 | Besides 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 [[../userint/output|User-defined output quantities]]). They can be selected for output with the user-parameter [[../userpar#data_output_user|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 by the parameters listed above and data are written to the same file(s) as the standard quantities.\\\\ |
| 169 | | By default, with parallel runs, processors output only data of their respective subdomains into seperate local files (file names are constructed by appending the four digit processor ID, e.g. <filename>_0000, <filename>_0001, etc.). After PALM has finished, the contents of these individual files are sampled into one final file using the program {{{combine_plot_fields.x}}} (automatically activated by '''mrun''').\\\\ |
| 170 | | Alternatively, PALM is able to collect all grid points of a cross section on PE0 before output is done. In this case only one output file ([[../iofiles#DATA_2D_XY_NETCDF|DATA_2D_XY_NETCDF]], etc.) is created and {{{combine_plot_fields.x}}} does not have to be called. In case of very large numbers of horizontal gridpoints, sufficient memory is required on PE0. This method can be used by assigning [#data_output_2d_on_each_pe data_output_2d_on_each_pe] = ''.F.''.\\\\ |
| 171 | | 3d volume data output is always handled seperately by each processor so that {{{combine_plot_fields.x}}} has to be called anyway after PALM has been finished. |
| | 169 | By default, with parallel runs, processors output only data of their respective subdomains into separate local files (file names are constructed by appending the four digit processor ID, e.g. <filename>_0000, <filename>_0001, etc.). After PALM has finished, the contents of these individual files are sampled into one final file using the program {{{combine_plot_fields.x}}} (automatically activated by '''mrun''').\\\\ |
| | 170 | Alternatively, PALM is able to collect all grid points of a cross section on PE0 before an output is done. In this case, only one output file ([[../iofiles#DATA_2D_XY_NETCDF|DATA_2D_XY_NETCDF]], etc.) is created and {{{combine_plot_fields.x}}} does not have to be called. In case of very large numbers of horizontal grid points, sufficient memory is required on PE0. This method can be used by assigning [#data_output_2d_on_each_pe data_output_2d_on_each_pe] = ''.F.''.\\\\ |
| | 171 | 3d volume data output is always handled separately by each processor so that {{{combine_plot_fields.x}}} has to be called anyway after PALM has been finished. |
| 185 | | Unlimited different masks can be defined (see [../maskedoutput Masked data output]). For each mask different instantaneous or temporally averaged quantities (up to 100) can be output. The masks are steered with the parameters [#mask_x mask_x], [#mask_y mask_y], [#mask_z mask_z], [#mask_x_loop mask_x_loop], [#mask_y_loop mask_y_loop] and [#mask_z_loop mask_z_loop]. It is possible to scale the masked data with a specified length for each direction (see [#mask_scale_x mask_scale_x], [#mask_scale_y mask_scale_y] and [#mask_scale_z mask_scale_z]).\\\\ |
| 186 | | By default, masked data are output to local files [[../iofiles#DATA_MASK_01_NETCDF|DATA_MASK_01_NETCDF]], [[../iofiles#DATA_MASK_02_NETCDF|DATA_MASK_02_NETCDF]], ... . If the user has switched on the output of temporally averaged data, these are written seperately to local files [[../iofiles#DATA_MASK_01_AV_NETCDF|DATA_MASK_01_AV_NETCDF]], [[../iofiles#DATA_MASK_02_AV_NETCDF|DATA_MASK_02_AV_NETCDF]], ... . The file's format is netCDF. Further details about processing netCDF data are given in [../netcdf netCDF data output].\\\\ |
| | 185 | Unlimited different masks can be defined (see [../maskedoutput Masked data output]). For each mask different instantaneous or temporally averaged quantities (up to 100) can be output. The masks are steered with the parameters [#mask_x mask_x], [#mask_y mask_y], [#mask_z mask_z], [#mask_x_loop mask_x_loop], [#mask_y_loop mask_y_loop], and [#mask_z_loop mask_z_loop]. It is possible to scale the masked data with a specified length for each direction (see [#mask_scale_x mask_scale_x], [#mask_scale_y mask_scale_y], and [#mask_scale_z mask_scale_z]).\\\\ |
| | 186 | By default, masked data are output to local files [[../iofiles#DATA_MASK_01_NETCDF|DATA_MASK_01_NETCDF]], [[../iofiles#DATA_MASK_02_NETCDF|DATA_MASK_02_NETCDF]], ... . If the user has switched on the output of temporally averaged data, these are written separately to local files [[../iofiles#DATA_MASK_01_AV_NETCDF|DATA_MASK_01_AV_NETCDF]], [[../iofiles#DATA_MASK_02_AV_NETCDF|DATA_MASK_02_AV_NETCDF]], ... . The file's format is netCDF. Further details about processing netCDF data are given in [../netcdf netCDF data output].\\\\ |
| 351 | | Alternatively, by assigning '''data_output_2d_on_each_pe''' = ''.F.'', the respective data is gathered on PE0 and output is done directly into one file, so {{{combine_plot_fields.x}}} does not have to be called. However, in case of very large numbers of horizontal grid |
| | 351 | Alternatively, by assigning '''data_output_2d_on_each_pe''' = ''.F.'', the respective data is gathered on PE0 and output is done directly into one file, so {{{combine_plot_fields.x}}} does not have to be called. However, in case of very large numbers of horizontal grid points, sufficient memory is required on PE0. |
| 393 | | By default, data from each timestep within the interval defined by [#averaging_interval averaging_interval] are used for calculating the temporal average. By choosing '''dt_averaging_input''' > ''dt'', the number of time levels entering the average can be minimized. This reduces the CPU-time of a run but may worsen the quality of the average's statistics.\\\\ |
| 394 | | With variable time step (see [#dt dt]), the number of time levels entering the average can vary from one averaging interval to the next (for a more detailed explanation see [#averaging_interval averaging_interval]). It is approximately given by the quotient of '''averaging_interval''' / MAX(''' dt_averaging_input''', '''dt''') (which gives a more or less exact value, if a fixed time |
| | 393 | By default, data from each time step within the interval defined by [#averaging_interval averaging_interval] are used for calculating the temporal average. By choosing '''dt_averaging_input''' > ''dt'', the number of time levels entering the average can be minimized. This reduces the CPU time of a run but may worsen the quality of the average's statistics.\\\\ |
| | 394 | With variable time step (see [#dt dt]), the number of time levels entering the average can vary from one averaging interval to the next (for a more detailed explanation see [#averaging_interval averaging_interval]). It is approximately given by the quotient of '''averaging_interval''' / MAX(''' dt_averaging_input''', '''dt''') (which gives a more or less exact value, if a fixed time step is used and if this is an integral divisor of '''dt_averaging_input''').\\\\ |
| 428 | | If data output is switched on (see [#data_output data_output], [#data_output_pr data_output_pr], [[../sppar#data_output_sp|data_output_sp]], and [#section_xy section_xy]), this parameter can be used to assign the temporal interval at which these data shall be output. Output can be skipped at the beginning of a simulation using parameter [#skip_time_data_output skip_time_data_output], which has zero value by default. Reference time is the beginning of the simulation, i.e. output takes place at times t = '''skip_time_data_output''' + '''dt_data_output''', '''skip_time_data_output''' + 2*'''dt_data_output''', '''skip_time_data_output''' + 3*'''dt_data_output''', etc. Since output is only done at the discrete time levels given by the timestep used, the actual output times can slightly deviate from these theoretical values.\\\\ |
| | 427 | If data output is switched on (see [#data_output data_output], [#data_output_pr data_output_pr], [[../sppar#data_output_sp|data_output_sp]], and [#section_xy section_xy]), this parameter can be used to assign the temporal interval at which these data shall be output. Output can be skipped at the beginning of a simulation using parameter [#skip_time_data_output skip_time_data_output], which has zero value by default. The reference time is the beginning of the simulation, i.e. output takes place at times t = '''skip_time_data_output''' + '''dt_data_output''', '''skip_time_data_output''' + 2*'''dt_data_output''', '''skip_time_data_output''' + 3*'''dt_data_output''', etc. Since output is only done at the discrete time levels given by the time step used, the actual output times can slightly deviate from these theoretical values.\\\\ |
| 443 | | If data output of time averaged 2d and 3d data is switched on (see [#data_output data_output] and [#section_xy section_xy]), this parameter can be used to assign the temporal interval at which they shall be output. Output can be skipped at the beginning of a simulation using parameter [#skip_time_data_output_av skip_time_data_output_av], which has zero value by default. Reference time is the beginning of the simulation, i.e. output takes place at times t = '''skip_time_data_output_av''' + '''dt_data_output_av''', '''skip_time_data_output_av''' + 2*'''dt_data_output_av''', '''skip_time_data_output_av''' + 3*'''dt_data_output_av''', etc. Since output is only done at the discrete time levels given by the timestep used, the actual output times can slightly deviate from these theoretical values.\\\\ |
| | 442 | If data output of time averaged 2d and 3d data is switched on (see [#data_output data_output] and [#section_xy section_xy]), this parameter can be used to assign the temporal interval at which they shall be output. Output can be skipped at the beginning of a simulation using parameter [#skip_time_data_output_av skip_time_data_output_av], which has zero value by default. The reference time is the beginning of the simulation, i.e. output takes place at times t = '''skip_time_data_output_av''' + '''dt_data_output_av''', '''skip_time_data_output_av''' + 2*'''dt_data_output_av''', '''skip_time_data_output_av''' + 3*'''dt_data_output_av''', etc. Since output is only done at the discrete time levels given by the time step used, the actual output times can slightly deviate from these theoretical values.\\\\ |
| 463 | | Output can be skipped at the beginning of a simulation using parameter [#skip_time_domask skip_time_domask], which has zero value by default. Reference time is the beginning of the simulation, i.e. output takes place at times t = '''skip_time_domask''' + '''dt_domask''', '''skip_time_domask''' + 2*'''dt_domask''', '''skip_time_domask''' + 3*'''dt_domask''', etc. Since output is only done at the discrete time levels given by the timestep used, the actual output times can slightly deviate from these theoretical values. |
| | 462 | Output can be skipped at the beginning of a simulation using parameter [#skip_time_domask skip_time_domask], which has zero value by default. The reference time is the beginning of the simulation, i.e. output takes place at times t = '''skip_time_domask''' + '''dt_domask''', '''skip_time_domask''' + 2*'''dt_domask''', '''skip_time_domask''' + 3*'''dt_domask''', etc. Since output is only done at the discrete time levels given by the time step used, the actual output times can slightly deviate from these theoretical values. |
| 477 | | If output of horizontally averaged vertical profiles is switched on (see [#data_output_pr data_output_pr]), this parameter can be used to assign the temporal interval at which profile data shall be output. Output can be skipped at the beginning of a simulation using parameter [#skip_time_dopr skip_time_dopr], which has zero value by default. Reference time is the beginning of the simulation, thus t = 0, i.e. output takes place at times t = '''skip_time_dopr''' + '''dt_dopr''', '''skip_time_dopr''' + 2*'''dt_dopr''', '''skip_time_dopr''' + 3*'''dt_dopr''', etc. Since profiles can not be calculated for times lying within a time step interval, the output times can deviate from these theoretical values. If a time step ranges from t = 1799.8 to t = 1800.2, then in the example above the output would take place at t = 1800.2. In general, the output always lie between t = 1800.0 and t = 1800.0 + [#dt dt]. If the model uses a variable time step, these deviations from the theoretical output times will of course be different for each output time.\\\\ |
| | 476 | If output of horizontally averaged vertical profiles is switched on (see [#data_output_pr data_output_pr]), this parameter can be used to assign the temporal interval at which profile data shall be output. Output can be skipped at the beginning of a simulation using parameter [#skip_time_dopr skip_time_dopr], which has zero value by default. The reference time is the beginning of the simulation, thus t = 0, i.e. output takes place at times t = '''skip_time_dopr''' + '''dt_dopr''', '''skip_time_dopr''' + 2*'''dt_dopr''', '''skip_time_dopr''' + 3*'''dt_dopr''', etc. Since profiles can not be calculated for times lying within a time step interval, the output times can deviate from these theoretical values. If a time step ranges from t = 1799.8 to t = 1800.2, then in the example above the output would take place at t = 1800.2. In general, the output always lie between t = 1800.0 and t = 1800.0 + [#dt dt]. If the model uses a variable time step, these deviations from the theoretical output times will, of course, be different for each output time.\\\\ |
| 493 | | This parameter can be used to assign the temporal interval at which profile data shall be output. Reference time is the beginning of the simulation, thus t = 0. For example if '''dt_dopr_listing''' = ''1800.0'', then output takes place at t = 1800.0, 3600.0, 5400.0, etc. Since profiles can not be calculated for times lying within a time step interval, the output times can deviate from these theoretical values. If a time step ranges from t = 1799.8 to t = 1800.2, then in the example above the output would take place at t = 1800.2. In general, the output always lie between t = 1800.0 and t = 1800.0 + [#dt dt] (numbers are related to the example above). If the model uses a variable time step, these deviations from the theoretical output times will of course be different for each output time.\\\\ |
| | 492 | This parameter can be used to assign the temporal interval at which profile data shall be output. The reference time is the beginning of the simulation, thus t = 0. For example if '''dt_dopr_listing''' = ''1800.0'', then output takes place at t = 1800.0, 3600.0, 5400.0, etc. Since profiles can not be calculated for times lying within a time step interval, the output times can deviate from these theoretical values. If a time step ranges from t = 1799.8 to t = 1800.2, then in the example above the output would take place at t = 1800.2. In general, the output always lies between t = 1800.0 and t = 1800.0 + [#dt dt] (numbers are related to the example above). If the model uses a variable time step, these deviations from the theoretical output times will, of course, be different for each output time.\\\\ |
| 517 | | This parameter can be used to assign the temporal interval at which data points shall be output. Reference time is the beginning of the simulation, i.e. output takes place at times t = '''dt_dots''', 2*'''dt_dots''', 3*'''dt_dots''', etc. The actual output times can deviate from these theoretical values (see [#dt_dopr dt_dopr]). Is '''dt_dots''' < [#dt dt], then data of the time series are written after each time step (if this is requested, it should be '''dt_dots''' = 0).\\\\ |
| | 516 | This parameter can be used to assign the temporal interval at which data points shall be output. The reference time is the beginning of the simulation, i.e. output takes place at times t = '''dt_dots''', 2*'''dt_dots''', 3*'''dt_dots''', etc. The actual output times can deviate from these theoretical values (see [#dt_dopr dt_dopr]). Is '''dt_dots''' < [#dt dt], then data of the time series are written after each time step (if this is requested, it should be '''dt_dots''' = 0).\\\\ |
| 598 | | If output of horizontal cross sections is switched on (see [#data_output data_output] and [#section_xy section_xy]), this parameter can be used to assign the temporal interval at which cross section data shall be output. Output can be skipped at the beginning of a simulation using parameter [#skip_time_do2d_xy skip_time_do2d_xy], which has zero value by default. Reference time is the beginning of the simulation, i.e. output takes place at times t = '''skip_time_do2d_xy''' + '''dt_do2d_xy''', '''skip_time_do2d_xy''' + 2*'''dt_do2d_xy''', '''skip_time_do2d_xy''' + 3*'''dt_do2d_xy''', etc. The actual output times can deviate from these theoretical values (see [#dt_dopr dt_dopr]).\\\\ |
| 599 | | Parameter [#do2d_at_begin do2d_at_begin] has to be used, if an additional output is wanted at the start of a run (thus at the time t = 0 or at the respective starting times of restart runs). |
| | 597 | If output of horizontal cross sections is switched on (see [#data_output data_output] and [#section_xy section_xy]), this parameter can be used to assign the temporal interval at which cross section data shall be output. Output can be skipped at the beginning of a simulation using parameter [#skip_time_do2d_xy skip_time_do2d_xy], which has zero value by default. The reference time is the beginning of the simulation, i.e. output takes place at times t = '''skip_time_do2d_xy''' + '''dt_do2d_xy''', '''skip_time_do2d_xy''' + 2*'''dt_do2d_xy''', '''skip_time_do2d_xy''' + 3*'''dt_do2d_xy''', etc. The actual output times can deviate from these theoretical values (see [#dt_dopr dt_dopr]).\\\\ |
| | 598 | Parameter [#do2d_at_begin do2d_at_begin] has to be used if an additional output is wanted at the start of a run (thus at the time t = 0 or at the respective starting times of restart runs). |
| 613 | | If output of horizontal cross sections is switched on (see [#data_output data_output] and [#section_xz section_xz]), this parameter can be used to assign the temporal interval at which cross section data shall be output. Output can be skipped at the beginning of a simulation using parameter [#skip_time_do2d_xz skip_time_do2d_xz], which has zero value by default. Reference time is the beginning of the simulation, i.e. output takes place at times t = '''skip_time_do2d_xz''' + '''dt_do2d_xz''', '''skip_time_do2d_xz''' + 2*'''dt_do2d_xz''', '''skip_time_do2d_xz''' + 3*'''dt_do2d_xz''', etc. The actual output times can deviate from these theoretical values (see [#dt_dopr dt_dopr]).\\\\ |
| 614 | | Parameter [#do2d_at_begin do2d_at_begin] has to be used, if an additional output is wanted at the start of a run (thus at the time t = 0 or at the respective starting times of restart runs). |
| | 612 | If output of horizontal cross sections is switched on (see [#data_output data_output] and [#section_xz section_xz]), this parameter can be used to assign the temporal interval at which cross section data shall be output. Output can be skipped at the beginning of a simulation using parameter [#skip_time_do2d_xz skip_time_do2d_xz], which has zero value by default. The reference time is the beginning of the simulation, i.e. output takes place at times t = '''skip_time_do2d_xz''' + '''dt_do2d_xz''', '''skip_time_do2d_xz''' + 2*'''dt_do2d_xz''', '''skip_time_do2d_xz''' + 3*'''dt_do2d_xz''', etc. The actual output times can deviate from these theoretical values (see [#dt_dopr dt_dopr]).\\\\ |
| | 613 | Parameter [#do2d_at_begin do2d_at_begin] has to be used if an additional output is wanted at the start of a run (thus at the time t = 0 or at the respective starting times of restart runs). |
| 628 | | If output of horizontal cross sections is switched on (see [#data_output data_output] and [#section_yz section_yz]), this parameter can be used to assign the temporal interval at which cross section data shall be output. Output can be skipped at the beginning of a simulation using parameter [#skip_time_do2d_yz skip_time_do2d_yz], which has zero value by default. Reference time is the beginning of the simulation, i.e. output takes place at times t = '''skip_time_do2d_yz''' + '''dt_do2d_yz''', '''skip_time_do2d_yz''' + 2*'''dt_do2d_yz''', '''skip_time_do2d_yz''' + 3*'''dt_do2d_yz''', etc. The actual output times can deviate from these theoretical values (see [#dt_dopr dt_dopr]).\\\\ |
| 629 | | Parameter [#do2d_at_begin do2d_at_begin] has to be used, if an additional output is wanted at the start of a run (thus at the time t = 0 or at the respective starting times of restart runs). |
| | 627 | If output of horizontal cross sections is switched on (see [#data_output data_output] and [#section_yz section_yz]), this parameter can be used to assign the temporal interval at which cross section data shall be output. Output can be skipped at the beginning of a simulation using parameter [#skip_time_do2d_yz skip_time_do2d_yz], which has zero value by default. The reference time is the beginning of the simulation, i.e. output takes place at times t = '''skip_time_do2d_yz''' + '''dt_do2d_yz''', '''skip_time_do2d_yz''' + 2*'''dt_do2d_yz''', '''skip_time_do2d_yz''' + 3*'''dt_do2d_yz''', etc. The actual output times can deviate from these theoretical values (see [#dt_dopr dt_dopr]).\\\\ |
| | 628 | Parameter [#do2d_at_begin do2d_at_begin] has to be used if an additional output is wanted at the start of a run (thus at the time t = 0 or at the respective starting times of restart runs). |
| 643 | | If output of 3d-volume data is switched on (see [#data_output data_output]), this parameter can be used to assign the temporal interval at which 3d-data shall be output. Output can be skipped at the beginning of a simulation using parameter [#skip_time_do3d skip_time_do3d], which has zero value by default. Reference time is the beginning of the simulation, i.e. output takes place at times t = '''skip_time_do3d''' + '''dt_do3d''', '''skip_time_do3d''' + 2*'''dt_do3d''', '''skip_time_do3d''' + 3*'''dt_do3d''', etc. The actual output times can deviate from these theoretical values (see [#dt_dopr dt_dopr]).\\\\ |
| 644 | | Parameter [#do3d_at_begin do3d_at_begin] has to be used, if an additional output is wanted at the start of a run (thus at the time t = 0 or at the respective starting times of restart runs). |
| | 642 | If output of 3d-volume data is switched on (see [#data_output data_output]), this parameter can be used to assign the temporal interval at which 3d-data shall be output. Output can be skipped at the beginning of a simulation using parameter [#skip_time_do3d skip_time_do3d], which has zero value by default. The reference time is the beginning of the simulation, i.e. output takes place at times t = '''skip_time_do3d''' + '''dt_do3d''', '''skip_time_do3d''' + 2*'''dt_do3d''', '''skip_time_do3d''' + 3*'''dt_do3d''', etc. The actual output times can deviate from these theoretical values (see [#dt_dopr dt_dopr]).\\\\ |
| | 643 | Parameter [#do3d_at_begin do3d_at_begin] has to be used if an additional output is wanted at the start of a run (thus at the time t = 0 or at the respective starting times of restart runs). |
| 658 | | Run control information is output to the local ASCII-file [[../iofiles#RUN_CONTROL|RUN_CONTROL]] At each output time, one line with information about the size of the time step, maximum speeds, total kinetic energy etc. is written to this file. Reference time is the beginning of the simulation, i.e. output takes place at times t = '''dt_run_control''', 2*'''dt_run_control''', 3*'''dt_run_control''', etc., and always at the beginning of a model run (thus at the time t = 0 or at the respective starting times of restart runs). The actual output times can deviate from these theoretical values (see [#dt_dopr dt_dopr]).\\\\ |
| | 657 | Run control information is output to the local ASCII-file [[../iofiles#RUN_CONTROL|RUN_CONTROL]] At each output time, one line with information about the size of the time step, maximum speeds, total kinetic energy etc. is written to this file. The reference time is the beginning of the simulation, i.e. output takes place at times t = '''dt_run_control''', 2*'''dt_run_control''', 3*'''dt_run_control''', etc., and always at the beginning of a model run (thus at the time t = 0 or at the respective starting times of restart runs). The actual output times can deviate from these theoretical values (see [#dt_dopr dt_dopr]).\\\\ |
| 1183 | | If the environment variable '''write_binary''' is set ''.T.'' (see [../runs Initialization and restart runs]), PALM checks the remaining CPU time of the job after each timestep. Time integration must not consume the CPU time completely, since several actions still have to be carried out after time integration has finished (e.g. writing of binary data for the restart run, carrying out output commands, copying of local files to their permanent destinations, etc.) which also takes some time. The maximum possible time needed for these activities plus a reserve is to be given with the parameter '''termination_time_needed'''. Among other things, it depends on the number of grid points used. If its value is selected too small, then the respective job will be prematurely aborted by the queuing system, which may result in a data loss and will possibly interrupt the job chain.\\\\ |
| | 1182 | If the environment variable '''write_binary''' is set ''.T.'' (see [../runs Initialization and restart runs]), PALM checks the remaining CPU time of the job after each time step. Time integration must not consume the CPU time completely since several actions still have to be carried out after time integration has finished (e.g. writing of binary data for the restart run, carrying out output commands, copying of local files to their permanent destinations, etc.) which also takes some time. The maximum possible time needed for these activities plus a reserve is to be given with the parameter '''termination_time_needed'''. Among other things, it depends on the number of grid points used. If its value is selected too small, then the respective job will be prematurely aborted by the queuing system, which may result in a data loss and will possibly interrupt the job chain.\\\\ |
| 1403 | | Set an MPI-barrier at the beginning of each cpu-time measurement.\\\\ |
| 1404 | | Measurement of code performance is carried out by default for most parts of the PALM code (see routine [source:palm/trunk/SOURCE/cpulog.f90 cpu_log] for more information). In case that MPI-calls are part of code segments to be measured, the measurement might be seriously affected by idle times (if MPI-calls on some of the processors have to wait because of other, previous MPI-calls on other processors which are not yet finished). In order to avoid measuring these idle times, you can switch on an MPI-barrier at the beginning of each measurement by setting '''cpu_log_barrierwait''' = ''.TRUE.''. You should keep in mind that these additional barriers may generally degrade the code performance, so they should be switched on only for getting precise cpu-time measurements (and not for production runs). |
| | 1402 | Set an MPI-barrier at the beginning of each CPU time measurement.\\\\ |
| | 1403 | Measurement of code performance is carried out by default for most parts of the PALM code (see routine [source:palm/trunk/SOURCE/cpulog.f90 cpu_log] for more information). In case that MPI-calls are part of code segments to be measured, the measurement might be seriously affected by idle times (if MPI-calls on some of the processors have to wait because of other, previous MPI-calls on other processors which are not yet finished). In order to avoid measuring these idle times, you can switch on an MPI-barrier at the beginning of each measurement by setting '''cpu_log_barrierwait''' = ''.TRUE.''. You should keep in mind that these additional barriers may generally degrade the code performance, so they should be switched on only for getting precise CPU time measurements (and not for production runs). |
| 1418 | | For parallel runs, the total number of processors to be used is given by the '''mrun'''-option -X. By default, PALM tries to generate a 2d processor net (domain decomposition along x and y), which is more or less square-shaped. If, for example, 16 processors are assigned (-X 16), a 4 * 4 processor net is generated ('''npex''' = 4, '''npey''' = 4). This choice is optimal for square total domains ([../inipar#nx nx] = [../inipar#ny ny]), because it minimizes the number of ghost points at the lateral boundarys of the subdomains. If nx and ny differ extremely, the processor net should be manually adjusted using adequate values for '''npex''' and '''npey'''.\\\\ |
| | 1417 | For parallel runs, the total number of processors to be used is given by the '''mrun'''-option -X. By default, PALM tries to generate a 2d processor net (domain decomposition along x and y), which is more or less square-shaped. If, for example, 16 processors are assigned (-X 16), a 4 * 4 processor net is generated ('''npex''' = 4, '''npey''' = 4). This choice is optimal for square total domains ([../inipar#nx nx] = [../inipar#ny ny]) because it minimizes the number of ghost points at the lateral boundarys of the subdomains. If nx and ny differ extremely, the processor net should be manually adjusted using adequate values for '''npex''' and '''npey'''.\\\\ |
