the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 29 Dec 2025
Development of ACFIRE version 1.0: A mesoscale model with forest canopy and fire behavior submodels
Abstract. Numerical models are essential for advancing understanding of fire–atmosphere interactions, especially where field campaigns alone cannot provide sufficient insight. Existing wildland fire models vary greatly in complexity and scale, from computational fluid dynamics models with detailed combustion submodels, to mesoscale models with empirical or semi-empirical combustion representations, to global or regional models that omit combustion byproducts altogether. However, no current framework simultaneously resolves atmospheric responses to wildland fires across scales from hundreds of meters to hundreds of kilometers, incorporates a comprehensive suite of physical parameterizations, and explicitly resolves some scales of atmospheric turbulence within and above a forest canopy. To address this gap, we introduce ARPS-CANOPY/DEVS-FIRE (hereafter, ACFIRE), a mesoscale model that integrates a canopy resolving atmospheric model (ARPS-CANOPY) with a fire behavior model (DEVS-FIRE), and detail its development and preliminary evaluation. Unlike the original ARPS-CANOPY, which relied on a user-imposed fire heat source, ACFIRE employs two-way fire-atmosphere coupling to compute heat release dynamically. We demonstrate the coupled modeling system with a low-intensity prescribed fire conducted in the New Jersey Pine Barrens in March 2019, comparing simulated fire spread rates with measurements from an array of surface thermocouples deployed during the fire. The simulated spread rates compare favorably to observed spread rates, with differences mainly attributable to the use of uniform fuels in the ACFIRE simulation. The integration of the dynamically coupled fire heat source represents a significant advance in canopy-resolving mesoscale modeling, and beyond this case, highlights the potential of ACFIRE to extend the application of atmosphere-fire models to a broader range of wildland fire research questions as well as future operational use.
- Preprint
(9927 KB) - Metadata XML
-
Supplement
(22555 KB) - BibTeX
- EndNote
Status: final response (author comments only)
-
CEC1: 'Comment on egusphere-2025-5863 - No compliance with the policy of the journal', Juan Antonio Añel, 07 Jan 2026
-
AC1: 'Reply on CEC1', Shiyuan Zhong, 12 Jan 2026
Dear Chief Editor,
Thank you for your detailed clarification regarding GMD’s Code and Data Policy. We would like to seek clarification on whether making an executable version of the ACFIRE model publicly available would be considered acceptable under the policy. The ACFIRE model is built on top of DEVS-FIRE, which in turn depends on DEVSJAVA, a framework copyrighted by the University of Arizona. Due to licensing restrictions associated with DEVSJAVA, we are not able to make the full source code of DEVS-FIRE publicly available. As a result, this limitation also affects the distribution of ACFIRE source code. Under these constraints, we can provide a publicly accessible executable version of the ACFIRE model, along with sufficient documentation to allow users to run the model and reproduce the results presented in the manuscript. We would appreciate your guidance on whether this level of access would satisfy GMD’s requirements for code availability during the discussion and review process, or whether full source-code publication is strictly required.
Thank you for your time and consideration. We look forward to your advice on how best to proceed.
Sincerely,
Sharon Zhong,
on behalf of the authors
Citation: https://doi.org/10.5194/egusphere-2025-5863-AC1 -
CEC2: 'Reply on AC1', Juan Antonio Añel, 12 Jan 2026
Dear authors,
Executable packages that do not allow to see and check the code of a software do not comply with the requirements of the journal, as they do not allow to review the code, which is equivalent to reviewing the methods.
In your reply you state that "licensing restrictions associated with DEVSJAVA" prevent you of publishing the DEVS-FIRE AND AC-FIRE source code. To decide if we can accept them as an exception to our policy, we need to know which are the mentioned licensing issues, have access to the license, how they affect by inheritance of licensing properties to the DEVS-FIRE and AC-FIRE licenses, and to also who makes the decision on such license. For example, you need to demonstrate that none of the authors have the capability to influence on the decision of the license used and that does not allow sharing the code, and that such license has been imposed by an authority, law or regulation that forbids you (the authors of the paper) to publish the code. Otherwise, it is requested that you make public the code without restrictions or limitations to accept your manuscript for peer-review in GMD.
I hope this makes clearer the situation.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2025-5863-CEC2 -
AC2: 'Reply on CEC2', Shiyuan Zhong, 12 Jan 2026
Dear Chief Editor,
Thank you again for your prompt response and for your detailed explanation the conditions under which exceptions to GMD’s Code and Data Policy may be considered. This is very helpful.
We would like to clarify the current situation regarding licensing and our ability to release the source code for DEVS-FIRE and AC-FIRE. DEVS-FIRE is built on top of DEVSJAVA, which is copyrighted by the University of Arizona. Our understanding is that the DEVSJAVA license does not currently permit redistribution of derivative source code without explicit permission from the copyright holder. Because DEVS-FIRE inherits core components and architectural elements from DEVSJAVA, this restriction propagates to DEVS-FIRE and, by extension, to AC-FIRE, which is a module developed on top of DEVS-FIRE. Importantly, the licensing terms for DEVSJAVA were not determined by the authors of this manuscript, and none of the authors have the authority to modify or override those terms. The decision regarding the DEVSJAVA license rests entirely with the University of Arizona as the copyright holder. As such, our current inability to publish the source code is not a matter of author preference, but rather a consequence of third-party copyright and licensing constraints.
Following your guidance, we have now initiated contact with the University of Arizona to formally request permission to release the relevant source code in a public repository. In parallel, we would appreciate clarification from GMD on the specific licensing requirements expected for code publication associated with a journal article (e.g., whether a particular open-source license is required or recommended). This information is necessary for us to assess the implications for DEVS-FIRE and to clearly communicate the journal’s requirements to the University of Arizona as part of our permission request. Once we receive clarification on the required license terms and a response from the University of Arizona, we will be in a better position to determine whether full compliance with GMD’s policy is feasible. We will, of course, report back promptly with any updates.
Thank you again for your time and for outlining the policy requirements clearly.
Sincerely,
Dr. Sharon Zhong, on behalf of all authors
Citation: https://doi.org/10.5194/egusphere-2025-5863-AC2 -
CEC3: 'Reply on AC2', Juan Antonio Añel, 13 Jan 2026
Dear authors,
Thanks for your reply. I would like to insist on the fact that copyright and licensing are different issues. The University of Arizona could be the owner of the copyright of DEVSJAVA, and at the same time to be perfectly allowed to distribute the code. In this regard, please share the DEVSJAVA license, so we can judge better.
Also, the fact that DEVS-FIRE and AC-FIRE are build on top of DEVSJAVA does not necessarily affects them. This is exactly why we need the terms of the DEVSJAVA license, to check it. Actually, unless the DEVSJAVA license contains a "viral" clause, something quite uncommon, you can publish the DEVS-FIRE and AC-FIRE codes, as it seems clear that you have developed them.
The journal does not recommend a specific license to be used. However, the policy of the journal, which I have linked in my first comment, mentions as examples the GPL or MIT licenses.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2025-5863-CEC3 -
AC3: 'Reply on CEC3', Shiyuan Zhong, 14 Jan 2026
Dear Chief Editor,
We have had extensive discussions with the Georgia State University tech transfer office and have reviewed the attached DEVSJAVA copyright form from the University of Arizona. The license we hold permits use of DEVSJAVA solely for educational and research purposes and explicitly prohibits further distribution.
Please review the attached license and let us know whether it would be sufficient to allow the DEVS-FIRE code to be made available for review, even though DEVSJAVA itself cannot be distributed. We truly wish to publish this article in your journal, which provides the ideal audience for our work.
We apologize for the length of this discussion and greatly appreciate your patience and guidance throughout the process.
-
CEC4: 'Reply on AC3', Juan Antonio Añel, 15 Jan 2026
Dear authors,
From the license form you have attached, it is quite obvious that it does not impose any restriction on additional software or code developed on top of DEVSJAVA. Therefore, you must publish and share the DEVSFIRE and AC-FIRE codes following the policy of the journal. Please, read it for a list of acceptable repositories and requirements, and reply to this comment with their links and DOIs. Also, remember that you will have to modify your manuscript accordingly in the future (including the same information in the Code and Data Availability section of the manuscript) if the Topical Editor decides to move ahead in the review process or accept the manuscript for publication.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2025-5863-CEC4 -
EC1: 'Reply on CEC4', Chiel van Heerwaarden, 15 Jan 2026
I would like to learn as soon as possible whether this is possible, to avoid letting people review a paper that won't be published. Thanks!
Citation: https://doi.org/10.5194/egusphere-2025-5863-EC1 -
AC5: 'Reply on EC1', Shiyuan Zhong, 15 Jan 2026
Dear Dr. van Heerwaarden,
As noted in our response to the Chief Editor’s comment, the issue has now been resolved, and we have uploaded all related materials, including all source codes, to the same data archive under the same DOI.
We sincerely apologize for the delay and for any inconvenience this process may have caused. We look forward to receiving the reviewers’ comments in due course.
Thank you again for your time and consideration!
Dr. Sharon Zhong (on behalf of all co-authors)
Citation: https://doi.org/10.5194/egusphere-2025-5863-AC5
-
AC5: 'Reply on EC1', Shiyuan Zhong, 15 Jan 2026
-
AC4: 'Reply on CEC4', Shiyuan Zhong, 15 Jan 2026
Dear Chief Editor,
Thank you for pointing this out and for your careful review of the license language. We have been able to resolve the issue and have now uploaded all relevant materials, including the DEVS-FIRE and AC-FIRE codes, to the same data archive under the same DOI. The repository link and DOI are therefore unchanged. We understand that the manuscript will need to be updated accordingly, and we will revise the Code and Data Availability section in the future, should the Topical Editor decide to move the paper forward in the review process or toward acceptance.
Thank you very much again for your guidance and for helping us ensure compliance with the journal’s policy!
Dr. Sharon Zhong (on behalf of all authors)
Citation: https://doi.org/10.5194/egusphere-2025-5863-AC4 -
CEC5: 'Reply on AC4', Juan Antonio Añel, 16 Jan 2026
Dear authors,
Many thanks for addressing this issue. We can consider now the current version of your manuscript in compliance with the code and data policy of the journal.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2025-5863-CEC5
-
CEC5: 'Reply on AC4', Juan Antonio Añel, 16 Jan 2026
-
EC1: 'Reply on CEC4', Chiel van Heerwaarden, 15 Jan 2026
-
CEC4: 'Reply on AC3', Juan Antonio Añel, 15 Jan 2026
-
AC3: 'Reply on CEC3', Shiyuan Zhong, 14 Jan 2026
-
CEC3: 'Reply on AC2', Juan Antonio Añel, 13 Jan 2026
-
AC2: 'Reply on CEC2', Shiyuan Zhong, 12 Jan 2026
-
CEC2: 'Reply on AC1', Juan Antonio Añel, 12 Jan 2026
-
AC1: 'Reply on CEC1', Shiyuan Zhong, 12 Jan 2026
-
RC1: 'Comment on egusphere-2025-5863', Anonymous Referee #1, 18 Feb 2026
This study reviews existing fire behavior and canopy-flow modeling frameworks and clearly articulates the need for coupled fire–atmosphere modeling. This newly developed ACFIRE system demonstrates overall encouraging agreement with observations from the prescribed burn in simulating fire spread dynamics. The manuscript is well organized and suitable for GMD. The following clarifications would strengthen the interpretation of the coupled framework.
- Clarification regarding the underlying assumptions for ACFIRE simulation inherited from ARPS-CANOPY (e.g., neutral stratification) and DEVS-FIRE (e.g., Rothermel’s equations and elliptical spread assumptions) will be great. When these components are integrated into the coupled ACFIRE framework, do these assumptions still hold? If certain assumptions are violated under strong fire-induced buoyancy and evolving stability conditions, how do such departures influence the physical interpretation and reliability of the simulated atmosphere–fire interactions?
- Line 203: Please clarify how the chosen ASCII-file communication interval compares with the relevant turbulence and combustion timescales, and whether it introduces temporal lag that may affect two-way coupling accuracy. Guidance on selecting appropriate intervals under different environmental conditions would be helpful.
- Line 290: Does the bias-correction factor address model structural bias within ARPS-CANOPY, or does it compensate for observational and post-processing uncertainties?
Citation: https://doi.org/10.5194/egusphere-2025-5863-RC1 -
RC2: 'Review of egusphere-2025-5863', Anonymous Referee #2, 12 Aug 2026
Review of "Development of ACFIRE version 1.0: A mesoscale model with forest canopy and fire behavior submodels" by Kiefer et al., submitted to GMD.
I think fire spread modelling with a resolved canopy is a promising direction and there is real potential in what is presented here. The authors are also very fair about where the model falls short, which I appreciate.
In my view the manuscript could improve with a more thorough evaluation of what is really new. What is new in ACFIRE is the dynamically computed heat source sitting inside a canopy-resolving atmospheric model. What is evaluated is fire arrival time, which is the DEVS-FIRE side. The atmosphere is never compared with observations, even though the tower data exist and were used for exactly this case in Kiefer et al. (2022). Alongside that, I could not work out from the text what wind actually reaches the Rothermel equations, because I could not find the WAF used in the simulation, nor the fuel moisture, and there is then a further factor of 0.7 on top.
I recommend major revisions. In order of what I think matters most:
1. Compare the fire-perturbed atmosphere with the six SERDP towers, against the Kiefer et al. (2022) imposed-heat-source results.
2. Show what the canopy sub-model buys you: ACFIRE versus plain ARPS/DEVS-FIRE, same case.
3. Document the wind chain properly (which WAF and what value, fuel moisture, and the origin of the 0.7).
4. Say something about where crown fire could come from in this framework.
General comments
1. The atmosphere is not evaluated.
Six instrumented flux towers were deployed during this burn (Sect. 3). Kiefer et al. (2022) used them to evaluate ARPS-CANOPY driven by a prescribed heat source. ACFIRE replaces that prescribed source with a computed one. So the question the paper is set up to answer is whether the computed source does at least as well at the towers as the imposed one did, and that comparison is simply absent. Section 5 is arrival times plus a narrative reading of the wind vectors in Figs. 3-8.
I would add that the Short Summary claims the system reproduces "fire spread and the resulting atmospheric changes". Nothing in the manuscript supports the second half until a comparison with the tower data is done.
2. The 0.7 factor.
Sect. 4.1, l. 290-295. The 6-m winds are multiplied by 0.7 before they reach DEVS-FIRE, to compensate a lower-canopy wind overestimate at the control tower. I appreciate that this is flagged as case-specific and that the factor comes from a wind comparison rather than from tuning against spread rate. Two things, however, should be addressed.
Fuel moisture is not stated anywhere in the manuscript. In a Rothermel model, moisture and mid-flame wind are the two knobs that matter, and their effects on rate of spread are hard to tell apart. Cutting the wind by 30% while leaving the moisture unspecified means a reader cannot judge whether the correction is fixing a wind problem or absorbing a moisture problem. Please give the values, the source, and whether they varied in time.
The justification is that the correction brings spread rates "more in line with fire-tracker observations" (l. 294-295). But observed rates span 0.4-6.6 m/min and the corrected simulation gives 2.3-3.7 m/min (l. 358-359). Remove the correction and you get roughly 3.4-5.5 m/min, which is also inside the observed range. So the stated evidence does not really distinguish the two runs.
Underneath this discussion there might be also some very interesting information. If ARPS-CANOPY systematically overestimates lower-canopy wind at this site, that is a finding about the canopy sub-model, and it would be very useful to the community.
3. The WAF does not fit a canopy-resolving model, and the value used is unclear.
Sect. 1.1 (l. 104-105) says, correctly, that the WAF scales wind at 6 m above *vegetation cover*. Sect. 2.4 (l. 234-235) then hands DEVS-FIRE a wind at 6 m *above ground*, which here is well inside a 12-24 m canopy. The manuscript slides between the two as if they were the same height. I would appreciate if the authors clarify this.
On the value: l. 109 gives 0.4 as the WAF for standard fuel model 7, and fuel model 7 is what the simulation uses (l. 306), so a reader can piece it together. But this appears in the Sect. 1.1 background as an illustration of the Albini-Baughman technique, and Sect. 4.1 never states the WAF actually applied in the run. Please state it explicitly in Sect. 4.1, along with which of the WAF classes of l. 110-112 it belongs to.
That last point matters more than it may seem. I understand the argument at l. 215-217, that the drag terms take care of overstory sheltering and the WAF is left to handle only the log profile below 6 m. That argument is self-consistent only if the WAF used is the *unsheltered* one, since the sheltered values already fold in overstory sheltering and would double-count against the drag terms. l. 110-112 says only unsheltered and partially sheltered WAFs are applied in models of this class, and 0.4 is the unsheltered tabulated value for fuel model 7, so I assume no double-counting occurs here. But the manuscript leaves this to inference, and a partially sheltered WAF would break the argument.
Related, and worth a comment from the authors: if the sheltering split is clean, why was a further 30% wind reduction needed on top of it (l. 290-292)? Either the 6-m wind entering the chain is genuinely biased high, in which case general comment 2 applies, or something in the sheltering split is not doing what is intended.
4. At 30 m, the canopy turbulence is not resolved.
The third selling point of ACFIRE is "the capability of explicitly resolving some scales of atmospheric turbulence within and above a forest canopy" (Sect. 1.2, l. 136-137; repeated in Sect. 6, l. 466-468; the abstract, l. 19-20, has the same claim as "explicitly resolves some scales of atmospheric turbulence within and above a forest canopy"). The demonstration runs at 30 m horizontal spacing, which exceeds the canopy height everywhere in the burn unit (12-24 m, l. 303). Canopy shear-layer eddies scale with about twice the canopy height, so 24-48 m here. The authors themselves report resolved eddies at about 100 m, i.e. 3dx (l. 386-390), and 3dx is where the numerics dissipate, not where turbulence lives.
I appreciate that "some scales of" is a deliberate hedge, and that l. 387-390 is clear about what 30-m spacing implies. But the hedge does not distinguish which scales, and the claim sits in a sentence about turbulence "within and above a forest canopy". What this configuration actually resolves is convective boundary-layer eddies above the canopy, with the in-canopy turbulence parameterised through the drag and TKE terms. That is a reasonable thing to do and it is still an advance on a bulk canopy. It is however not in-canopy turbulence resolution. The authors do list 1-m spacing as future work (l. 486), but I would ask that the abstract and Sect. 1.2 say explicitly that in the configuration demonstrated here the resolved scales lie above the canopy, as l. 387-390 already concedes.
5. The evaluation is a bit thin.
The evaluation is based on a single case with low intensity. The comparison is an isochrone overlay, a spread-rate range (l. 358-359), a transit time (l. 351-352) and a five-minute arrival difference at the northeastern perimeter (l. 442-444). What is missing is any error statistic: no RMSE on arrival time at the tracker locations, no burned-area overlap. The fire-tracker array gives point arrival times across the unit, which is exactly the sort of data that supports a number rather than a range.
On the fuels: I accept that gridded 3-m fuels do not exist and that uniform fuel model 7 is a defensible fallback. However, the overstory is heterogeneous and is represented as such, Ap per grid point from LiDAR. Sect. 6 (l. 482-483) describes the unit as having "generally horizontally homogeneous fuels and forest overstory vegetation", and the second half of that contradicts Fig. 1 and l. 302-303, where PAI across the burn unit runs from 0.2 to 1.5 and canopy height from 12 to 24 m. This is worth fixing, because the model has the overstory variability and still misses the unburned islands. Since you note (l. 363-365) that the islands seem to sit over shorter, thinner vegetation, why not plot arrival time against PAI or canopy height?
On attribution: the abstract says differences are "mainly attributable to the use of uniform fuels" (l. 26-27). Sect. 5 offers three candidates, uniform fuels, unresolved eddies, and interpolation smoothing (l. 391-394), and no experiment separates them.
Finally, and I think this is the cheapest high-value experiment available: run the same case with plain ARPS/DEVS-FIRE, bulk canopy, and show the difference. The paper currently does not demonstrate that the canopy sub-model changes the fire at all. If it does, that is the paper's best argument.
6. The coupling claim, and crown fire.
To be clear, the body of the paper is honest about this. Sect. 2.3 (l. 186-188) and Sect. 4.1 (l. 311-313) both say DEVS-FIRE cannot do crown fire, and Sect. 4.1 states plainly that the ARPS-CANOPY vegetation does not burn and Ap is static. Good. (One correction: l. 313 points the reader to "Sects. 2.3-2.4", but Sect. 2.4 does not mention crown fire at all. Either cite Sect. 2.3 alone or add the restriction to Sect. 2.4.)
The abstract and Short Summary do not say any of it. "Simulates how wildfire and forest canopies interact" will be read as torching and crowning. What actually happens is that the fire heats the near-surface air, the perturbed 6-m wind feeds back into surface spread, and a fixed drag field modulates that wind. Put the surface-fire restriction in the abstract.
Related: I would like a paragraph in Sect. 6 on what a route to crown fire would look like here. With the fuel bed and the canopy specified independently and Ap held static, coupling them is not a minor change, and the authors know better than anyone what it would take.
Citation: https://doi.org/10.5194/egusphere-2025-5863-RC2
Viewed
| HTML | XML | Total | Supplement | BibTeX | EndNote | |
|---|---|---|---|---|---|---|
| 2,059 | 1,174 | 255 | 3,488 | 323 | 430 | 434 |
- HTML: 2,059
- PDF: 1,174
- XML: 255
- Total: 3,488
- Supplement: 323
- BibTeX: 430
- EndNote: 434
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
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.html
You do not provide in your manuscript a repository neither for the DEVS-FIRE nor the ACfire model, which we can not accept. You mention in the Code and Data Availability section of your manuscript that the fact that DEVS-FIRE is based on DEVSJAVA and copyrighted by the University of Arizona makes not possible to share it. This is not right. The fact that a software is based on other or ownership of copyright do not prevent publication of a software, but terms of licenses, and the potential share of code from one software used to develop another. In this way, it is perfectly possible that DEVS-FIRE can be published.
Something similar happens with ACfire. In this case, it seems even more clear that this is a kind of new module developed on top of DEVS-FIRE and presented in this work. Again, unless a licensing issue prevents it, which you should clarify, it is perfectly possible to publish the ACfire code.
You mention in your Code and Data Availability statement that "Furthermore, we are considering the option of commercializing the DEVS-FIRE software to better serve the community. " This statement is irrelevant for the purpose of the of the section, and therefore, you should remove it. Moreover, it is important to note that publishing a software under a free-libre open source software license does not prevent you from commercializing it, so such reasoning is wrong.
The GMD review process depends on reviewers and community commentators being able to access, during the discussion phase, the code and data on which a manuscript depends. Please, therefore, publish the DEVS-FIRE and ACfire software in one of the appropriate repositories and reply to this comment with the relevant information (link and a permanent identifier for it (e.g. DOI)) as soon as possible. We cannot have manuscripts under discussion that do not comply with our policy.
The 'Code and Data Availability’ section must also be modified to cite the new repository locations, and corresponding references added to the bibliography.
I must note that if you do not fix this problem, we cannot continue with the peer-review process or accept your manuscript for publication in GMD.
Juan A. Añel
Geosci. Model Dev. Executive Editor