Reply on RC2

As an aside before my more substantive comments, a personal concern I’d like to raise here is the presentation of model as ‘agent-based’. The term is very fashionable and because of this is often applied when a better term would be appropriate. For example, as Bithell et al. (2008, doi: doi:10.1016/j.geoforum.2006.10.014) distinguish discreteelement, individual-based and agent-based modelling. These are all essentially the same approach aiming to “represent the interactions of individuals or entities with one another and their environments by sets of computational rules” with roots in complexity science. This is also the case for ABWiSE. The differences between the terms is disciplinary and dependent on what type of individuals are being represented; 'discrete-element models' are used in geomorphology, 'individual-based models' are used in ecology and 'agentbased models' are used in social science (where the individuals are understood to have some kind of agency or decision-making capacity). To my mind ABWiSE would be better described as a discrete-element model, where discrete elements are akin to ‘flames’ (rather than ‘fires’ as used in the model code) as I tend to understand agents as having some kind of decision-making agency. But I do recognise that ‘agent’ has become de rigueur and my personal view is a backburn that will be overwhelmed by the conflagration, so my comment here is more for public reflection than any change in the manuscript.


What is 'Agent-Based'?
As an aside before my more substantive comments, a personal concern I'd like to raise here is the presentation of model as 'agent-based'. The term is very fashionable and because of this is often applied when a better term would be appropriate. For example, as Bithell et al. (2008Bithell et al. ( , doi: doi:10.1016Bithell et al. ( /j.geoforum.2006.014) distinguish discreteelement, individual-based and agent-based modelling. These are all essentially the same approach -aiming to "represent the interactions of individuals or entities with one another and their environments by sets of computational rules" with roots in complexity science. This is also the case for ABWiSE. The differences between the terms is disciplinary and dependent on what type of individuals are being represented; 'discrete-element models' are used in geomorphology, 'individual-based models' are used in ecology and 'agentbased models' are used in social science (where the individuals are understood to have some kind of agency or decision-making capacity). To my mind ABWiSE would be better described as a discrete-element model, where discrete elements are akin to 'flames' (rather than 'fires' as used in the model code) as I tend to understand agents as having some kind of decision-making agency. But I do recognise that 'agent' has become de rigueur and my personal view is a backburn that will be overwhelmed by the conflagration, so my comment here is more for public reflection than any change in the manuscript.
The authors are thankful to the referee for bringing up this point for public reflection. We believe there is value in using the term "agent-based modelling" in a broader sense, not only because it is becoming de-rigeur, as the referee has said, but also because it invites originality. Used as a catch-all term, it can make it easier to compare similar methods across disciplines, and can encourage researchers to consider new problems under the lens of complex systems science and agent-based modelling. As to agency being a prerequisite of ABM, the Boids model is certainly considered an ABM, though the agency of the agents is very limited. If perception and (re)action are the chief elements of agency, then the term can encompass a lot. While ABWiSE could indeed fall under discreteelement methods, the concept of the model stemmed more from this concept of agency than discretization, which is why we prefer to use that terminology.

Complex vs Complicated
However, I do think there are some points in the manuscript where the language and concepts use to frame the development of ABWiSE in complexity science need changes. For example, I think we need to be careful about distinguishing complexity of model behaviour from the complicatedness of the model structure. This is well explained and explored by Sun et al. (2016;doi: 10.1016/j.envsoft.2016. There are some points in the manuscript where this distinction is blurred and I think the authors need to clarify, particularly given the emphasis they place on how their model approach aims to exemplify concepts from complexity theory and given this is a proof-of-concept paper (so we need to be clear about the concepts). For example: Line 51 I think you actually mean that the gap is between complicatedness of model structure and the speed of model execution? A very simple model could run very quickly and but still produce complex behaviour (i.e. complexity, e.g. the classic boids flocking model). Line 58, isn't the problem with CFD models that they are very complicated (needing many calculations) rather than they inherently produce complexity? Line 63 'small' I think you mean 'individual' here? It's not the size of the entity that is important for modelling complexity, rather the that there interactions of individual (discrete) entities that might give rise to emergent phenomena Line 129 I don't think we should be aiming to build 'complex' models. Rather, we should aim to develop simple (enough) models that enable us to understand complex phenomena (although often our models do become quite complicated). Can you check your use of language (complex vs complicatedness) and if you really do want to build a model with a complex structure, justify why that is better than one with a simple structure that produces complex behaviour (which I think is actually what you are trying to do). Line 6: given my points above, please consider whether you really do think physical models are necessarily complex and if this is really what you are hoping to combine with empiricism The authors are grateful to the referee for bringing these points to our attention. Overall, we agree that a better distinction between complicatedness and complexity will improve the quality of the manuscript. We have frequently used the term complex model to mean a model that represents complexity, rather than a model with complex structure. We will revise these instances to clarify that distinction.
On point one, while it is true that there are many simple (and fast running) models that produce complex behaviour, the preceding discussion in the manuscript notes that physical models typically represent the most complex behaviours, but they run slowly because of the way they do so. The gap between complexity and speed we were referring to is specific to fire simulation models, and more precisely those we have included in our Background section. Perhaps the phrase "Modellers are attempting to bridge the gap between available complexity and execution speed of fire spread models in various ways." would provide enough clarity?
On point two, indeed, that is poorly phrased. We will remove the word "complex" or replace it with "complicated".
On point three, we meant as a small part of the whole system, rather than physically small, but we agree that individual may be a more suitable term. We will rectify this in the revisions.
For point four, we do not wish to be creating complex models, as such. The intention was to mean models that account for / include the relevant complexities of the system at hand. We will revise the manuscript to ensure there are no references to "complex model structure" and that those phrases indicate "models that have complexity", instead.
The last one is an important point, and we will clarify it in the manuscript. We intended to show that, in what we have reviewed, physical models have typically been the only ones able to successfully address the complexity of forest fires, especially fire-wind interactions. Most of the physical models are complicated, however, and it is this complicatedness we wish to reduce using empiricism and ABM.

Model Flow
In general, the model is well very described. The appendices seem to contain all procedures and they are clear. The main exception to this for me is Figure 1 which  We thank the referee for pointing out the shortfalls of Figure 1. We propose a revised version, which is included in a supplement to this reply. It is more explicit about the order of execution, where procedures are arranged chronologically left-to-right, and the "inner loop" performed by every agent within a model time step is clearly identified. The box shapes follow standard convention for data (the cylinders), procedures (rectangles), and choices (diamond), so we thought the distinction was clear. The arrows show chronology.

Fuel Types
The approach you take to calibrate your model is sensible and seems to work relatively well. As you highlight it's not feasible to examine all possible parameter combinations and the CART approach seems to works well. However, it seems to me that even though the fuel variables are inputs to the model, they are still a key part of 'the model' (in the sense that they are conceptual representations of what will burn) and should be subject to some assessment. As you note in the appendix the fuel values are gross simplifications -this suggests some kind of sensitivity analysis of their values would be worthwhile. It would require more model runs, but not necessarily too many. Furthermore, I wonder if analysing results (for scenarios 3 and 4) relative to fuel type would be useful to understand errors. For example, a simple set of box plots for hits, misses and false alarms by fuel type might highlight whether some fuel types are poorly parameterised. However it is done, and while I appreciate you intend to do more comprehensive sensitivity and uncertainty analyses in future, I think some consideration of the uncertainty in the modelling due to fuel variable values is needed as this is a key input to the model. The authors thank the reviewer for this suggestion. While we agree that some analysis of the fuel type values is important, the method of analysis suggested by the reviewer may not be suitable. Given that fire propagates along the landscape in the simulation, and that different fuel types are distributed throughout, errors resulting from any poorly parametrized fuel type could result in error in other fuel types. We propose, instead, to test the different fuel types using scenarios 1 and 2. This would allow us to compare ABWiSE's response to fuel types with that of Prometheus. We did, in fact, test scenario 4 with a random distribution of fuel types across the study area, but the fire repeatedly failed to spread even to the river valley, and so would have made for very boring maps. We had omitted this from the manuscript for the sake of brevity, but could include FoM results from these tests in a table.

Wind
The incorporation of 'fire-atmosphere' feedback is good. But there does not seem to be an explicit consideration of how important incorporating this feedback is. Some consideration of this would be useful and it could be as simple as running the model with and without the feedback included to show the difference in performance (e.g. for the four scenarios). Furthermore, as it currently stands in this manuscript I think 'fire-atmosphere feedback' is a bit of a misnomer and could be explained more simply if it were described as fire-wind feedback (akin to how you name it in the source code). I can see that in future you may include other aspects of atmosphere but here you are solely looking at a 'fire-wind feedback' so why not call it that? (especially in Figure 1).
The referee makes an excellent point that the value of incorporating fire-wind feedback is never explicitly considered in our manuscript. We will rectify this, as suggested, as well as change our terminology from fire-atmosphere feedback to fire-wind feedback, as appropriate. Table 1  We thank the referee for their suggestions on model comparison. Since we will be following their advice on model evaluations for fuel type and wind by comparing with Prometheus, it will be no problem to include some other data for Prometheus and execution time in tables comparing cases 3 and 4.

I would like to see more explicit comparison with the Prometheus model (and maybe others). You do mention FoM values for Prometheus in the text but including these values in
Refactoring in another, faster language is an ultimate goal for ABWiSE, though for now, NetLogo is ideal for quickly implementing changes (due to its simple syntax and the modellers' familiarity with it). It is also worth noting that the current code in NetLogo has not been optimized for speed, so there may be room for improvement there, too.  Table 1 presents the distribution of FoM for the ensemble simulations, and as such is descriptive, rather than predictive. These distributions have no expected predictions from which to have errors, and so we report the standard deviation to describe the spread of possibilities in the ensemble of simulations. We thank the referee for noticing this discrepancy. Upon reflection, the statement is not particularly relevant to the manuscript. We may include something similar to the referee's statement about absolute changes in performance, instead. We are referring to the gridlines (graticules) used to represent scale in each of the subfigures. We thought it important to mention because there was no room to include the coordinates, as in i), for the rest. We thought it was important for the reader to be able to compare sizes between cases. We will change the terminology to make this clear.

Specific comments:
It is great that your model is open source with freely available source code. If the journal rules allow I suggest you make this clearer earlier in the manuscript (not leave right at the end). For example, I suggest you make a reference to the code on Line 178 where you state the implementation of the model.
We thank the referee for this suggestion, especially for including where to put the reference. We have seen nothing in the journal rules prohibiting such, therefore we will include it as suggested unless the editor disagrees.