Model Description

This project models a forest fire. Two versions of the project were created; the first uses AgentCubes, and the second uses JavaScript and the AgentModel.js library.

The Story

• A healthy tree will turn into a StayHealthy tree before the beginning of a time step. At the end of the time step, if it had not been turned into a burning tree, it will turn back into a healthy tree.
• Ignited trees turn into burning trees.
• Burning trees have a chance to turn into burnt trees.
• Dying trees turn into burnt trees.
• If a healthy tree is next to a burning tree, it has a chance to turn into an ignited tree.
• If a healthy tree is next to a dying tree, it has a chance to turn into an ignited tree.
• Wind blows in the headings North-South and East-West.
• If wind is blowing in a certain direction, the percent chance that a healthy tree catches fire in that direction increases.
• The percent chance that a healthy tree catches fire in the opposite direction of the wind decreases.
• A counter object counts and graphs burning, burnt, and healthy trees

Agents and Shapes

Observed Behaviors

The following behaviors were observed from our models and their graphs: When there is no wind, the fire spreads in a diamond shaped pattern, equally in all directions. Sometimes, the burning trees turn into burnt trees and die out. When there is wind, the fire spreads in the direction of the wind, and usually leaves patches of healthy trees unscathed in the opposite direction.

A graph of the models shows a relationship between the amount of healthy trees, burnt trees, and burning trees. Healthy trees and burnt trees seem inversely related- when one increases, the other decreases, and burning trees increases when the change of healthy trees to burnt trees increases. The amount of healthy trees and burnt trees are curved- their positive or negative change slows at the start and end of the model and rapidly changes in the middle of the time.

This makes a lot of sense when putting the model to perspective. In a limited world, the amount of healthy trees that can be changed at one point has a cut off point. So, when a burning tree is put in a world of healthy trees, the amount of healthy trees changing to burning trees to burnt trees grows slowly at the start, changing slowly, until the amount of spread continually grows and more and more trees are converted per time step. But, since the world is limited, the model hits a point where the diamond spread finds less and less new healthy trees to convert, healthy trees hiding in the nooks and corners of the world. Then the graphs quickly stabilize, signifying the entire world has been burnt. The spike of burning trees in relation to the increased change of healthy trees -> burnt trees also makes sense because, well, as the amount of change increases, the more trees are set to a 'burning' status. This has a quadratic curve because of logic explained before, that the amount of change rises and falls, but also because eventually (almost) all the trees turn into burnt trees, not being classified as burning anymore.

Nearest-Neighbors Burning

To workaround the AgentCubes issue, we created another shape for Trees called 'ignited trees.' They work in exactly the same way, but are named differently. In that way, we can reference the change as one time step. At the start of the rules, we checked to see if it was an ignited tree, and if the time step just started, a tree would not be ignited, moving onto the rules. Then, when a healthy tree needed to be changed to a burning tree, we changed it to an ignited tree. To signify the end of one time step the program goes back to the original rule, sees that it is an ignited tree, and still calls it a burning tree to graph.

We similarily pulled the same trick for StayHealthy trees and dying trees to represent the correct amount of healthy trees and burnt trees.

Conclusions

We learned the general trends and behaviors of the trees as time passes in a forest fire, as described in the observed behaviors, stemming from the "Nearest Neighbour" way of modeling. With our wind adjustment variable, we could see with our eyes how the spread changed and warped in it's direction. In addition, we saw how the actual model limitations can affect the application of it to real life. In our model, the limitations on the growth of the forest fire were pretty dependent on the world size and the chance for burning trees to turn into burnt trees, which leads us to question the actual semantics of forest fire growth in real life.

We also learned a lot about how to workaround limitations in software to develop models. To get over the Nearest Neighbour hurdle, we developed lots of rules that would manipulate the shapes to form a time step. But in doing so we had to develop a "check" phase and "change" phase to prevent the software ordering them in unpleasant ways, leading room for uncertainty and error.

Additionally, we learned general programming skills with Javascript. With programming, we learned how to use functions from another programmer's library to develop our own models. Oh, and also, how it feels, like a worm writhing to the crux of the brain, the desecration of the mind when looking for a syntax error without an IDE. Seriously, the discovery of the two commas that entirely broke your model is an entirely bittersweet experience.