# 1.2: The modelling cycle

## Why a modelling cycle

Start coding a model before you have decided what it should represent, and the work tends to unravel: assumptions get baked into code before they are examined, and a wrong early choice is discovered only after hours of effort. The remedy is a disciplined order of work. The stages are not arbitrary, because each one produces what the next needs: a description of the system has to precede precise rules, which have to precede code, and so on. Getting that order right is the backbone of every modelling project, even though, as we will see, you will often step back to an earlier stage when later work exposes a gap.

A model is built through a sequence of stages that move from a real-world problem to a working simulation and back again. Nikolic, van Dam and Lukszo describe these stages as a cycle, because the work is iterative: modellers move forward through the stages as the model takes shape and return to earlier ones when later work exposes a problem [^1]. It is also the cycle used throughout this book.

## The stages of the cycle

The diagram below shows the cycle used in this chapter.

```{figure} ../figures/fig_1_4_modelling_cycle.png
:name: fig-modelling-cycle
:width: 80%
:align: center

**Figure 1.4** The modelling cycle: real world → conceptual model → formal model → implementation → verification & validation → simulations, with a re-iterative loop that lets the modeller move forward and backward between stages. Adapted from Nikolic, van Dam and Lukszo (2013) [^1].
```

The cycle has seven stages. **Real world** is the starting point: a system exists, a question about it needs answering, and a model is one way to address that question. **Conceptual model** is where the modeller decides what is inside the system, what is outside it, and how the relevant parts behave, in plain language [^1]. **Formal model** turns that description into precise rules, often as pseudocode or equations, so the model can be implemented without ambiguity [^1]. **Implementation** is the translation of the formal model into running code, using a modelling environment or programming language [^1]. **Verification and validation** are two distinct checks: verification asks whether the code correctly implements the formal model, while validation asks whether the model represents the real system well enough to answer the question [^1]. **Simulations** are the experiments run with the verified, validated model, analysed to answer the research question [^1]. **Using the model** carries the findings back to the real world to predict, explain, or understand the system, which often raises new questions and restarts the cycle [^1].

The loop at the centre of the diagram reflects how the work proceeds. Modellers iterate. Formalisation often reveals gaps in the conceptual model. Implementation surfaces ambiguities the formal model did not resolve. Simulation results sometimes show that an earlier choice was wrong. Each of these sends the modeller back to a previous stage, and that is part of the work, not a failure of it [^1].

## A running example: traffic on a single-lane road

The stages are easiest to grasp when they are applied to one concrete problem, so before walking through them we introduce the example that recurs throughout the chapter. The same example is used through every stage of this chapter. The system is a stretch of road carrying traffic in one direction. The question is why traffic jams sometimes appear on such a road even when there is no accident, no bottleneck, and no obvious external cause. Empirical observation of real traffic shows that congestion can form spontaneously and that the resulting slow-downs travel backwards along the road as a wave [^2]. A model of the individual vehicles is one way to investigate how this happens, because the phenomenon arises from their interaction rather than from any single cause [^3].

```{admonition} How this chapter is organised
:class: note

The next subsections walk through the cycle one stage at a time, using this traffic example throughout: the conceptual model (1.2.1), the formal model (1.2.2), implementation (1.2.3), verification and validation (1.2.4), simulation experiments (1.2.5), and using the model (1.2.6). A final subsection (1.2.7) then presents a worked student report that applies the whole cycle to a real research question.
```

## Explore the cycle interactively

The stages are defined in the section above; here you see each one applied to the traffic example so the abstract steps become concrete. Click any stage on the ring below to see what happens in it and how it maps onto the traffic problem, or step through with the arrows. Each stage prepares the next, and any stage can send the modeller back to an earlier one [^1].

```{raw} html
:file: ../learning_activities_and_widgets/widgets/widget_1_2a_explore_the_modelling_cycle.html
```

## Practise the order

Having seen each stage applied to traffic, the next step is to reproduce the order for yourself, since fixing the sequence in your own mind is what makes the cycle usable. Recall that the order is not arbitrary: each stage produces what the next one needs, so a conceptual model has to precede a formal one, which has to precede code, and so on. In the activity below, put the cycle together yourself, in the order the stages happen, from the real world through to using the model.

```{raw} html
:file: ../learning_activities_and_widgets/learning_activities/activity_1_2b_cycle_scramble.html
```

The stages run in a fixed order because each one hands its output to the next, yet the loop at the centre means any stage can send you back to an earlier one. Holding both of those ideas together, a clear sequence and a genuine willingness to iterate, is what the cycle teaches.

With the order in place, the questions below check that you can tell the individual stages apart, especially the pairs that are easy to confuse.

```{raw} html
:file: ../learning_activities_and_widgets/learning_activities/activity_1_2c_check_the_modelling_cycle.html
```

Begin with {doc}`section_1_2_1_conceptual_model`, the first stage of the cycle, where the traffic problem is turned into a conceptual model.

## Key takeaways

```{admonition} Key takeaways
:class: important

- A model is built through a cycle of seven stages: real world → conceptual model → formal model → implementation → verification & validation → simulations → using the model, which carries the findings back to the real world.
- The cycle is iterative: formalisation, implementation, and simulation each often send the modeller back to an earlier stage.
- The same traffic example runs through every stage of this chapter, from the question through to the answer it gives.
```

## References

[^1]: Nikolic, I., van Dam, K. H., & Lukszo, Z. (2013). Practice. In K. H. van Dam, I. Nikolic, & Z. Lukszo (Eds.), *Agent-based modelling of socio-technical systems* (pp. 73–137). Springer.

[^2]: Treiber, M., & Kesting, A. (2013). *Traffic flow dynamics: Data, models and simulation*. Springer.

[^3]: Ramstedt, L., Törnquist Krasemann, J., & Davidsson, P. (2017). Movement of people and goods. In B. Edmonds & R. Meyer (Eds.), *Simulating social complexity: A handbook* (2nd ed., pp. 705–720). Springer.