the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 04 Mar 2026
palm_csd 25.10: A processing tool for static input data in the PALM model system
Abstract. We present palm_csd version 25.10, the current default preprocessing tool for generating the static driver for the building-resolving large-eddy simulation model PALM. The static driver defines the spatial surface characteristics of the simulation domain. This paper provides a technical description of the updated palm_csd workflow, focusing on the processing of buildings, vegetation, pavement, water bodies, terrain height and land cover in compliance with the PALM Input Data Standard (PIDS). Major extensions introduced since the previous description include the processing of georeferenced raster and vector data with automated reprojection, user-defined domain rotation and nesting, enhanced handling of building parameters, optimized generation of resolved vegetation, estimation of leaf area index from vegetation height, and the derivation of static input for non-building-resolving simulations based on Local Climate Zone classifications. We demonstrate the application of palm_csd using publicly available geodata for the city of Berlin (Germany), covering both building-resolving and LCZ-based simulation setups. Common data inconsistencies and sources of uncertainty in urban geodata are discussed. palm_csd 25.10 provides a reproducible, flexible and continuously maintained framework for transforming heterogeneous geospatial datasets into PALM-compatible static drivers to support both detailed urban morphology and coarser-scale urban climate applications.
Competing interests: At least one of the (co-)authors is a member of the editorial board of Geoscientific Model Development. The peer-review process was guided by an independent editor, and the authors also have no other competing interests to declare.
Publisher's note: Copernicus Publications remains neutral with regard to jurisdictional claims made in the text, published maps, institutional affiliations, or any other geographical representation in this paper. While Copernicus Publications makes every effort to include appropriate place names, the final responsibility lies with the authors. Views expressed in the text are those of the authors and do not necessarily reflect the views of the publisher.-
Notice on discussion status
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
-
Preprint
(7469 KB)
-
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
- Preprint
(7469 KB) - Metadata XML
- BibTeX
- EndNote
- Final revised paper
Journal article(s) based on this preprint
Interactive discussion
Status: closed
-
RC1: 'Comment on egusphere-2026-355', Anonymous Referee #1, 03 Apr 2026
-
AC1: 'Reply on RC1', Sebastian Schubert, 26 May 2026
Dear Reviewer #1
We would like to thank you for careful reading of our paper and for the thoughtful comments, which helped to improve the quality of this manuscript. We have carefully considered your comments and have revised the manuscript accordingly. Our responses are given in a point-by-point manner in the attachment of the supplementary of this response.
Yours sincerely
On behalf of authors
Sebastian Schubert
-
AC1: 'Reply on RC1', Sebastian Schubert, 26 May 2026
-
RC2: 'Comment on egusphere-2026-355', Anonymous Referee #2, 09 Apr 2026
I really appreciate the work and effort that the PALM team put into developing such a great model and all the tools that come with PALM. It is great that the palm_csd tool is getting updated with new features that can not only help PALM users, but also help other tool developers, as palm_csd has been the reference tool for PALM static drivers.
My main comments are more about clarification around tool configuration and data availability, as this will help PALM users replicate the examples shown in this paper and utilise palm_csd in their own simulations.
Major comments:
- Data availability: I understand that the authors have provided several links to the data used in this paper in the main text. Can the authors provide a summary of data availability for better accessibility and reproducibility? This will help users replicate and prepare their simulations. The Zenodo link also contains the data used in the code, but I failed to identify which data is used for each case. Please clarify this and point readers to the exact documentation (e.g., README files), and update the documentation, as this is not clear.
- Workflow and folder structure: While I understand palm_csd has been publicly available for many years, the workflow and folder structure are still not clear (especially to new users) by reading the papers and documentation. Can the authors provide a flowchart showing code and folder structures and the recommended workflow? This will help users to learn and pick up the tool quickly. It is also not clear which parameters are available in the configuration file.
- New features: I appreciate the list of new features in Lines 70-85, but could the authors please specify in the manuscript or point to the documentation on how to do these in the updated version? For example, which parameter should the users use for domain rotation? The authors may also want to highlight how the LCZ-based configuration can help set up simulations, particularly in regions without high-quality building data.
Specific comments:
- Line 120-125: for bridges configuration, can the authors please point to vector or raster examples in the Zenodo folder for users to replicate? And from the configuration file I can see the raster and vector files are used directly. Please highlight that with the new features in Line 71 to give readers/users direct information on how to use palm_csd.
- Line 135: “buffer zone” – please clarify how this is done; which parameter controls this in the configuration? Or point readers to the documentation as I struggle to find this information and I would imagine other users have the same problem.
- Line 166: “The input quantities can be specified as a single file or as several vector point files, with the columns representing the respective input data or as separate corresponding raster files.” Similar to my previous comments, please give examples and point to which files users can access to replicate the case discussed here.
- Line 212: “Furthermore, a gradual overlay of the terrain height is applied to avoid sharp gradients at the nest’s boundaries.” Can the authors clarify exactly how this is done?
- Line 245: “In contrast to Demuzere et al. (2022a), the user can choose in (6) between the arithmetic and the geometric mean of building heights.” Which parameter can the users choose? Please clarify.
- Line 258-259: “The input data are freely available from ...”. Please also add this to data availability.
- Lin 265: Follow-up on the previous comment: I understand that the authors have included two data sources, but can the authors specify which website the nDSM and DTM were obtained from? This will help users search their data.
- Line 270-275: I appreciate the detailed pre-processing steps here, but the authors may want to add something like “Similarly, other building parameters can be assigned for the building polygon in QGIS” just so readers without a GIS background could pick up the context easily.
- Line 278: “the land-use data set from ALKIS® (Amtliche Liegenschaftskatasterinformationssystem) is employed”. Please clarify what is ALKIS and is it freely available? If so, please add to the data availability section.
- Figure 6: Please use a colour-blind-friendly palette as the current colours contain red and green in the same figure.
- Figure 7a: Same as Figure 6. A colour-blind-friendly colormap would be preferred, although I understand it could be hard for this particular case.
Citation: https://doi.org/10.5194/egusphere-2026-355-RC2 -
AC2: 'Reply on RC2', Sebastian Schubert, 26 May 2026
Dear Reviewer #2
We would like to thank you for careful reading of our paper and for the thoughtful comments, which helped to improve the quality of this manuscript. We have carefully considered your comments and have revised the manuscript accordingly. Our responses are given in a point-by-point manner in the attachment of the supplementary of this response.
Yours sincerely
On behalf of authors
Sebastian Schubert
Interactive discussion
Status: closed
-
RC1: 'Comment on egusphere-2026-355', Anonymous Referee #1, 03 Apr 2026
Review comments on “palm_csd 25.10: A processing tool for static input data in the PALM model system” submitted to GMD as a model description paper.
This study introduced the new version of the preprocessing program applied to PALM. The novel features described in this study are as follows: processing of georeferenced raster and vector data, including rotation of the domain, enforcing building parameter treatment, optimizing generation of vegetation parameters such as LAI, and non-building resolving simulations based on the LCZ concept. Authors included the trial of the features targeting existing urban areas with some visualizations. The explanation of the features is well organized, thus I recommend a few points to improve the reliability/applicability for possible users.
1. Treatment of Vegetation
Is it possible to test the accuracy of LAI and LAD estimation for the vegetation patch case (shown in 2.3.2)? In my understanding, there are some assumptions or parameterizations (e.g., λ_LAI in equation 2) that have been made to obtain profiles of LAI and LAD values. To present the validation result can be useful to show the robustness of the process that the authors proposed. Additionally, the estimation of vertical profiles of LAD is a little unclear. Both equations (3) and (4) estimate LAD(z), but I cannot understand which value was used. Can users select these two equations for estimation?
2. 2D and 3D building treatment
The authors mentioned the plan to support the 3D building input. I think that it should be helpful to add some explanation of the limitations that users encounter when using 2D data. For example, authors have said that the current version already supports a bridge-like structure, but can the 3D data further support more complicated building shapes? Also, authors mentioned that building parameters can be given for individual buildings and based on a 2D raster, but can the 3D data further support more complicated parameter distribution? Please consider adding an explanation of the current parameter settings provided via 2D building data, especially its limitations, and the future parameter setting plans via 3D building data would be helpful to users.
Minor comments
3. Please consider adding some explanation on residential_1951_2000 at L.115.
4. Please consider adding some explanation on the meaning of _2 adding to the parameter name at L.129. Does it mean the second roof layer?
Citation: https://doi.org/10.5194/egusphere-2026-355-RC1 -
AC1: 'Reply on RC1', Sebastian Schubert, 26 May 2026
Dear Reviewer #1
We would like to thank you for careful reading of our paper and for the thoughtful comments, which helped to improve the quality of this manuscript. We have carefully considered your comments and have revised the manuscript accordingly. Our responses are given in a point-by-point manner in the attachment of the supplementary of this response.
Yours sincerely
On behalf of authors
Sebastian Schubert
-
AC1: 'Reply on RC1', Sebastian Schubert, 26 May 2026
-
RC2: 'Comment on egusphere-2026-355', Anonymous Referee #2, 09 Apr 2026
I really appreciate the work and effort that the PALM team put into developing such a great model and all the tools that come with PALM. It is great that the palm_csd tool is getting updated with new features that can not only help PALM users, but also help other tool developers, as palm_csd has been the reference tool for PALM static drivers.
My main comments are more about clarification around tool configuration and data availability, as this will help PALM users replicate the examples shown in this paper and utilise palm_csd in their own simulations.
Major comments:
- Data availability: I understand that the authors have provided several links to the data used in this paper in the main text. Can the authors provide a summary of data availability for better accessibility and reproducibility? This will help users replicate and prepare their simulations. The Zenodo link also contains the data used in the code, but I failed to identify which data is used for each case. Please clarify this and point readers to the exact documentation (e.g., README files), and update the documentation, as this is not clear.
- Workflow and folder structure: While I understand palm_csd has been publicly available for many years, the workflow and folder structure are still not clear (especially to new users) by reading the papers and documentation. Can the authors provide a flowchart showing code and folder structures and the recommended workflow? This will help users to learn and pick up the tool quickly. It is also not clear which parameters are available in the configuration file.
- New features: I appreciate the list of new features in Lines 70-85, but could the authors please specify in the manuscript or point to the documentation on how to do these in the updated version? For example, which parameter should the users use for domain rotation? The authors may also want to highlight how the LCZ-based configuration can help set up simulations, particularly in regions without high-quality building data.
Specific comments:
- Line 120-125: for bridges configuration, can the authors please point to vector or raster examples in the Zenodo folder for users to replicate? And from the configuration file I can see the raster and vector files are used directly. Please highlight that with the new features in Line 71 to give readers/users direct information on how to use palm_csd.
- Line 135: “buffer zone” – please clarify how this is done; which parameter controls this in the configuration? Or point readers to the documentation as I struggle to find this information and I would imagine other users have the same problem.
- Line 166: “The input quantities can be specified as a single file or as several vector point files, with the columns representing the respective input data or as separate corresponding raster files.” Similar to my previous comments, please give examples and point to which files users can access to replicate the case discussed here.
- Line 212: “Furthermore, a gradual overlay of the terrain height is applied to avoid sharp gradients at the nest’s boundaries.” Can the authors clarify exactly how this is done?
- Line 245: “In contrast to Demuzere et al. (2022a), the user can choose in (6) between the arithmetic and the geometric mean of building heights.” Which parameter can the users choose? Please clarify.
- Line 258-259: “The input data are freely available from ...”. Please also add this to data availability.
- Lin 265: Follow-up on the previous comment: I understand that the authors have included two data sources, but can the authors specify which website the nDSM and DTM were obtained from? This will help users search their data.
- Line 270-275: I appreciate the detailed pre-processing steps here, but the authors may want to add something like “Similarly, other building parameters can be assigned for the building polygon in QGIS” just so readers without a GIS background could pick up the context easily.
- Line 278: “the land-use data set from ALKIS® (Amtliche Liegenschaftskatasterinformationssystem) is employed”. Please clarify what is ALKIS and is it freely available? If so, please add to the data availability section.
- Figure 6: Please use a colour-blind-friendly palette as the current colours contain red and green in the same figure.
- Figure 7a: Same as Figure 6. A colour-blind-friendly colormap would be preferred, although I understand it could be hard for this particular case.
Citation: https://doi.org/10.5194/egusphere-2026-355-RC2 -
AC2: 'Reply on RC2', Sebastian Schubert, 26 May 2026
Dear Reviewer #2
We would like to thank you for careful reading of our paper and for the thoughtful comments, which helped to improve the quality of this manuscript. We have carefully considered your comments and have revised the manuscript accordingly. Our responses are given in a point-by-point manner in the attachment of the supplementary of this response.
Yours sincerely
On behalf of authors
Sebastian Schubert
Peer review completion
Journal article(s) based on this preprint
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 1,060 | 598 | 73 | 1,731 | 101 | 128 |
- HTML: 1,060
- PDF: 598
- XML: 73
- Total: 1,731
- BibTeX: 101
- EndNote: 128
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
Discussed
Sebastian Schubert
Julian Anders
Tobias Gronemeier
Björn Maronga
Mohamed Salim
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
- Preprint
(7469 KB) - Metadata XML
Review comments on “palm_csd 25.10: A processing tool for static input data in the PALM model system” submitted to GMD as a model description paper.
This study introduced the new version of the preprocessing program applied to PALM. The novel features described in this study are as follows: processing of georeferenced raster and vector data, including rotation of the domain, enforcing building parameter treatment, optimizing generation of vegetation parameters such as LAI, and non-building resolving simulations based on the LCZ concept. Authors included the trial of the features targeting existing urban areas with some visualizations. The explanation of the features is well organized, thus I recommend a few points to improve the reliability/applicability for possible users.
1. Treatment of Vegetation
Is it possible to test the accuracy of LAI and LAD estimation for the vegetation patch case (shown in 2.3.2)? In my understanding, there are some assumptions or parameterizations (e.g., λ_LAI in equation 2) that have been made to obtain profiles of LAI and LAD values. To present the validation result can be useful to show the robustness of the process that the authors proposed. Additionally, the estimation of vertical profiles of LAD is a little unclear. Both equations (3) and (4) estimate LAD(z), but I cannot understand which value was used. Can users select these two equations for estimation?
2. 2D and 3D building treatment
The authors mentioned the plan to support the 3D building input. I think that it should be helpful to add some explanation of the limitations that users encounter when using 2D data. For example, authors have said that the current version already supports a bridge-like structure, but can the 3D data further support more complicated building shapes? Also, authors mentioned that building parameters can be given for individual buildings and based on a 2D raster, but can the 3D data further support more complicated parameter distribution? Please consider adding an explanation of the current parameter settings provided via 2D building data, especially its limitations, and the future parameter setting plans via 3D building data would be helpful to users.
Minor comments
3. Please consider adding some explanation on residential_1951_2000 at L.115.
4. Please consider adding some explanation on the meaning of _2 adding to the parameter name at L.129. Does it mean the second roof layer?