make_static.py Description
This section outlines the steps needed to create a static driver using the make_static script (in the following sections referred to as "the script"), which leverages the functions of palmpy to create static driver from geodata. When it comes to geodata, due to the different ways and standards, how people record geographical features, it is extremely difficult to write a script that does not require any data preprocessing. In order to create a simulation setup procedure that is easy to employ, some generalization standards were outlined about how geodata should look like in order for the script to be able to understand it.
It must be noted here that there is also a script shipped with PALM that can be used to create a static driver file. However, at the time it was needed to create static drivers for various projects at the Center for Aviation, this script was not usable as it relied heavily on geodata that was preprocessed by the DLR. Furthermore, the input files were not optional. Therefore, it was decided to create a new script, that fulfilled the needs at the Center for Aviation for projects, that were not necessarily focussed around urban climate simulations, but it turned out to be generally applicable. The core of the script created here was set up completely on its own without reusing code from the shipped PALM script. Regarding the implementation of leaf area density arrays, the approach of the shipped script was analyzed before implementing our own approach. Therefore, while the outcome of both scripts may be comparable, the mechanics behind are two separate pair of shoes.
In the process of designing this workflow, it was found that is required to decide on a specific data format, that data needs to have in order to be able to be automatically forged into a PALM static driver file. With the vastness of different sources of geodata in the world, it is almost impossible to write a script that can adapt to an arbitrary naming of fields in a GIS attribute table. Therefore, the following requirements were set up in order to homogenize the input data for an automated script. In doing so, a sensible balance had to be struck between the generalization of data and the flexibility to systematically change parameters in the static drivers. This was all done keeping in mind the functionalities in PALM as of May 2020. It may be great to have data about the detailed position of a water fountain that is only temporarily active, but there is currently to option to include temporarily active water fountains in a PALM simulation - a grid point can either be vegetation, pavement or water. Therefore, to setup a PALM simulation in practice, geodata needs to be collected, then it needs to be searched for relevant information. And as the relevant data often does not come collected in a single dataset, the relevant data needs to be subset and exported into new files. The following sections will outline how these files need to look like. It shall be mentioned here that not all datasets need to be provided - which information is used can be steered by setting appropriate flags in the namelist. This will be discussed further below (see Static File Generation).
With this script, it is possible to create a PALM static driver file with most, but not all, supported variables (as of April 2020). Which variables can be included in a static driver file can be seen in the official PALM documentation.
Currently, with the presented code, it is possible to include the following features into a static driver file:
- topography (Variable
zt) - land cover (
vegetation_type,water_type) - paved surfaces (
pavement_type) - soil type (
soil_type) - surface fraction (
surface_fraction) - resolved vegetation (
lad) - tree identification numbers (
tree_id) - building heights (2D:
buildings_2d, 3D:buildings_3d) - building identification numbers (
building_id) - building type (
building_type) - street type (
street_type)
Furthermore, the following actions are possible:
- supplying manually captured farming areas (affects
vegetation_type) - changing individual vegetation types (
vegetation_pars) - make individual changes to building parameters (
building_pars) - change albedo parameters for vegetation types (
albedo_pars,vegetation_pars)
Actions that are not implemented yet, but should be tackled soon:
- global definition of roughness lenght (
z0, useful for wind energy projects/benchmark cases) - global definition of albedo types (
albedo_type, overwrites all individual albedo definitions. Useful for future urban climate simulations) - individual changes to water and pavement types (similar to
vegetation_pars, implementation is straightforward)
While many variables can be included in a generate static driver, not all need to be. This can be steered by setting appropriate flags in the namelist, that needs to be provided when starting the static generation script.
A big part of the framework is a static file generation script, that should automate a large portion of the required workflow from source geodata to usable PALM static driver file. The script, which is presented in the following sections, evolved over time and went through many iterations. That said, it is nowhere near from perfect and some implementation choices may be questionable. However, it proves to be a valuable tool as it is now and may be used as a starting point for further development, which will most definitely take place.
The script requires a namelist file, where vital information about the generation process is defined. All the options in the namelist file are outlined in detail below. This ranges from information about where input files are stored, to where the palmpy module is located, to the extents of each domain and which variables shall be processed. The script has become quite complex, due to the many existing limitations and requirements that PALM regarding the static driver file. During the creation of this script, some checks were implemented as well, which prevent the creation of an incompatible static driver, which would lead to a lot of time lost creating the required PALM namelists and dynamic driver files.
Running the script itself is a rather quick action, the time consuming bit lies in the preprocessing of the data. However, should a part of the script fail, for whatever reasons, one needs to delve into the script and find out what is going wrong. To this end, the script itself is commented extensively, which should help to pinpoint the errors. However, some errors may be cryptic to a new user. Please contact the author of this documentation for additional guidance. This may also help to identify and isolate potential bugs in the code, which was tested a lot, but not in a systematic and extensive manner.
Should input files not be available in the formats described above, this would require the script to be adapted to the particular project. It is not possible to create a solution that fits every individual need (at least not in the given timeframe for this project), but the way the script is built up, modifications should be easy to implement. For instance, should a shape file only be available as raster data, one could change the gdt.rasterandcuttlm() function to gdt.cutalti() function, which lacks the rasterization step.
The following flowchart provides an insight into the inner workings of the make_static script. The flowchart touches on every aspect of the script, however, not every single line is reproduced. If two lines performed the same action and summarizing them seemed appropriate, this was hence done for better legibility of the flowchart.
From the start to node A, the script reads the namelist, saves the provided information in lists and plots an overview of the case. Between nodes A and B, the process to create the topography and land use arrays are outlined. Between B and C, resolved vegetation and crops are handled. Between C and D, paved surfaces and buildings are set up. Between D and E, street types array is created and all arrays gathered, put into a Dataset and written to a netCDF file. After node E, the process to output the parameter files and INIFOR namelist is outlined.
