Version 42 (modified by suehring, 7 years ago) (diff) |
---|
!!! Currently under construction !!'''
PALM-4U provides a standardized way via the NetCDF data format to input e.g. global attributes, topography data or surface properties, vegetation properties, etc., as well as initialization data and boundary conditions for the prognostic variables.
Input variables are distinguished between static, dynamic, radiation and chemistry variables, while for each type a separate input file exists. The static input file, indicated by the filename supplement _STATIC, contains all static information, such as topography, geographical latitude and longitude, surface property and vegetation information. The dynamic input file, indicated by the filename supplement _STATIC, contains dynamic information on the initial state of the atmosphere or time-dependent boundary conditions. The radiation input file, indicated by _RAD, contains static and dynamic information on radiation properties such as trace gas profiles or sky-view factors. The chemistry input file, indicated by _CHEM, contains static and dynamic information on chemical species and emissions.
The initialization procedure for the surface elements follows a multi-step approach, depending on the given level of detail. In a first step, surfaces elements are initialized horizontally homogeneous with a bulk classification for each type (e.g. vegetation or soil), either set by a default value or set by a namelist-provided value, while the bulk classification provides standard values for a variety of parameters. In a second step, surface elements are initialized individually by providing the bulk classification at each grid point. In case more detailed information is available, all/single parameters can also initialized individually at each grid point.
The provided input data is used to classify each surface element according to its treatment, i.e. default-, natural- or urban-type, in order to treat each surface element accordingly. In case no land-surface or urban-surface scheme is applied, all surfaces are classified as default-type. If a surface element has vegetation, pavement or water, it will be classified as natural-type and is treated by the land-surface scheme, while building surfaces will be treated by the urban-surface scheme.
After reading the input files, PALM-4U performs consistency checks on the provided data. All applied input variables are listed and explained below and additional remarks on restrictions and initialization are given. Please note, this documentation does not comprise all possible global and variables attributes, only those which are required for read by PALM. More detailed information on variable attributes can be found in the Palm input data standard.
Static input file
Global attributes:
Attribute | Type | Explanation / Remarks |
---|---|---|
origin_lat | NC_FLOAT | Geographical latitude in degrees north. This attribute defines the south boundary of the model domain and overwrites the namelist parameter latitude, which is used e.g. for the Coriolis parameters as well as for the radiation. Please note, in case of a nested run, values of latitude will be synchronized internally to the respective value of the root parent domain. |
origin_lon | NC_FLOAT | Geographical longitude in degrees east. This attribute defines the left boundary of the model domain and overwrites the namelist parameter longitude, which is used e.g. for the radiation. Please note, in case of a nested run, values of longitude will be synchronized internally to the respective value of the root parent domain. |
origin_z | NC_FLOAT | Reference height in m above sea level after DHHN2016. |
Topography:
In order to prescribe topography from the static input file, topography = 'read_from_file' is required. The minimum requirement for proper topography input is orography_2D.
Input variable | Type | LOD | Explanation / Remarks |
---|---|---|---|
orography_2D(y,x) | NC_FLOAT | none | Terrain height in m relative to origin_z. If not provided, the relative terrain height will be set to 0 all over the model domain. Please note, orography_2D must not contain any _FillValues. |
buildings_2D(y,x) | NC_FLOAT | 1 | 2-dimensional building height in m relative to the underlying terrain. No holes or overhanging structures are possible. buildings_2D will be mounted on top of the maximum local terrain height occupied by the respective building. Please note, buildings_2D will not be used if buildings_3D is present on file. If buildings_2D are prescribed, building_id is required. |
buildings_3D(z,y,x) | NC_BYTE | 2 | 3-dimensional building topology relative to the underlying terrain. buildings_3D will be mapped on top of the maximum local terrain height occupied by the respective building. Note, buildings_3D do not need to be prescribed beyond the top level of the highest buildings. If buildings_3D are prescribed, building_id is required. |
building_id(y,x) | NC_INT | none | Building ID is used to identify single building envelopes, which is used for correct mapping of buildings on top of the underlying terrain, as well as for the indoor_model. Please note, building_id must not contain any _FillValue at grid points where buildings_2D/3D is defined. |
Surface variables:
For a proper classification of natural land and water surfaces, pavement_type, soil_type, vegetation_type and water_type are required, which define bulk parameters for albedo, soil, root distribution, leaf-area density, etc. To enable initialization of the land-surface model with driver-provided variables, the namelist parameter surface_type need to be set to 'netcdf'. Further, if the urban-surface model is applied, also building_type is required, which defines bulk parameters to run the urban-surface model. Please note, for the sake of consistency, at least one of the variables pavement_type, vegetation_type, water_type or building_type need to be defined at each 'xy' location.
Input variable | Type | LOD | Explanation / Remarks |
---|---|---|---|
albedo_pars (nalbedo_pars,y,x) | NC_FLOAT | none | Spectral and broadband albedo for natural and urban surfaces for (y,x)-locations. When albedo_type = 0, all parameters must be set, otherwise single parameters set by albedo_type can be overwritten. |
albedo_type(y,x) | NC_BYTE | none | Optional classification of albedo. Default values for albedo_type are already set in the bulk parametrization of building_type, pavement_type, vegetation_type, water_type, but will be overwritten in case albedo_type is defined. The value of albedo_type will also overwrite the prescribed values in vegetation_pars, water_pars, or pavement_pars. An overview of the different albedo types can be found here. |
building_pars (nbuilding_pars,y,x) | NC_FLOAT | none | Parameters for the building parameterization. When building_type = 0, all parameters must be set, otherwise single parameters set by building_type can be overwritten. building_pars becomes only effective if the urban-surface model or the indoor_model are applied. Building parameters can be distinguished between ground-floor and upper level. For more information, please see here. |
building_surface_pars
(nbuilding_surface_pars_s, | NC_FLOAT | none | Detailed information for specific building surfaces. This variable can contain data for the entire domain or for selected areas where detailed data is available. Setting of building_subsurface_pars will replace parameter settings made by building_type and building_pars. building_subsurface_pars becomes only effective if the urban-surface model is applied. For more information, please see here. |
building_type(y,x) | NC_BYTE | none | Building type used to select bulk parameters. building_type is required if the urban-surface model or the indoor_model are applied. Please note, building_type must not contain any _FillValue at grid points where buildings_2D/3D is defined. An overview of the different building types can be found here. |
pavement_pars (npavement_pars,y,x) | NC_FLOAT | none | Parameters required for the bulk pavement parameterization in the land surface scheme. When pavement_type = 0, all parameters must be set, otherwise single parameters set by pavement_type can be overwritten. |
pavement_subsurface_pars
(npavement_subsurface_pars, | NC_FLOAT | none | Parameters required for the bulk pavement parameterization. For all zsoil levels where pavement_subsurface_pars is not missing, the settings of the soil model are overwritten, i.e. thermal conductivity and heat capacities are set, and the layers are impermeable for water. When pavement_type = 0, all parameters must be set. |
pavement_type(y,x) | NC_BYTE | none | Bulk classification of pavements on soil. At locations where pavement_type is defined, soil_type must not contain any _FillValues. pavement_type overwrites the homogeneously prescribed setting via the namelist parameter pavement_type. An overview of the different pavement types can be found here. |
soil_pars (nsoil_pars,(zsoil),y,x) | NC_FLOAT | 1, 2 | Parameters for soil parametrization. When soil_type = 0, all parameters must be set, otherwise single parameters set by soil_type can be overwritten. In case lod = 1, prescribed parameters are vertically uniform, while in case lod = 2 parameters can be set for each layer individually. An overview of the different soil parameters can be found here. |
soil_type((zsoil),y,x) | NC_BYTE | 1, 2 | Bulk classification of soil in terms of porosity. soil_type overwrites the homogeneously prescribed setting via the namelist parameter soil_type. In case lod = 1, a 2-dimensional vertically uniform soil texture is prescribed, while in case lod = 2 the 3-dimensional soil_type is set for each layer individually. An overview of the different soil types can be found here. |
surface_fraction (nsurface_fraction,y,x) | NC_FLOAT | none | Relative fraction of the respective surface type given via vegetation_type (index 0), pavement_type (index 1) and water_type (index 2). The sum over all relative fractions must be equal to one for each location. This parameter is only needed at locations (y,x) where more than one surface type (vegetation, pavement, water) is defined. Moreover, if more than one surface type is defined at a location, the relative fractions of the respective surface types must not be 0. Also, if surface_fraction is given for one of the above mentioned surface types, this type need to be defined at this location. |
vegetation_pars (nvegetation_pars,y,x) | NC_FLOAT | none | Parameters for the bulk parametrization of non-resolved vegetation in the land-surface model for each (y,x)-location. All/single parameters set by vegetation_type can be overwritten for given (y,x)-location. Please note, if vegetation_type = 0, all parameters must be set. An overview of the different vegetation parameters can be found here. |
vegetation_type(y,x) | NC_BYTE | none | Bulk classification of non-resolved vegetation surfaces at natural land surface types. At locations where vegetation_type is defined, soil_type must not contain any _FillValues. vegetation_type overwrites the homogeneously prescribed setting via the namelist parameter vegetation_type. An overview of the different vegetation types can be found here. |
water_pars (nalbedo_pars,y,x) | NC_FLOAT | none | Parameters used for the parameterization of water surfaces. When water_type = 0, all parameters must be set, otherwise single parameters set by water_type can be overwritten. |
water_type(y,x) | NC_BYTE | none | Bulk classification of water bodies. water_type overwrites the homogeneously prescribed setting via the namelist parameter water_type. An overview of the different water types can be found here. |
Resolved plant canopy:
In order to consider resolved plant canopy, the plant-canopy model need to be switched on and setting of canopy_mode = 'read_from_file_3d' is required.
Input variable | Type | LOD | Explanation / Remarks |
---|---|---|---|
leaf_area_density (zlad,y,x) | NC_FLOAT | none | Vegetation resolved by the plant-canopy model in terms of a three dimensional leaf area density (LAD). Please note, plant canopy is prescribed relative to the underlying topography and will be mounted on top of the terrain. A preprocessor tool is available to convert arbitrary vegetation information to an LAD field. If leaf_area_density is set, all settings of LAD-related parameters made in the namelist &canpar will be ignored. Please note, unresolved vegetation is already treated via the land-surface model considered by vegetation_type. Please check for possible double counting of similar vegetation in case vegetation_type and leaf_area_density is set at (y,x)-location. |
basal_area_density (zlad,y,x) | NC_FLOAT | none | Basal area in m2 (i.e. trunk area) per grid volume. A preprocessor tool is available to convert arbritrary vegetation information to an basal area density field. The dimension of the field must be equal to that of the leaf area density. Please note, basal area is prescribed relative to the underlying topography. |
root_area_density_lad (zsoil,y,x) | NC_FLOAT | none | Root area of the resolved vegetation in the soil. |
root_area_density_lsm (zsoil,y,x) | NC_FLOAT | none | Root area of the parameterized vegetation in the soil that is set via vegetation_type. When vegetation_type = 0, the root_area_density_lsm must be set. |
Dynamic input file
Radiation input file
Chemistry input file
Attachments (14)
-
example_static
(29.5 KB) -
added by suehring 7 years ago.
Example static input file
-
example_driver_static.ncl
(16.8 KB) -
added by suehring 7 years ago.
NCL-script to create example static input file
-
PALM_input_data_standard_v1.9.pdf
(198.6 KB) -
added by gronemeier 7 years ago.
PALM Input Data Standard, version 1.9; use for PALM rev3051 and above
- create_simple_static_driver.py (12.7 KB) - added by scharf 6 years ago.
- button_aerosol.png (22.3 KB) - added by scharf 6 years ago.
- button_chemistry.png (23.9 KB) - added by scharf 6 years ago.
- button_dynamic.png (27.3 KB) - added by scharf 6 years ago.
- button_radiation.png (20.0 KB) - added by scharf 6 years ago.
- button_static.png (25.4 KB) - added by scharf 6 years ago.
- button_virtualmeasurements.png (26.8 KB) - added by scharf 6 years ago.
-
PALM_input_data_standard_v1.10.pdf
(171.5 KB) -
added by maronga 5 years ago.
PALM input data standard v1.10
-
PALM_input_data_standard_v1.11.pdf
(177.3 KB) -
added by maronga 5 years ago.
PALM input data standard v1.11
-
PALM_input_data_standard_v1.12.pdf
(176.0 KB) -
added by maronga 5 years ago.
PALM input data standard v1.12
- PALM_input_data_standard.pdf (176.0 KB) - added by suehring 5 years ago.
Download all attachments as: .zip