Comment on nhess-2021-179

This manuscript explores the use of ‘agent-based’ approaches for simulating wildfire spread. Primarily the focus on in methodological advances rather than improvement of process understanding (but such understanding may emerge later with used of this new method). I am glad to see that the model code is available for scrutiny and with an open source licence. The manuscript is well written and seems worthy of publication given that it does present a novel approach to simulating wildfire spread (albeit extending on previous approaches). However, I have some concerns about the framing of the modelling, and some suggestions for analyses.


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.

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

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 is a flow chart to 'describe model procedures'. This is very difficult to read and needs to be improved. First, what do the arrows represent? Do they show the flow of time (order of execution) or indicate flows of information? Or both? Or something else. Maybe different types of arrows are needed (then a key is also needed). A key (legend) to explain the different shapes of boxes would be useful. Really think you should aim here to represent the order of execution of the model and, to do this most explicitly, every equation listed in Appendix A2 would be shown in the flow chart so that readers can understand in what order they are executed (without needing to check the source code). I understand that some procedures here are 'global' (once per iteration) while some are for multiple agents (so repeated multiple times per iteration), but some use of symbology can help here.

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.

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).

Model Comparison
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 Table 1 would enable to reader to compare performance of ABWiSE v1 directly. I don't think you should be shy in doing this. I agree that in it's current state ABWiSE 'is no replacement for existing model' but why couldn't it be in the future? The only way to advance the model with that objective is to directly compare model performance. Furthermore, I was encouraged to see that the model executes quickly (section 5.4) and so could feasibly be used operationally, but how does speed of execution compare to Prometheus (i.e. compare practicality as well as model performance). As a side note, if you were to refactor the model in a language faster than NetLogo (e.g. maybe using AgentPy in Python, https://agentpy.readthedocs.io) then this would be even more feasible. Ultimately, my comment here is that even though this is a 'proof of [the agentbased] concept' manuscript, I would like to see more direct comparison of ABWiSE with existing models.

Specific comments:
Table 1: Why do you present Standard Deviations and not Standard Errors? I think the latter would be more useful for comparing performance between the various cases. Line 315: I am unclear why case 3 is highlighted as having particularly low performance at the coarse resolution? In Table 1 it looks to me that Case 4 has worst absolute performance and case 3 actually has the smallest absolute decrease in Mean FoM between 200m and 500m resolutions. So this sentence confuses me. Could you please clarify Figure 4: I am confused about what 'Grid Spacing' is, as referred to in the figure caption. Grid spacing is not mentioned elsewhere in the manuscript. Could you please clarify. 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.