The scale of the challenge is staggering. ALMaSS must simulate landscapes of up to fifty by fifty kilometres, with a typical study area of ten by ten kilometres, at one-square-metre resolution. That means representing every hedgerow, field margin, road, and patch of grassland as discrete, addressable units of space. At the same time, the system must support multiple ecological models running simultaneously, from simple insect populations to complex human decision-making. Computational efficiency in both memory and processor speed is therefore not a luxury but a survival requirement. The developers achieved this balance through a strongly object-oriented design in C++, using relatively low-level programming to keep algorithms and data structures fast, while the class-based architecture keeps a codebase of enormous size manageable and extensible.

At the heart of the system sits the Landscape class, which acts as the environment into which all other models are placed. It is far more than a passive backdrop. The Landscape class supplies every piece of information that any agent-based or subpopulation model needs, in both space and time. When a simulation begins, the class performs a careful initialisation: it builds the internal map representation, establishes the FarmManager that will govern all farming activity, sets up behavioural functions for agent movement and resource use, and prepares the machinery for modifying input data and generating outputs. In effect, the Landscape class is the backbone of the entire simulation, ensuring that every virtual animal and every simulated farmer can access realistic environmental information at every moment of the run.

One of the most elegant engineering decisions in ALMaSS is its use of the flyweight design pattern to represent the map. Rather than storing full descriptive data for every square metre, the landscape is decomposed into internally homogeneous polygons, such as a one-hectare field. Each polygon is described once, in a class derived from the Landscape Element base class, and every one-metre cell of the raster map simply holds a reference pointing to that polygon’s data. A single hectare field therefore occupies ten thousand raster cells, but each cell contains only a pointer rather than a full copy of vegetation type, height, cover, biomass, farm ownership, and spilled grain records. This approach saves enormous amounts of memory and, crucially, means that updating a field’s properties requires changing the data in only one place, which the simulation then reads instantly through every cell that references it.

The external data feeding this structure arrives through two file types. The PolyRef file lists every polygon in the landscape, one row each, with attributes including a unique identifier, area in square metres, a farm reference number, soil type, centroid coordinates, and optional measures of elevation, slope, aspect, and openness, which quantifies the distance to the nearest tall artificial object. The companion .lsb file is a binary raster that records, for every one-metre cell, which polygon covers the majority of that cell. Together they provide a complete topographic and administrative map of the landscape. Soil types are classified using FAO texture codes, from sand through silt loam to heavy clay and organic peat, each linked to agricultural usage categories and crop management classes that determine how farming operations proceed on that ground.

Every simulated day, the landscape executes a disciplined sequence of updates: the calendar is advanced, the weather is refreshed, farming operations are triggered through the FarmManager, and every polygon’s internal behaviour is updated through a polymorphic Tick function. Vegetation growth is a central part of this daily cycle. Any landscape element with vegetation simulates its development using a method that relates plant height and leaf area index to the accumulated day-degrees since sowing or the start of the year. Growth curves are defined as sequences of inflection points with gradients of change, and five distinct growth phases allow complex patterns to be modelled, from autumn-sown wheat progressing through winter dormancy to post-harvest regrowth. Leaf area index is converted to vegetation cover using Beer’s Law with a light extinction coefficient of 0.6, and biomass change is driven by green leaf area and incoming radiation. When a harvest or cutting event occurs, the vegetation immediately jumps to a different growth phase, capturing the abrupt reality of farm machinery in the field.

The farming simulation itself is organised as a hierarchy of interacting objects. The FarmManager is an administrative class that controls the list of all farms and their scheduling, called once per day by the Landscape. Each Farm object owns a list of fields, some designated as permanent crops such as pasture or orchards, others assigned rotational crops drawn from a rotation list typically one hundred crops long, representing the area covered by each crop type in one-percentage blocks. Crop management is encoded in remarkably flexible event-driven programs. Each crop class exists as a single instance, and management operations are dispatched through an event queue containing pointers to the owning farm and the specific field. When a crop is initiated on a field, a timed event enters the queue, potentially scheduled months in advance. When triggered, the management code executes, generating new events that can fork into parallel threads, branching on conditions such as farm type, weather, soil state, vegetation characteristics, or the history of previous operations on that field. Only one thread reaches the end of the plan, returning a Done signal that triggers the next crop in the rotation. The result is a management system that behaves almost like a multi-threaded program, adapting dynamically to the changing farming context during the simulation.

Weather in ALMaSS is not simulated but supplied as historical input, including hourly temperature, precipitation, wind speed and direction, soil temperature, snow depth, humidity, and radiation. Because the record is historical, it is typically looped for long simulations, and models can request weather information for any point in time, even future dates within the loop. The Calendar class provides timekeeping from one day down to ten-minute resolution for animal models, supplying Julian days and simulation dates that crop management codes depend upon. It also calculates sunrise and sunset automatically from the latitude and longitude of the landscape, using either the official ninety-degree or astronomical 108-degree solar angle. These components together allow a crop code to demand, for instance, five consecutive rain-free days before a pesticide application proceeds.

The performance figures are remarkable. A ten by ten kilometre Danish landscape typically contains upwards of forty thousand polygons and one hundred fifty to two hundred farms. With no animals present, the landscape simulation runs at approximately one simulated year per second on an average personal computer, during which every farm operation is carried out daily and every vegetated element updates its biomass, leaf area index, height, digestibility, and insect biomass. Memory is the limiting factor: a fifty by fifty kilometre landscape requires a machine with sixty-four gigabytes of RAM, with the raster map alone consuming twenty gigabytes. Yet the scaling between area and run-time is linear, and the system has coped with up to fifty million concurrent agents in some simulations. This combination of detail and speed has enabled ALMaSS to address genuinely complex, multi-layered questions, such as tracing the chain from policy to farmer to pesticide to insects to birds and back to farmer, revealing emergent properties that no single-model study could capture.

The practical impact of this architecture is already substantial. ALMaSS has contributed to more than eighty published papers and reports and has supported three European H2020 projects: PoshBee, B-GOOD, and EcoStack, and currently underpins the population modelling framework in the Horizon Europe project PollinERA. In the Netherlands, ALMaSS scenarios evaluated how insecticide toxicity levels, spray drift reduction, and grassy field margins affected carabid beetle populations, finding that toxicity reduction had the most significant positive impact and that effectiveness was highly context-specific. In agri-environment scheme evaluations, thirteen different management scenarios demonstrated that landscape context plays a crucial role in determining whether conservation measures succeed. In land-use conversion studies, converting agricultural land to forest or permanent grassland benefited carabid beetles and mammals but harmed skylarks and spiders, illustrating how the same management action produces species-dependent outcomes. The code is openly available through a GitLab project, complete with documentation generated using doxygen, executable run directories, and example crop rotations for spring barley and winter wheat. As ecology increasingly demands system-level answers to multifaceted environmental questions, ALMaSS stands as a rare example of a simulation platform built to endure, adapt, and reveal the hidden connections between human decisions and the living landscape.

Subject of Research: Software architecture and methods of the ALMaSS landscape and farming simulation system for agent-based ecological modelling

Article Title: ALMaSS Landscape and Farming Simulation: software classes and methods

Article References: Topping, C. J., & Duan, X. (2024). ALMaSS Landscape and Farming Simulation: software classes and methods. Food and Ecological Systems Modelling Journal, 5, Article e121215. https://doi.org/10.3897/fmj.5.121215

Image Credits: AI Generated

DOI: 10.3897/fmj.5.121215

Keywords: ALMaSS, landscape simulation, agent-based modelling, farm management simulation, vegetation growth modelling, ecological risk assessment, C++ software design, flyweight pattern, crop rotation, agri-environment schemes, pesticide risk, Danish agriculture