Changes between Version 119 and Version 120 of doc/app/iofiles
- Timestamp:
- Feb 12, 2020 1:26:50 PM (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
doc/app/iofiles
v119 v120 5 5 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. \\\\ 6 6 Depending on the configuration of the underlying file-system (e.g. Lustre) and the capacity of the I/O-hardware, simultaneous output to a larger number of files, i.e. if a larger number of PEs is used (>1000), may lead to severe problems as job aborts or even to a complete crash of the whole system. In order to circumvent this problem, the maximum number of parallel I/O streams (i.e. the number of files which are simultaneously written), can be limited by using the [wiki:doc/app/palmrun palmrun]-option {{{-w <max # of streams>}}}, where {{{<max # of streams>}}} should be smaller or equal 256 (on the SGI-ICE of HLRN-II). The (parallel) output is then done in a sequential order for blocks of 256 PEs. \\\\ 7 In case of [../examples/coupled coupled] atmosphere-ocean runs, both the atmosphere and the [../ini par#ocean 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'.) \\7 In case of [../examples/coupled coupled] atmosphere-ocean runs, both the atmosphere and the [../initialization_parameters#ocean 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'.) \\ 8 8 9 9 ||='''Unit''' =||='''Name''' =||='''I/O''' =||='''Format''' =||='''Explanation / File content''' =|| … … 41 41 }}} 42 42 {{{#!td 43 Binary data, which are read in by the model at the beginning of a [../runs restart run]. The appropriate file must have been written by the preceding job of the job chain (see [#BINOUT BINOUT]). This file contains the [../ini parinitial parameters] 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 [../d3par#data_output_pr 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. \\\\43 Binary data, which are read in by the model at the beginning of a [../runs restart run]. The appropriate file must have been written by the preceding job of the job chain (see [#BINOUT BINOUT]). This file contains the [../initialization_parameters initial parameters] 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 [../d3par#data_output_pr 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. \\\\ 44 44 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. \\\\ 45 45 The first record of this file contains a version number (ten character string) of the subroutine, 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. \\\\ 46 Starting from the second record, all initial parameters follow (exception: [../ini par#initializing_actions 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 [../inipar#nz nz] and [../inipar#statistic_regions statistic_regions]. If a variable with unknown name is found the model run is aborted. \\\\46 Starting from the second record, all initial parameters follow (exception: [../initialization_parameters#initializing_actions 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 [../initialization_parameters#nz nz] and [../initialization_parameters#statistic_regions statistic_regions]. If a variable with unknown name is found the model run is aborted. \\\\ 47 47 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). \\\\ 48 48 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}}}). \\\\ … … 66 66 }}} 67 67 {{{#!td 68 Binary data, which are written by the model at the end of the run and possibly needed by [../runs restart runs] for the initialization. This output file is then read in as file [#BININ BININ]. It contains the [../ini parinitial parameters] 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 [../d3par#data_output_pr 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 BININ]. \\\\68 Binary data, which are written by the model at the end of the run and possibly needed by [../runs restart runs] for the initialization. This output file is then read in as file [#BININ BININ]. It contains the [../initialization_parameters initial parameters] 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 [../d3par#data_output_pr 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 BININ]. \\\\ 69 69 The file BINOUT is written by the model only if, with the help of the [wiki:doc/app/palmrun palmrun]-configuration file, the environment variable {{{write_binary}}} is assigned to the {{{true}}} (see [../runs example]). \\\\ 70 70 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. … … 86 86 {{{#!td 87 87 This file contains the so-called time step control output of the model. At certain temporal intervals, which are described by the run parameter [../d3par#dt_run_control 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. \\\\ 88 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 [../ini par#dt_run_control_1d dt_run_control_1d]). \\\\88 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 [../initialization_parameters#dt_run_control_1d dt_run_control_1d]). \\\\ 89 89 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 HEADER] (however without data concerning the consumed CPU time, because these are only known at the end of a run). With the run parameter [../d3par#force_print_header force_print_header] it can be achieved that this information is also written at the beginning of the file RUN_CONTROL at restart runs. \\\\ 90 90 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): \\ … … 279 279 }}} 280 280 {{{#!td style="vertical-align:top;border:none" 281 Distance (in km) the coordinate system has been moved in x-direction with Galilei-Transformation switched on (see [../ini par#galilei_transformation galilei_transformation]).281 Distance (in km) the coordinate system has been moved in x-direction with Galilei-Transformation switched on (see [../initialization_parameters#galilei_transformation galilei_transformation]). 282 282 }}} 283 283 |------ … … 286 286 }}} 287 287 {{{#!td style="vertical-align:top;border:none" 288 Distance (in km) the coordinate system has been moved in y-direction with Galilei-Transformation switched on (see [../ini par#galilei_transformation galilei_transformation]).288 Distance (in km) the coordinate system has been moved in y-direction with Galilei-Transformation switched on (see [../initialization_parameters#galilei_transformation galilei_transformation]). 289 289 }}} 290 290 |------ … … 293 293 }}} 294 294 {{{#!td style="vertical-align:top;border:none" 295 Number of multigrid cycles used if {{{psolver='multigrid'}}} (see [../ini par#psolver psolver] and [../inipar#mg_cycles mg_cycles]).295 Number of multigrid cycles used if {{{psolver='multigrid'}}} (see [../initialization_parameters#psolver psolver] and [../initialization_parameters#mg_cycles mg_cycles]). 296 296 }}} 297 297 }}} … … 312 312 }}} 313 313 {{{#!td 314 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 [../d3par#dt_dopr_listing 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 [../ini par#statistic_regions statistic_regions] for additional statistic evaluation, then the tables described above are written for each individual subdomain. The name of the respective subdomain (see [../userpar#region region]) appears in the header of the respective table. \\314 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 [../d3par#dt_dopr_listing 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 [../initialization_parameters#statistic_regions statistic_regions] for additional statistic evaluation, then the tables described above are written for each individual subdomain. The name of the respective subdomain (see [../userpar#region region]) appears in the header of the respective table. \\ 315 315 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 about 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: \\ 316 316 {{{#!table style="border:none" … … 473 473 }}} 474 474 {{{#!td 475 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 [../ini par#dt_pr_1d 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: \\475 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 [../initialization_parameters#dt_pr_1d 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: \\ 476 476 {{{#!table style="border:none" 477 477 {{{#!td style="vertical-align:top;border:none;width:40px" … … 811 811 {{{#!td 812 812 The file contains column-separated surface variables shf, qsws, pt_surface, q_surface, surface_pressure and profiles of ug, vg, w_subs, td_lsa_lpt, td_lsa_q (large scale advection tendencies), td_sub_lpt, td_sub_q (large scale subsidence tendencies) at different time steps. The data is usually provided by measurements or larger scale models.\\\\ 813 In case of [../ini par#large_scale_forcing large_scale_forcing] = ''.T.'' the subroutine {{{lsf_init}}} in [source:palm/trunk/SOURCE/large_scale_forcing_nudging_mod.f90 large_scale_forcing_nudging_mod] which is called in [source:palm/trunk/SOURCE/module_interface.f90 module_interface_init] reads the surface and profile information in a free floating point format. The hash character (#) is used as a special steering character. The data in the file has to be organized in the following way:\\813 In case of [../initialization_parameters#large_scale_forcing large_scale_forcing] = ''.T.'' the subroutine {{{lsf_init}}} in [source:palm/trunk/SOURCE/large_scale_forcing_nudging_mod.f90 large_scale_forcing_nudging_mod] which is called in [source:palm/trunk/SOURCE/module_interface.f90 module_interface_init] reads the surface and profile information in a free floating point format. The hash character (#) is used as a special steering character. The data in the file has to be organized in the following way:\\ 814 814 * The file has to begin with '''exactly''' three lines beginning with a # where for example header information can be stored. 815 815 * The first line not beginning with a # contains surface data which must be column separated and in the following sequence: time, shf, qsws, pt_surface, q_surface, surface_pressure. … … 837 837 {{{#!td 838 838 The file contains column-separated profiles of the prognostic variable u, v, w, lpt, q originating from measurements or larger scale models which are to be used for nudging. Additionally, height information and the nudging time scale tnudge have to be provided.\\\\ 839 In case of [../ini par#nudging nudging] = ''.T.'' the subroutine {{{nudge_init}}} in [source:palm/trunk/SOURCE/large_scale_forcing_nudging_mod.f90 large_scale_forcing_nudging_mod] which is called in [source:palm/trunk/SOURCE/module_interface.f90 module_interface_init] reads the profile information in a free floating point format. The hash character (#) is used as a special steering character. The data in the file has to be organized in the following way:\\839 In case of [../initialization_parameters#nudging nudging] = ''.T.'' the subroutine {{{nudge_init}}} in [source:palm/trunk/SOURCE/large_scale_forcing_nudging_mod.f90 large_scale_forcing_nudging_mod] which is called in [source:palm/trunk/SOURCE/module_interface.f90 module_interface_init] reads the profile information in a free floating point format. The hash character (#) is used as a special steering character. The data in the file has to be organized in the following way:\\ 840 840 * The file can begin with an arbitrary number of lines beginning with a # where for example header information can be stored. 841 841 * A line beginning with ''# time'' indicates the beginning of a profile data set at time step ''time''. … … 861 861 {{{#!td 862 862 Two-dimensional rastered topography height information (in m above ground). \\\\ 863 In case of [../ini par#topography 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 [http://en.wikipedia.org/wiki/ESRI_grid#ASCII ESRI grid] - also known as [http://en.wikipedia.org/wiki/ESRI_grid#ASCII 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: \\863 In case of [../initialization_parameters#topography 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 [http://en.wikipedia.org/wiki/ESRI_grid#ASCII ESRI grid] - also known as [http://en.wikipedia.org/wiki/ESRI_grid#ASCII 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: \\ 864 864 * each line contains height information in m from ''i = 0, ..., nx,'' 865 865 * the top line contains height information in m for ''j = ny'' (North), the bottom line for ''j = 0'' (South), … … 891 891 0 0 0 0 0 0 0 0 0 0 0 0 0 892 892 }}} 893 These data must exactly match the horizontal grid. Due to the staggered grid, the topography may be displaced by -0.5 [../ini par#dx dx] in x-direction and -0.5 [../inipar#dy dy] in y-direction depending on the parameter [../inipar#topography_grid_convention topography_grid_convention]. See also the example in [source:/palm/trunk/EXAMPLES/topo_file trunk/EXAMPLES/topo_file/]. \\\\893 These data must exactly match the horizontal grid. Due to the staggered grid, the topography may be displaced by -0.5 [../initialization_parameters#dx dx] in x-direction and -0.5 [../initialization_parameters#dy dy] in y-direction depending on the parameter [../initialization_parameters#topography_grid_convention topography_grid_convention]. See also the example in [source:/palm/trunk/EXAMPLES/topo_file trunk/EXAMPLES/topo_file/]. \\\\ 894 894 Alternatively, the user may add code to the user interface subroutine [../userint/int#user_init_grid user_init_grid]. \\\\ 895 895 Please note, topography information can also be provide in netCDF format via file [#PIDS_STATIC].
