the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
The Western United States Large Forest-Fire Stochastic Simulator (WULFFSS) 1.0: A monthly gridded forest-fire model using interpretable statistics
Abstract. We developed WULFFSS, a new stochastic monthly gridded forest-fire model for the western United States (US). Operating at 12-km resolution, WULFFSS calculates monthly probabilities of forest fires ≥100 ha and area burned per fire. The model is forced by variables related to vegetation, topographic, anthropogenic, and climate factors, organized into three indices representing spatial, annual-cycle, and lower frequency temporal domains. These indices can interact, so variables promoting fire in one domain amplify fire-promoting effects in another. Fire probability and size models use multiple logistic and linear regression, respectively, and can be easily updated as new data or ideas emerge. During its training period of 1985–2024, WULFFSS captures 72 % and 83 % of observed interannual variability in western US forest-fire frequency and area, respectively. It reproduces regional differences in seasonal timing, frequencies, and sizes of fires, and performs well in cross-validation exercises that test the model’s accuracy in years or regions not considered during model training. While lacking fine-scale fire dynamics, WULFFSS’ use of classic statistics promotes interpretability and efficient ensemble generation. Designed to run within a vegetation ecosystem model, bidirectional feedbacks between vegetation and fire can identify how ecosystem changes have altered or will alter fire-climate relationships across the western US. The model's predictive power should improve with increasingly accurate and extensive observational data, and its approach can be extended to other regions. Here we provide a thorough description of the WULFFSS model, including the motivation underlying its development, caveats to our approach, and areas for future improvement.
- Preprint
(2836 KB) - Metadata XML
-
Supplement
(183 KB) - BibTeX
- EndNote
Status: open (until 03 Sep 2025)
-
CEC1: 'Comment on egusphere-2025-2934 - No compliance with the policy of the journal', Juan Antonio Añel, 25 Jul 2025
reply
Dear authors,
Unfortunately, after checking your manuscript, it has come to our attention that it does not comply with our "Code and Data Policy".
https://www.geoscientific-model-development.net/policies/code_and_data_policy.htmlYou have deposited the code and data relative to your manuscript in datadryad.org, which is an acceptable repository. However, you have shared both of them only with the editors and reviewers, and we can not accept this. Our policy clearly states that all the assets must be published without restrictions at the time of submitting a manuscript to the journal. Only in very specific cases, and with a proper justification, we can accept that the code and data are restricted to the readership of the journal, as they must be public so that anyone wanting to contribute to Discussions has access to them.
Therefore, please, remove all the restrictions for the access to the code and data used in your manuscript, and reply to this comment, as soon as possible, confirming it.
Also, I have checked the repository for the code, and I have seen that it does not include a license. If you do not include a license, the code remains your property and nobody can use it. Therefore, please, add a license to the repository with your code. You could want to choose a free software/open-source (FLOSS) license: for example, GPLv3, GPLv2, Apache License, MIT License, etc.
Additionally, it seems that you have developed your model in using the M language, and using the proprietary interpreter Matlab. As it is well known, the company distributing Matlab does not assure compatibility between versions of their interpreter. Therefore, to assure the replicability of your work, specify in any future version of your manuscript the version number of the Matlab interpreter that you have used. Also, it would be good if you clarify if your model can be run using the M Language free interpreter, Octave.
I must note that if you do not fix the above mentioned issues, we could not continue with the peer-review process or accept your manuscript for publication in our journal.
Juan A. Añel
Geosci. Model Dev. Executive EditorCitation: https://doi.org/10.5194/egusphere-2025-2934-CEC1 -
AC1: 'Reply on CEC1', A. Park Williams, 25 Jul 2025
reply
Dear Dr. Añel,
Thank you for the time and thought you put into checking over our manuscript. We are enthusiastic to address the issues you raise as soon as possible and move along with the review process. Our detailed responses to your concerns are below, but in short:
To have our data published with a DOI and not simply in peer-review mode we believe that we will need to submit a revised manuscript with an updated url in the “Code and data availability” section. We also believe our model code will be given a different DOI from the data so that we can put the code under a license, in which case we will add a second url to the “Code and data availability” section. However, we’re unsure if we are permitted by GMD to submit a revised manuscript along with our reply, and in any case it will likely take a number of days for our data and code archival to be approved by Dryad/Zenodo and assigned permanent DOIs.
If you could please advise as to how to proceed that would be much appreciated. That is, should we submit a revised manuscript with the updated URLs for the data and code archives once those are available, and if so can GMD please initiate that? Or should we wait and do this after the first round of reviews?
If it’s helpful, we would like to point out that anybody (not only editors and reviewers) can access the data and code we archived on Dryad using the peer-review url that we provided in the “Code and data availability” section of our original submission.
Thank you again for your time.
Sincerely,
Park WilliamsEditor: You have deposited the code and data relative to your manuscript in datadryad.org, which is an acceptable repository. However, you have shared both of them only with the editors and reviewers, and we can not accept this. Our policy clearly states that all the assets must be published without restrictions at the time of submitting a manuscript to the journal. Only in very specific cases, and with a proper justification, we can accept that the code and data are restricted to the readership of the journal, as they must be public so that anyone wanting to contribute to Discussions has access to them.
Therefore, please, remove all the restrictions for the access to the code and data used in your manuscript, and reply to this comment, as soon as possible, confirming it.
Authors: We apologize our confusion. We thought we had adhered to policy because the url that we provided in the “Code and data availability” will allow anybody to be able to access our model data and code. However, we overlooked the policy stating “Where code and data change during the revision process of the manuscript, the updated versions must also be archived. Authors must take care that the results in revised manuscripts are correctly associated with the corresponding archived data (with different DOIs referenced in the submitted and final manuscripts in cases where data have changed).” As we understand it, this is not possible when the data are posted in Dryad’s peer-review mode (peer review model allows for revision of the data/code without archival of previous versions). We will therefore publish the model and code so that a DOI is assigned and will revise the “Code and data availability” section of the paper accordingly.
Editor: Also, I have checked the repository for the code, and I have seen that it does not include a license. If you do not include a license, the code remains your property and nobody can use it. Therefore, please, add a license to the repository with your code. You could want to choose a free software/open-source (FLOSS) license: for example, GPLv3, GPLv2, Apache License, MIT License, etc.
Authors: Thank you for pointing this out. After some research, we see that Dryad’s policy is that all data deposited on Dryad must comply with a CCO license waiver (https://creativecommons.org/publicdomain/zero/1.0/), meaning that the data should not need to be associated with a license on Dryad. The Dryad policy can be found here: https://datadryad.org/requirements.
However, we were unclear on how Dryad’s policy pertains to code. To avoid confusion, we now use Zenodo, via Dryad, to share our code under the GNUv3 license. When we publish our dataset via Dryad we believe the code will automatically be assigned a DOI via Zenodo and if we update our model/code during the peer review process then Zenodo will automatically update the DOI and archive the older version(s).
Editor: Additionally, it seems that you have developed your model in using the M language, and using the proprietary interpreter Matlab. As it is well known, the company distributing Matlab does not assure compatibility between versions of their interpreter. Therefore, to assure the replicability of your work, specify in any future version of your manuscript the version number of the Matlab interpreter that you have used. Also, it would be good if you clarify if your model can be run using the M Language free interpreter, Octave.
Thank you for pointing this out. We will update the next manuscript version to specify that all of our code was executed using Matlab 2024a. While the paper is in peer review we will determine if our code can be run using Octave.
Citation: https://doi.org/10.5194/egusphere-2025-2934-AC1 -
CEC2: 'Reply on AC1', Juan Antonio Añel, 27 Jul 2025
reply
Dear authors,
First, you must reply to this comment with the DOI and link for the repositories containing the code and data. It is not necessary that you submit a new manuscript at the moment. Publishing the information here is enough to make it available to anyone that is interested on it.
Also, thanks for addressing the issues with the license.
Regarding the Matlab version, R2024a is the name of the release not the version number. The corresponding version number is 24.1 (https://www.mathworks.com/support/requirements/previous-releases.html)
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2025-2934-CEC2 -
AC2: 'Reply on CEC2', A. Park Williams, 02 Aug 2025
reply
Thank you. The dataset has now been published publicly at https://doi.org/10.5061/dryad.63xsj3vdb
The code is published publicly at https://doi.org/10.5281/zenodo.16423649
Citation: https://doi.org/10.5194/egusphere-2025-2934-AC2
-
AC2: 'Reply on CEC2', A. Park Williams, 02 Aug 2025
reply
-
CEC2: 'Reply on AC1', Juan Antonio Añel, 27 Jul 2025
reply
-
AC1: 'Reply on CEC1', A. Park Williams, 25 Jul 2025
reply
-
RC1: 'Comment on egusphere-2025-2934', Anonymous Referee #1, 28 Aug 2025
reply
Summary:
This paper introduces WULFFSS, a newly developed statistical model designed to simulate the monthly probability and size of large forest fires (size ≥100 ha) across the western US, on a 12-km spatial resolution. The modeling framework consists of 3 statistical models that are called stepwise, forced by climate, vegetation, topographic, and anthropogenic variables. Two of the three models each consist of three components representing different groups of predictor variables, as well as interactions in between them. The modeling framework features its stochastic nature and interpretability, and computational efficiency. The framework is designed to be couple with forest ecosystem model (such as DYNAFFOREST) to allow bidirectional feedbacks between the vegetation and fire events. The application of the framework for 1985-2024 is able to capture the majority interannual variability of forest fires in the studied western US with some limitation.
Comments:
The authors did a good job in building the statistical modeling framework to estimate fire probability and sizes in western US from multiple influencing groups of variables. Allowing the model to couple with an forest ecosystem model for feedbacks indeed promotes its future potential. However, there are questions about methodological choices and performance analysis that further explanation needs to be made to clarify the robustness of this paper.
1. The modeling framework consists of three stepwisely connected statistical models, how sensitive is the final simulation to the prior step variables?
2. For model P and A, each consists of the three component groups of predictor variables. The variables are categorized into spatial, annual cycle and temporal domains to be examined. This is quite different from the more conventional method. Why took this approach, instead of treating all predictors in the same single pool? Is there quantitative consideration that the three-domain method better than the standard multi-variable regression?
3. When presenting the landcover data in the model, the author uses 41 grid cells from 8 directions surrounding the target grid cell to calculate the forest connectivity. Is there specific reason how the chosen area (or, the number of the grid cells) is set?
4. When introducing the human factor in the model, the author uses population density and distance to road, as predictors. Could the author please explain why some other widely used predictors, such as GDP or fire agency availability, are not included in the domain, relating to suppression capability?
5. The model yields quite good simulations for the other regions in the western US, yet it evidently underperforms in the CA/NV region on both annual frequency and forest area burned (Fig. 16d and Fig. 17d). Apart from the potential reasons listed, did author analyse as to where the discrepancy comes from, was it mainly caused by ignition probability, or together with fire size? What is the dominant driver for this bias?
6. The model significantly underestimates the extreme fire events in year 2020 and 2024 (in terms of fire size), does this imply that the model systematically lack the ability to capture fire events induced by extreme weather conditions accurately? Can author suggest ways to improve this?
7. By introducing self-regulation effect that reduces fuels from previous fires, will this “saturation” effect limit the model performance in future projection, considering that the climate change and ecosystem feedbacks may alter its self-regulation point?Citation: https://doi.org/10.5194/egusphere-2025-2934-RC1
Viewed
HTML | XML | Total | Supplement | BibTeX | EndNote | |
---|---|---|---|---|---|---|
648 | 94 | 14 | 756 | 21 | 8 | 27 |
- HTML: 648
- PDF: 94
- XML: 14
- Total: 756
- Supplement: 21
- BibTeX: 8
- EndNote: 27
Viewed (geographical distribution)
Country | # | Views | % |
---|
Total: | 0 |
HTML: | 0 |
PDF: | 0 |
XML: | 0 |
- 1