The
model works
with a set of files, which are all located in the temporary working
directory and which are either expected at the beginning of the run
(the so-called input files) or which are
produced during the run and/or at the end of the simulation (output
files).
The following table lists all
default files
addressed by the model. They are arranged according to the
associated FORTRAN unit (unit number). The
unit 90 is used for different files, which are opened only briefly
and uniquely in the model and closed directly afterwards.
Unit numbers 101 - 109, 111 - 113, and 116 refer to data files
which have NetCDF format.
These are not opened by a FORTRAN-OPEN-statement but by a corresponding
NetCDF call (NF90_CREATE or NF90_OPEN). These files are only created on
machines where a NetCDF library is available.
The file names described in the list correspond to the names indicated in the respective OPEN instruction, i.e. the files are expected and saved under these names in the temporary working directory of the model. By default, file names are always written in capital letters. The third column indicates whether it is an input or output file (I and/or O). The NetCDF files can be both input and output files (I/O). If restart jobs shall append data to an existing NetCDF file (created by a previous job of the job chain), the respective file has to be given as an input file (see also chapter 4.5.1 which gives more details about the PALM-NetCDF-output).
On parallel computers many of the files are read and/or written by the central processing element 0 (PE0) only. These files have processor-independent content (and therefore they can be read or written by other PEs just as well). However, certain files have processor-dependent content. For the binary output of data for restart runs (local file BINOUT), for example, each PE outputs only the data of its subdomain. So each processing element writes into its own file with its own file name. These files lie in a subdirectory of the temporary working directory. Their names are build off from the underline ("_ ") and the four digit processor ID. The data written for restart runs would be e.g. on the files BINOUT/_0000 (PE0), BINOUT/_0001 (PE1), BINOUT/_0002 (PE2) etc. Such files, which have processor-dependent content on parallel computers, are marked in the following list by the fact, that to the file name a line (”/“) is attached. If appropriate output files are to be copied through mrun to permanent files, and/or files with processor-dependent content are supposed to be copied as input files into the temporary working directory of the model, you have to indicate a special file attribute in the appropriate file connection statement (see arpe, flpe in the mrun description). Then the permanent file name will be interpreted as a directory name, in which the input files are expected and/or to which output files are written. The file names in these directories are always named _0000, _0001, _0002 etc.
For internal use, the model may open a set of further files, which are not defined by the user but contain no usable information and therefore are not included in this list.
In case of coupled atmosphere-ocean runs (see chapter 3.8), both the atmosphere and the ocean executable use the same temporary working directory. However, each executable requires its own, unique set of files for I/O. In order to distinguish between atmosphere and ocean files, coupled atmosphere-ocean runs use the following filename convention. The atmosphere executable uses the set of normal filenames given in the table below. The ocean executable uses a set of modified filenames that have the string '_O' added to their normal name. The coupled ocean filenames are given in brackets in the table below where applicable. The string '_O' is simply appended to most filenames; exceptions are highlighted in bold face. (Note: uncoupled ocean runs use the normal set of filenames without '_O'.)
Unit |
Name |
I/O |
Format |
Description/contents |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
11 |
I |
ASCII/ |
Parameter for model steering. This file is needed by the model in each case. Its content and structure is described in detail in chapter 4.0. Chapter 4.4.1 shows a simple example. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
13 |
I |
Binary |
Binary data, which are read in by the model at the beginning of a restart run (see chapter 3.3). The appropriate file must have been written by the preceding job of the job chain (see BINOUT). This file contains the initial parameters (see chapter 4.1) of the job chain, arrays of the prognostic and diagnostic variables as well as those parameters and variables for plots of horizontally averaged vertical profiles (see data_output_pr), which have been determined by the job chain so far. Concerning runs on several processors it has to be noted that each processing element reads its own file and the file content is processor-dependent. The number of processors which can be used must not be changed during a job chain and/or if a job chain is continued. Knowledge of the file structure is usually not necessary, because the file is produced and also read again by the model, but it can be useful for error determination in case of read errors . Therefore the file structure is described in the following. The first record of this file contains a version number (ten character string) of the subroutine, which, which output the data that follows (write_var_list.f90). This number has to agree with the version number subroutine which is reading the file (read_var_list.f90) in case of a restart run. Otherwise the model run is aborted. Version numbers are changed whenever new code revisions require a change of the file format. Starting from the second record, all initial parameters follow (exception: initializing_actions), whereby each parameter fills two records. In the first record the name of the parameter is saved as a character string (30 characters long, short names are filled by trailing blanks, longer names are cut off at the end), in the second record the value (or the values) of the parameter follow. The sequence of parameters on the file may be arbitrary, however the first and second variable must be nz and statistic_regions. If a variable with unknown name is found the model run is aborted. At the end of the initial parameters a record with the string "*** end ***"follows (filled up with trailing blanks up to a length of 30 characters). Afterwards the fields of the prognostic and diagnostic variables follow. This part of the file also begins with a record consisting of a character string of length 10, which contains the version number of the subroutine that wrote the arrays that follow (write_3d_binary.f90). It must agree with the number of the reading subroutine (read_3d_binary.f90). The following record contains the number of processors which were used in the model run producing this file, the processor ID of the special processor, which creates the file, as well as the lower and upper array indices of the subdomain belonging to this processing element. If no complete agreement with the values of the current model run exists, then this is aborted. This examination must be made in particular on parallel computers, because the jobs of a job chain always have to use the same number of processors and the same virtual processor grid. After these tests the individual arrays as well as parameters and variables for plots of horizontally averaged vertical profiles follow. Like the initialization parameters, they consist of two records. In the first record, the name of the array or the variable (character string, consisting of 20 characters, filled with trailing blanks) is located, in the second one its values follow. The sequence of the individual variables may be arbitrary again. The parameters for the plot and the respective variables are only read in if for the run parameter use_prior_plot1d_parameters = .TRUE is selected, otherwise they will be skipped. At the end of the file there has to be a record with the character string "*** end ***"(filled up with trailing blanks up to a length of 20 characters). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
14 |
O |
Binary |
Binary data, which are written by the model at the end of the run and possibly needed by restart runs (see chapter 3.3) for the initialization. This output file is then read in as file BININ. It contains the initial parameters (see chapter 4.1) of the model run, arrays of the prognostic and diagnostic variables as well as those parameters determined so far during a job chain and variables for plots of horizontally averaged vertical profiles (see data_output_pr). With runs on several processors it has to be noted that each processing element writes its own file and the file content is processor-dependent. A specification of the file format can be found in the description of the file BININ. The file BINOUT is written by the model only if, with the help of the mrun-configuration file, the value true is assigned for the environment variable write_binary (see chapter 3.3). With large grid point numbers the file BINOUT (or the files residing in directory BINOUT/) will be very large and should be stored (if available) on the archive system of the remote computer. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
15 |
RUN_CONTROL (RUN_CONTROL_O) |
O | Ascii |
This file contains the so-called time step control output of the model. At certain temporal intervals, which are described by the run parameter dt_run_control, a line with the values of certain control parameters is written into this file. Additionally, such a control line is always written, whenever the time step of the model changes. All data and quantities always refer to the entire model domain. If the 1D-model is switched on for the initialization of the 3D-models, then control lines are likewise written into this file at certain temporal intervals (see dt_run_control_1d). By default, the file RUN_CONTROL only lists information about the selected model parameters at the beginning of the initial run. These informations are written at the beginnning of a run. They correspond to those of the file HEADER (however without data concerning the consumed CPU time, because these are only known at the end of a run). With the run parameter force_print_header it can be achieved that this information is also written at the beginning of the file RUN_CONTROL at restart runs. The individual columns of the 1D - time step control
output
have the following meaning (listed by the respective heading of the
appropriate
column in the file):
The individual columns of the 3D - time step control output
have the following meaning (listed by the respective heading of the
appropriate
column in the file):
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
16 |
LIST_PROFIL (LIST_PROFIL_O) |
O |
Ascii |
This file contains
horizontally
(and possibly temporally)
averaged vertical profiles of some model variables. The quantities
saved are set model-internally and can not be determined by the user.
At each output time (see dt_dopr_listing)
two tables are written to the file consecutively. The first contains
variables which are defined on the scalar / u-v-grid-levels, the
second table contains variables which are defined on the w-grid-levels.
If subdomains were defined with the initialization parameter statistic_regions for
additional statistic evaluation, then the tables
described above are written for each individual subdomain. The name of
the respective subdomain (see region)
appears in the header of the respective table. In each case the tables consist of a header, followed by the profiles arranged next to each other in columns. The header contains some basic information of the respective run (model version, run identifier consisting of basic file name and number of the job in the job chain, executing computer, date, time of the beginning of the run, name of the subdomain, output time, kind of averaging). On the u-v-level the following columns are written:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
17 | LIST_PROFIL_1D (LIST_PROFIL_1D_O) |
O | Ascii | This file contains
the vertical
profiles calculated by the
1D-model within initial runs. The quantities saved are set
model-internally and cannot be determined by the user. At the
respective output times (see dt_pr_1d)
a table with the following information is written to the file: The
table header contains some basic information of the respective run
(model version, run identifier consisting of basic file name and number
of the job in the
job chain (this number should always be 00, because the 1D-model is
only switched on at initial runs), executing computer, date,
time of the beginning of the run, output time). Afterwards the
following columns appear:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
18 | CPU_MEASURES (CPU_MEASURES_O) |
O | Ascii | Time measurements
are
accomplished through the subroutine cpu_log.f90. The file
CPU_MEASURES contains a header with some basic information of the
respective run
(model version, run identifier consisting of basic file name and
number of the job in the job chain, executing computer, date, time of
the beginning of the run) and afterwards two tables with data of CPU
times which have been consumed by certain model parts. The model parts
analyzed in the first table do not overlap and the CPU times needed for
them therefore approximately add up to the “total”
value given in the
first line of this table. In the second table (heading: special
measures) overlaps (in particular with the parts described in the first
table) are possible. For each model part it is indicated in the following columns how much CPU time was needed (absolutely and relative), and how often it was called. With runs on several processors the average values of all processors are indicated. In the case of parallel runs information for those processors with the largest and smallest CPU time follow as well as the standard deviation of all PEs from the average value. With good parallelization the CPU times on the individual processors should differ only little from each other and the standard deviation should be small. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
19 | HEADER (HEADER_O) |
O | Ascii |
Information about the selected model parameters (physical and numerical values) as well as general information about the run. This file contains the values of all important steering parameters (numerical procedures, computing grid and model dimensions, boundary conditions, physical dimension, turbulence quantities, actions during the simulation, 1D-model-parameters) as well as data concerning the selected plot and list outputs. The headlines of the file list the program version used, date and time of the beginning of the run, the name of the executing computer, the run identifier (corresponds to the selected base file name) and the number of the run (number of the restart run). With parallel runs the number of processors as well as the assigned virtual processor net also appear. After these headlines run time and time step information appear (point of starting time, related to t=0 of the initial run, end-time, time actually reached, CPU time, etc.). If a model run is incorrectly terminated (e.g. run time error or excess of the permitted CPU time), information over the time reached and the necessary CPU time is missing (to understand: the file HEADER is written twice by the model; once briefly after beginning of the simulation (naturally here the information over the time reached is missing etc.) and then briefly before the normal end of the simulation. The second, now complete output overwrites the first output.). At the end of the file, information about the values of user parameters (see chapter 3.7 and chapter 4.3) can be output by the user with the help of the subroutine user_header (located in the file user_interface.f90). If no user parameters were found, the string “*** no user-defined variables found” appears at the end of the file. If user parameters were indicated, the string “user-defined variables and actions” is printed, followed by informations about the user-defined subdomains for which profiles and time series are output. All further information to appear here, must be provided by the user (by appropriate WRITE statements in user_header). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
21 | PLOT2D_XY (PLOT2D_XY_O) |
O |
Binary |
This file contains data of the two-dimensional horizontal cross sections written by the model (see data_output) in a format readable by ISO2D (the first record contains the coordinate information dx, eta, hu, ho, then the individual arrays follow). The data are visualized with the help of ISO2D using NAMELIST - parameter sets, which are directly written by the model to the local files PLOT2D_XY_GLOBAL and PLOT2D_XY_LOCAL. With parallel runs and choice of data_output_2d_on_each_pe = .T. each processing element writes the data of its subdomain to a separate file with the name PLOT2D_XY_<processor-Id>, whereby <processor-Id> is a four digit number (e.g. PLOT2D_XY_0000). These files are not suitable for ISO2D, but after the end of the model run they can be combined to one file readable by ISO2D with the help of the program combine_plot_fields.x. This tool expects the files of the individual processing elements under the names described above and outputs the combined file under the name PLOT2D_XY. Usually it is called by an appropriate OUTPUT - command (OC:) in the MRUN-configuration file. The tool writes informative messages about the actions accomplished into the job protocol (e.g., even if no files were found). By the call of combine_plot_fields.x possibly existing files of the other cross sections (xz and/or yz) and three-dimensional arrays (see PLOT3D_DATA) are also combined. Further information about the output of plots of two-dimensional cross sections is found in the description of the run parameter data_output. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
22 |
PLOT2D_XZ (PLOT2D_XZ_O) |
O |
Binary |
This file contains the data of the xz cross sections written by the model. The description of the local file PLOT2D_XY applies to this file, respectively |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
23 |
PLOT2D_YZ (PLOT2D_YZ_O) |
O |
Binary |
This file contains the data of the xz cross sections written by the model. The description of the local file PLOT2D_XY applies to this file, respectively |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
27 |
PLOT2D_XY_LOCAL (PLOT2D_XY_LOCAL_O) |
O |
Ascii/ NAMELIST |
NAMELIST - parameter sets, with which the plot layout of the data in the local file PLOT2D_XY can be steered, if they are visualized with the plot program ISO2D. This file contains the so-called local parameter set (NAMELIST - group name: &LOCAL) required by ISO2D (one parameter set for each field present at the file PLOT2D_XY). After the model run these parameter sets can be edited by the user, if neccessary. Additionally ISO2D still needs another so-called global parameter set. This is saved by the model to the local file PLOT2D_XY_GLOBAL. Due to the fact that ISO2D expects global and local parameter sets on one and the same file, in fact the global parameter set first, the user has to append the contents of the file PLOT2D_XY_LOCAL to the file PLOT2D_XY_GLOBAL before the call of ISO2D (e.g. by an OUTPUT-command in the MRUN-configuration file: “PLOT2D_XY_LOCAL >> PLOT2D_XY_GLOBAL”). This relatively pedantic proceeding is due to the fact that the model can produce the file PLOT2D_XY_GLOBAL only at the end of the simulation (only then e.g. when the final value of the global ISO2D - parameter planz is known), while the local parameter sets are written continuously to the file PLOT2D_XY_LOCAL during the run. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
28 |
PLOT2D_XZ_LOCAL (PLOT2D_XZ_LOCAL_O) |
O |
Ascii/ NAMELIST |
NAMELIST - parameter sets, with which the plot layout of the data in the local file PLOT2D_XZ can be steered, if they are visualized with the plot program ISO2D. The description of the local file PLOT2D_XY_LOCAL applies to this file, respectively. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
29 |
PLOT2D_YZ_LOCAL (PLOT2D_YZ_LOCAL_O) |
O |
Ascii/ NAMELIST |
NAMELIST - parameter sets, with which the plot layout of the data in the local file PLOT2D_YZ can be steered, if they are visualized with the plot program ISO2D. The description of the local file PLOT2D_XY_LOCAL applies to this file, respectively. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
30 |
PLOT3D_DATA (PLOT3D_DATA_O) |
O |
Binary |
This file contains the data of the three-dimensional arrays (see data_output) written by the model in a format readable for the visualization software AVS. Beyond that AVS needs coordinate information, which are output into the local file PLOT3D_COOR, as well as the local files PLOT3D_FLD and PLOT3D_FLD_COOR, which describe the structure of the files PLOT3D_DATA and PLOT3D_COOR in the so-called AVS-FLD-format. Due to the fact that AVS expects these information in only one (so-called FLD -) file, the content of the file PLOT3D_FLD_COOR must be appended to the file PLOT3D_FLD by the user after the end of the model run (e.g. with an appropriate OUTPUT - command in the MRUN - configuration file: "cat PLOT3D_FLD_COOR >> PLOT3D_FLD"). With parallel runs each processing element writes the data of its subdomain to a separate file with the name PLOT3D_DATA_<Processor-Id>, where <Processor-Id> is a four digit number (e.g. PLOT3D_DATA_0000). These files are not suitable for AVS, but after the end of the model run they can be combined to one file readable for AVS with the help of the program combine_plot_fields.x. This tool expects the files of the individual processing elements under the names described above and outputs the combined file into a new file PLOT3D_DATA. Usually it is called by an appropriate OUTPUT - command in the MRUN-configuration file. The tool writes informative messages about the accomplished actions into the job protocol (e.g., even if no files were found). By the call of combine_plot_fields.x also possibly existing files with two-dimensional plot data (see e.g. PLOT2D_XY) are combined. With parallel runs the output of data of large volume is also possible in compressed form. For this purpose the initialization parameter do3d_compress = .TRUE. must be set and the desired output accuracy has to be indicated with the help of do3d_comp_prec. In favorable cases the file size can be reduced by a factor of up to 5. For the visualization of compressed data a special AVS module (read_compressed_field) and a further entry in the MRUN-configuration file are needed. More details can be found in chapter 4.5.6. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
31 |
PLOT3D_COOR | O |
Binary |
Coordinate information concerning the three-dimensional arrays (see PLOT3D_DATA) needed by the visualization software AVS. The file PLOT3D_COOR should be saved by the user into the same permanent directory as the file PLOT3D_DATA. For parallel runs PLOT3D_COOR is written by PE0 only. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
32 |
PLOT3D_FLD | O |
Ascii/ AVS-Fld |
AVS-fld-file describing the three-dimensional array data, saved by the model into the local file PLOT3D_DATA, needed by the visualization software AVS. This file describes the structure of the file PLOT3D_DATA (e.g. number of arrays, array dimensions, data type etc.). It uses the so-called AVS-Fld-format. It also contains the name of the file (inclusive cycle number, but without path) under which the local file PLOT3D_DATA is saved (this is the file name given in the file connection statement of the MRUN – configuration) in the permanent directory of the user (possibly on remote computers). Under this name AVS expects the data which are to be visualized. If there is no file connection statement for PLOT3D_DATA indicated in the configuration file, that file (filename) is registered “unknown” in the file PLOT3D_FLD and the actual name must be inserted later by hand. The file PLOT3D_FLD should be saved by the user in the same permanent directory as PLOT3D_DATA, so that AVS can find the file PLOT3D_DATA without any problems. If the two files lie in different directories, then the path name of the file PLOT3D_DATA must be added. AVS-fld-files are expected by AVS to have the suffix ".fld". Cycle numbers must not be attached behind this ".fld" suffix. This suffix is attached to the permanent file names (still after possible cycle numbers) by mrun if "fld" is indicated in the column 6 of the file connection statement. Likewise, AVS expects information about the coordinate system underlying the arrays on this file. This information is output by the model into the local file PLOT3D_FLD_COOR, whose content the user has to append to the file PLOT3D_FLD after the end of the model run (e.g. with an appropriate OUTPUT-command in the MRUN-configuration file: “cat PLOT3D_FLD_COOR >> PLOT3D_FLD”). For parallel runs, PLOT3D_FLD is produced by PE0 only. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
33 | PLOT3D_FLD_COOR | O |
Ascii/ AVS-Fld |
File for the description of the coordinate information output by the model into the local file PLOT3D_COOR, which is needed for the visualization of three-dimensional array data by visualization-software AVS. This file describes the structure of the file PLOT3D_COOR (e.g. grid spacing, data type etc.) using the so-called AVS-Fld-format. It also contains the name of the file (inclusive cycle number, but without path) into which the local file PLOT3D_COOR (this is the file name described in the file connection statement of the MRUN - configuration file) is output in the permanent directory of the user (possibly on remote computers). Under this name AVS expects the data which are to be visualized. If there is no file connection statement for PLOT3D_COOR indicated in the configuration file, that file is registered as "unknown" in the file PLOT3D_FLD_COOR and the actual name must be inserted later by hand. AVS expects the information contained in the file PLOT3D_FLD_COOR, as well as the remaining information about the three-dimensional arrays output by the model (see PLOT3D_FLD) in one and the same file. This is satisfied by appending the file PLOT3D_FLD_COOR after the end of a run are to the file PLOT3D_FLD (e.g. with an appropriate OUTPUT-command in the MRUN-configuration file: “cat PLOT3D_FLD_COOR >> PLOT3D_FLD”). For parallel runs, PLOT3D_FLD_COOR is written by PE0 only. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
40 and/or 40-49 |
and/or PLOT1D_DATA_1 ... (PLOT1D_DATA_O_0 PLOT1D_DATA_O_1 ...) |
O | Ascii |
This file contains data (possibly horizontally and/or temporally averaged) of the vertical profiles (see data_output_pr) written by the model in a format readable by profil. It is created only if data_output_format = 'profil' is assigned. This file's format is suitable to be read by the plot software profil. Each data point of the profiles is output in one single line (1st column: height in m, 2nd column: value of the respective quantity). Within the file, data of the individual profiles are located one behind the other. The order of the data in the file follows the order used in the assignment for data_output_pr (data_output_pr = 'u', 'v',… means that the file starts with the data of the u-component profile, followed by the v-component profile, etc.).
The profile data written to the file are described with the run parameter data_output_pr. Plots produced with these data using the parameter file PLOT1D_PAR do not have to contain all these profiles. The profiles which can be drawn in the plot are described with run parameter cross_profiles. By subsequent editing of the file PLOT1D_PAR all profiles can be plotted (also the basic layout of the plots can be changed). For orientation, each profile existing on the file PLOT1D_DATA, starts with a comment line, which indicates the presented variable and the output time. The text of these comment lines is used as a legend in the plot. The very first line of the file is a comment line, containing information about the used model version, the run identifier (base file name + number of the respective restart run), the name of the executing computer, as well as the date and time of the beginning of the run. At the end of this comment line is the name of the subdomain, to which the profiles belong (see statistic_regions). By default, the profiles present averages of the total model domain. If the model has to produce profiles for other subdomains beyond that, up to 9 further files (units No. 41-49) are created, whereby the number of the respective subdomain is attached to the file name (e.g. PLOT1D_DATA_1). The name of the file with the data of the total domain in this case reads PLOT1D_DATA_0. For presentation in the same plot, profile data of the restart runs can be attached to existing data of preceding runs of a job chain. One can do this with the file attribute tra in the file connection statement. The model produces a parameter file (PLOT1D_PAR) for these combined data, if the run parameter is set use_prior_plot1d_parameters = .T. If this is omitted, then the parameter file gives wrong plots (i.e. use_prior_plot1d_parameters = .T. and "tra" must be specified together)! Further information about output of vertical profile data is given in the description of the run parameter data_output_pr. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
80 | PARTICLE_INFOS/ (PARTICLE_INFOS_O/) |
O | Ascii | This file is created in case of particle transport (see the particles package). It contains statistical informations about the number of particles used and about the number of particles exchanged between each single PE. These informations are output after every timestep if switched on by parameter write_particle_statistics. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
81 | PLOTSP_X_PAR (PLOTSP_X_PAR_O) |
O | Ascii/ NAMELIST |
This
file is created if spectra along x are calculated and output (see the spectra
package). It contains the NAMELIST parameter set, with which
the
layout of a plot
of the data in the local file PLOTSP_X_DATA
can be steered, if these data are plotted with the plot software profil. It contains the so-called RAHMEN (frame)- and
CROSS-parameter sets (NAMELIST- group names &RAHMEN and/or
&CROSS)
needed by profil.
The user can edit these parameter sets (and thus all details of the
plot layout) after the run. By default, for one quantity, all spectra at different heights are plotted into a single panel. Different colors and line styles are used for each height. Panels of up to four quantities are arranged on one page in two lines (and two columns). More quantities are plotted on additional page(s). If there is more than one output time (see dt_dosp), additional pages will be plotted for each single output time. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
82 |
PLOTSP_X_DATA (PLOTSP_X_DATA_O) |
O |
Ascii |
This
file is created if spectra along x are calculated and output (see the spectra
package). It contains the spectral data along x (see data_output_sp)
in a format readable by profil.
The data can only be visualized with profil
using NAMELIST parameter sets, which are written by
the model to the local file PLOTSP_X_PAR. Regardless of the (sub)set of spectra specified by plot_spectra_level for actual plotting, this file contains all data of spectra specified by comp_spectra_level. Each data point of a spectrum is output in a single line (1st column: wavenumber, 2nd column: spectral coefficient). If spectra are to be calculated and output for more than one height (see comp_spectra_level), the spectral coefficients for the further heights can be found in the subsequent columns. The order of the data in the file follows the order used in the assignment for data_output_sp. For orientation, a header of comment lines (one for each height level) is placed in front of the spectral data of each quantity. They indicate the respective quantity and the output time. The text of these comment lines is used as a legend in the plot. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
83 |
PLOTSP_Y_PAR (PLOTSP_Y_PAR_O) |
O |
Ascii |
This
file is created if spectra along y are calculated and output (see the spectra
package). It contains the NAMELIST parameter set, with which
the
layout of a plot
of the data in the local file PLOTSP_Y_DATA
can be steered, if these data are plotted with the plot software profil. For more details see PLOTSP_X_PAR. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
84 |
PLOTSP_Y_DATA (PLOTSP_Y_DATA_O) |
O |
Ascii |
This
file is created if spectra along x are calculated and output (see the spectra
package). It contains the spectral data along y (see data_output_sp)
in a format readable by profil.
The data can only be visualized with profil
using NAMELIST parameter sets, which are written by
the model to the local file PLOTSP_Y_PAR. For more details see PLOTSP_X_DATA. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
85 |
PARTICLE_DATA/ (PARTICLE_DATA_O/) |
O |
Binary |
This
file is created if particle transport is switched on (see the particles
package) and contains all particle data for one or several
output
times (see dt_write_particle_data). The first record of this file contains an identification string (PALM version number, run identifier, etc., 80 characters long). The second record also contains a version string (80 characters long) followed by two records with particle group informations (see file check_open.f90). Then, for each output time, two records follow, where the first one gives some general information (numbers of particles, etc.) and the second one contains the actual particle data. A FORTRAN TYPE structure is used for storing the particle attributes. See file advec_particles.f90 for the detailed format. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
90 | PARTICLE_RESTART_ DATA_IN/ |
I |
Binary |
Binary
data, which are read in by the model at the beginning
of a restart run (see chapter
3.3). The appropriate file must have been written by the
preceding
job of the job chain (see PARTICLE_RESTART_DATA_OUT).
This file is needed if particle transport is switched on (see the particles
package) and contains all particle informations (particle
positions, velocities, etc.) from the end of the preceding run.
Concerning runs on
several processors it has to be noted that each processing element
reads its own file and that the file content is processor-dependent.
The
number of processors which can be used must not be changed during a job
chain and/or if a job chain is continued. The first record of this file contains a version number (four character string) of the subroutine, which output the data that follows (write_particles, see end of file advec_particles.f90). This number has to agree with the version number of the subroutine which is reading the file (init_parrticles.f90) in case of a restart run. Otherwise the model run is aborted. Version numbers are changed whenever new code revisions require a change of the file format. Some general informations like the number of particles stored in the file, the number of particle groups, etc.. are stored in the second record. The third record includes the particles to be released at the source and the fourth record contains all current particles. In case that particle tails are used (see maximum_number_of_tailpoints), a further record may follow, which contains the particle tail informations. A FORTRAN TYPE structure is used for storing the particle attributes. For detailed informations about the file format see the corresponding READ statements in file init_particles.f90 . |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
90 |
PARTICLE_RESTART_ DATA_OUT/ |
O |
Binary |
Binary data, which are output at the end of the run and possibly needed by restart runs (see chapter 3.3) for the initialization. This output file is then read as file PARTICLE_RESTART_DATA_IN. The file is only written if particle transport is switched on (see the particles package). For a more detailed description of the file structure see PARTICLE_RESTART_DATA_IN. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
90 |
and/or PLOT1D_PAR_0 (PLOT1D_PAR_O_0
|
O |
Ascii/
NAMELIST |
NAMELIST parameter set, with which the layout of a plot of the data in the local file PLOT1D_DATA can be steered, if these data are visualized with the plot program profil. This file contains the so-called RAHMEN (frame)- and CROSS-parameter sets (NAMELIST- group names &RAHMEN and/or &CROSS) needed by profil. These parameter sets (and thus all details of the plot layout) can be edited after the model run by the user. By default, all profiles of one variable saved at different times are drawn into one panel. Different colors are used for each output time. Which profiles are drawn into which plane and how these planes are arranged on the plot, is determined with the parameters cross_profiles, profile_columns and profile_rows. The file PLOT1D_PAR is created by the model briefly before the end of a run. If a model run crashes uncontrolled (run time errors or CPU - time exceeded), this file is usually missing, although profile data were saved to the file PLOT1D_DATA. If the model has to create profiles for different subdomains (see statistic_regions), further files are created, whereby the file name includes the number of the respective subdomain (e.g. PLOT1D_PAR_1). In this case the name of the file with NAMELIST parameters of the total domain is PLOT1D_PAR_0. For presentation in the same plot, profile data of the restart runs can be appended to existing data of preceding runs of a job chain. One can do this with the file attribute tra in the file connection statement for PLOT1D_DATA. The model produces a parameter file PLOT1D_PAR for these combined data, if the run parameter is set use_prior_plot1d_parameters = .T. If this is omitted, then the parameter file gives wrong plots (i.e. use_prior_plot1d_parameters = .T. and "tra" must be specified together)! |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
90 |
PLOT2D_XY_GLOBAL (PLOT2D_XY_GLOBAL_O) |
O |
Ascii/ NAMELIST |
NAMELIST parameter set, with which the plot layout of the data in local file PLOT2D_XY can be steered, if they are visualized with the plot program iso2d. This file contains the so-called global parameter set (NAMELIST - group name: &GLOBAL) needed by iso2d. This parameter set can be edited after the model run by the user. By default, the arrays are drawn using isolines and each array will be drawn onto a separate page (thus no color shading presentation, no vector arrows, streamlines etc.). Additionally iso2d needs the so-called local parameter sets. These are saved by the model to the local file PLOT2D_XY_LOCAL. Due to the fact that iso2d expects global and local parameter sets on one and the same file, in fact the global parameter set first, the user has to append the contents of the file PLOT2D_XY_LOCAL to the file PLOT2D_XY_GLOBAL before call of iso2d (e.g. by an OUTPUT - command in the MRUN - configuration file: “cat PLOT2D_XY_LOCAL >> PLOT2D_XY_GLOBAL”). This relatively pedantic proceedure is due to the fact that the model can create the file PLOT2D_XY_GLOBAL only at the end of the simulation (only then, when the final value of the global iso2d-parameter planz is known), while the local parameter sets are written continuously to the file PLOT2D_XY_LOCAL during the run. Since the file PLOT2D_XY_GLOBAL needs to be addressed only briefly once, output-unit 90 is used, which is also used for other files. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
90 |
PLOT2D_XZ_GLOBAL (PLOT2D_XZ_GLOBAL_O) |
O |
Ascii/ NAMELIST |
NAMELIST parameter set, with which the plot layout of the data in the local file PLOT2D_XZ can be steered, if they are visualized with the plot program iso2d. The description of the local file PLOT2D_XY_GLOBAL applies to this file, respectively. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
90 |
PLOT2D_YZ_GLOBAL (PLOT2D_YZ_GLOBAL_O) |
O |
Ascii/ NAMELIST |
NAMELIST parameter set, with which the plot layout of the data in the local file PLOT2D_YZ can be steered, if they are visualized with the plot program iso2d. The description of the local file PLOT2D_XY_GLOBAL applies to this file, respectively. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
90 | TOPOGRAPHY_DATA | I | Ascii | Two-dimensional rastered topography
height information
(in m above ground). In case of topography = 'read_from_file' the subroutine init_grid reads the topography height information (in m above ground) for each grid point in a free floating point format. The ascii file format is ESRI grid - also known as ARC/INFO ASCII GRID - without the header. The data on file are laid out naturally, i.e. in W-E orientation horizontally and in S-N orientation vertically, they must thus be organized as follows:
N (0,ny) (1,ny) (2,ny) ... (nx,ny) top of file (0,ny-1) (1,ny-1) (2,ny-1) ... (nx,ny-1) W (0,ny-2) (1,ny-2) (2,ny-2) ... (nx,ny-2) E : : (0,0) (1,0) (2,0) ... (nx,0) bottom of file S Example for a 50m tall building surrounded by a 12.5m tall podium on flat ground: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 0 0 0 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 0 0 0 12.5 12.5 50 50 50 50 50 50 12.5 12.5 0 0 0 12.5 12.5 50 50 50 50 50 50 12.5 12.5 0 0 0 12.5 12.5 50 50 50 50 50 50 12.5 12.5 0 0 0 12.5 12.5 50 50 50 50 50 50 12.5 12.5 0 0 0 12.5 12.5 50 50 50 50 50 50 12.5 12.5 0 0 0 12.5 12.5 50 50 50 50 50 50 12.5 12.5 0 0 0 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 0 0 0 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 These data must exactly match the horizontal grid. Due to the staggered grid the topography may be displaced by -0.5 dx in x-direction and -0.5 dy in y-direction depending on the parameter topography_grid_convention. See also the example in trunk/EXAMPLES/topo_file/ .Alternatively, the user may add code to the user interface subroutine user_init_grid to allow different data formats. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
101 | DATA_2D_XY_NETCDF (DATA_2D_XY_NETCDF_O) |
I/O | Binary/ NetCDF- format |
This file
contains data of the two-dimensional horizontal
cross sections (see data_output)
in NetCDF format. The data in this file can be visualized by any
graphic software which provides a NetCDF interface (e.g. NCL or ferret). More detailed informations about the PALM-NetCDF-output are given in chapter 4.5.1. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
102 | DATA_2D_XZ_NETCDF (DATA_2D_XZ_NETCDF_O) |
I/O | Binary/ NetCDF- format |
This file
contains data of the two-dimensional vertical (xz)
cross sections (see data_output)
in NetCDF format. The data in this file can be visualized by any
graphic software which provides a NetCDF interface (e.g. NCL or ferret). More detailed informations about the PALM-NetCDF-output are given in chapter 4.5.1. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
103 | DATA_2D_YZ_NETCDF (DATA_2D_YZ_NETCDF_O) |
I/O | Binary/ NetCDF- format |
This file
contains data of the two-dimensional vertical
(yz) cross sections (see data_output)
in NetCDF format. The data in this file can be visualized by any
graphic software which provides a NetCDF interface (e.g. NCL or ferret). More detailed informations about the PALM-NetCDF-output are given in chapter 4.5.1. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
104 | DATA_1D_PR_NETCDF (DATA_1D_PR_NETCFD_O) |
I/O | Binary/ NetCDF- format |
This file
contains data of the horizontally averaged vertical profiles (see data_output_pr)
in NetCDF format. The data in this file can be visualized by any
graphic software which provides a NetCDF interface (e.g. NCL or ferret). More detailed informations about the PALM-NetCDF-output are given in chapter 4.5.1. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
105 | DATA_1D_TS_NETCDF (DATA_1D_TS_NETCDF_O) |
I/O | Binary/ NetCDF- format |
This file
contains data of the timeseries (see dt_dots)
in NetCDF format. The data in this file can be visualized by any
graphic software which provides a NetCDF interface (e.g. NCL or ferret). More detailed informations about the PALM-NetCDF-output are given in chapter 4.5.1. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
106 | DATA_3D_NETCDF (DATA_3D_NETCDF_O) |
I/O | Binary/ NetCDF- format |
This file
contains data of the 3d-volume data (see data_output)
in NetCDF format. The data in this file can be visualized by any
graphic software which provides a NetCDF interface (e.g. NCL or ferret). More detailed informations about the PALM-NetCDF-output are given in chapter 4.5.1. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
107 | DATA_1D_SP_NETCDF (DATA_1D_SP_NETCDF_O) |
I/O | Binary/ NetCDF- format |
This file
contains data of the horizontal spectra (see data_output_sp)
in NetCDF format. The data in this file can be visualized by any
graphic software which provides a NetCDF interface (e.g. NCL or ferret). More detailed informations about the PALM-NetCDF-output are given in chapter 4.5.1. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
108 | DATA_PRT_NETCDF/ (DATA_PRT_NETCDF_O/) |
I/O | Binary/ NetCDF- format |
This file
contains particle data (see dt_prel)
in NetCDF format. The data in this file can be visualized by any
graphic software which provides a NetCDF interface (e.g. NCL or ferret). More detailed informations about the PALM-NetCDF-output are given in chapter 4.5.1. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
109 | DATA_1D_PTS_NETCDF (DATA_1D_PTS_NETCDF_O) |
I/O | Binary/ NetCDF- format |
This
file contains data of the timeseries of particle quantities (see dt_prel)
in NetCDF format. The data
in this file can be visualized by any graphic software which provides a
NetCDF interface (e.g. NCL
or
ferret).
For a list of available output quantities see dt_dopts. In case of using more than one particle group (see number_of_particle_groups), seperate time series are output for each of the groups. The long names of the variables in the NetCDF file containing the respective timeseries all end with the string' PG ##', where ## is the number of the particle group (01, 02, etc.). More detailed informations about the PALM-NetCDF-output are given in chapter 4.5.1. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
111 | DATA_2D_XY_AV_NETCDF (DATA_2D_XY_AV_NETCDF_O) |
I/O | Binary/ NetCDF- format |
This file
contains data of the temporally averaged two-dimensional horizontal
cross sections (see data_output)
in NetCDF format. The data in this file can be visualized by any
graphic software which provides a NetCDF interface (e.g. NCL or ferret). More detailed informations about the PALM-NetCDF-output are given in chapter 4.5.1. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
112 | DATA_2D_XZ_AV_NETCDF (DATA_2D_XZ_AV_NETCDF_O) |
I/O | Binary/ NetCDF- format |
This file
contains data of the temporally
averaged two-dimensional vertical (xz)
cross sections (see data_output)
in NetCDF format. The data in this file can be visualized by any
graphic software which provides a NetCDF interface (e.g. NCL or ferret). More detailed informations about the PALM-NetCDF-output are given in chapter 4.5.1. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
113 | DATA_2D_YZ_AV_NETCDF (DATA_2D_YZ_AV_NETCDF_O) |
I/O | Binary/ NetCDF- format |
This file
contains data of the temporally
averaged two-dimensional vertical
(yz) cross sections (see data_output)
in NetCDF format. The data in this file can be visualized by any
graphic software which provides a NetCDF interface (e.g. NCL or ferret). More detailed informations about the PALM-NetCDF-output are given in chapter 4.5.1. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
116 | DATA_3D_AV_NETCDF (DATA_3D_AV_NETCDF_O) |
I/O | Binary/ NetCDF- format |
This file
contains data of the temporally
averaged 3d-volume data (see data_output)
in NetCDF format. The data in this file can be visualized by any
graphic software which provides a NetCDF interface (e.g. NCL or ferret). More detailed informations about the PALM-NetCDF-output are given in chapter 4.5.1. |