ALMaSS has been under continuous development for more than two decades and is used to simulate everything from skylarks and hares to beetles, spiders, newts, roe deer and even people. At its heart sit two components that have remained essentially unchanged in core design since the earliest versions: the landscape simulation and the population managers. The population manager’s job is deceptively simple to state. It holds and manipulates the lists of entities that a particular model focuses on, schedules the actions those agents or population objects perform, and reports the status of the population back to the rest of the simulation. How well it does that job, the new paper argues, shapes the efficiency of the code, the flexibility of the algorithms, and even the outcome of the simulation itself.

The system is written in C++ using a rigorously object-oriented design. All functionality common to every population manager is defined in a base class called Population_Manager, while model-specific details live in descendant classes that inherit that code. A skylark population manager and a ladybird population manager are therefore siblings built from the same skeleton, each tailored with the number and type of life stages, input and output routines, and species-specific behaviours it needs. Inheritance is only the first pillar at work. The design also exploits polymorphism, allowing inherited methods to be re-implemented differently in each descendant, and encapsulation, keeping the internal workings of the class and its data hidden from other parts of the code. The result is a fully functional entity with a clean interface to the rest of the ALMaSS simulation. The class hierarchy can nest several levels deep; for beetles, common routines such as daily day-degree calculations for egg development sit in a general beetle manager, while ladybird-specific reproductive management resides further down the tree.

The core data structure is a list of every individual in the population, organised by life stage. In the original design, all individuals were held in a structure that had to be traversed serially during scheduling, which becomes painfully inefficient when simulations involve many organisms. The current version solves this by splitting the lists into a set of sub-lists, one per thread, in a structure the code calls TheSubArrays. This is a vector of vectors of forward_list: vectors are resizable arrays that can be randomly accessed, allowing the number of lists to be changed at run time to match the number of threads, while a forward_list is a singly-linked container that efficiently accepts new objects pushed onto its end. The first dimension of TheSubArrays represents the types of population entities, typically life stages, which descendant classes can alter. The second dimension is the thread number, enabling parallel running through OpenMP. The third dimension is the list of individuals at each life stage handled by each thread, a list whose length changes constantly as individuals are born and die.

Scheduling is where the design becomes genuinely distinctive. Each simulated time step, usually one day or ten minutes, is divided into what the authors call pseudo time. Before the step begins, three fixed actions occur: the objects of dead individuals from the previous step are deleted and their memory released, the live individuals are distributed evenly across the threads, and every individual is flagged with a variable called StepDone, set to false. The lists are then reordered, typically randomised, so that the order of individuals’ actions cannot bias the outcome. The main scheduling process then runs through three methods: BeginStep, Step and EndStep, each bracketed by a customisable Do method that descendant classes can use for reporting or list management. BeginStep and EndStep iterate through all objects in parallel once each, allowing behaviour to be selected at the start and end of a time step. Step is different: it is called iteratively, in the order of objects in TheSubArrays, until every object signals that StepDone is true. This turns the Step process into a state machine, permitting highly flexible behaviour sets, and an individual can even force another back into the Step code by resetting its flag, an event facility useful for tightly coupled objects such as family groups.

Parallel execution creates a hazard the authors confront head-on: when several agents in the same life stage run simultaneously, two may both try to claim the same resource, such as a patch of food, and both may assume they obtained it, producing serious and hard-to-trace bugs. The solution is a guard map that segments the landscape into non-overlapping grids, each carrying a guard flag. Before an individual performs any location-related activity, it must possess the guard flag for that location; other agents are blocked there until the behaviour completes and the flag is released. In BeginStep and EndStep, which run only a single loop, an agent whose flag is unavailable simply waits and retries later in that section. In the iterative Step function, waiting happens automatically, because the agent can be skipped and called again in the next loop, and loops continue until all individuals report StepDone as true.

To show why execution order matters so much, the authors built a minimalist model called Theoretical1, in which animals compete for a limited food resource. Each individual receives one food unit matched to its needs but forages randomly, gaining between 0.5 and 1.6 units daily, with food translated directly into growth. Each day, an individual selects another at random; if it is twenty percent larger, it can eat that individual and grow by half a percent of the victim’s size. Run for thirty-six months with the before-step action set to do nothing, the fixed execution order handed a decisive advantage to the earliest animals in the list: they grew faster, eventually ate the others, and the population declined while size differences widened. With the order randomised instead, no individual ever gained enough advantage to eat another. Neither version is inherently correct, the authors stress, but the example demonstrates that choosing the wrong representation of execution order can considerably alter a model’s outcome, echoing a concern raised in the literature but rarely quantified.

A second example, drawn from the established skylark model, shows how the three-phase design handles complex behaviour across life stages. Skylarks are territorial, and the insects they forage change daily with vegetation state and weather. Within a single one-day time step, the model must assess food availability around the territory, have the male forage, fill his energetic costs, feed the chicks, then do the same for the female, and finally let chick growth proceed. In the real world these activities are integrated over the day; with a one-day time step that integration is impossible to represent literally. The solution is to order the processes logically so that none depends on a process that follows it. The male’s entire sequence, from assessing forage to allotting portions to each chick, runs in BeginStep, with the forage information communicated to the female. In Step, the female uses that information to determine available forage, subtract her needs and allot food to the chicks. In EndStep, the chicks consume their allotted forage and determine daily growth. Viewed from outside the time step, the behaviour is integrated over the day, exactly as in nature, yet computed efficiently in pseudo time rather than through costly repeated iterations across life stages.

The third example quantifies the payoff of the new multithreading. Theoretical2 creates 10,000 animal objects, each holding 1,000 real numbers, with 1,040 births and 1,000 deaths per time step in a gradually expanding population, and 10,000 squaring calculations per animal per step, run for five simulated years on the same ten by ten kilometre landscape. On a computing node with two Intel Xeon Gold 6130 processors, each supporting 32 threads, run time fell from 443 seconds with one thread to 164 seconds with five, a 63 percent improvement, and further to 103 seconds with forty threads. Gains diminish as thread counts rise, a pattern the authors attribute to synchronisation overheads, and they note that computationally heavier models could benefit more than expected because thread management costs are relatively small. The guard map’s resolution and the complexity of the step code both influence the optimal thread number, so no universal guideline exists. One failure mode remains: the guard map cannot protect a simulation in which an agent can kill another agent of the same type at the same location, as when one adult ladybird eats another, so multithreading must be disabled in such models. Having served for more than twenty years without a major update, the Population_Manager now stands renewed, its authors argue, offering significant speed gains with minimal memory cost, while its central lesson endures: how agents are scheduled should always be an active, deliberate choice, never an accident of code.

Subject of Research: Agent-based population management and scheduling in the ALMaSS simulation framework

Article Title: Managing large and complex population operations with agent-based models: The ALMaSS Population_Manager

Article References: Topping, C. J., & Duan, X. (2024). Managing large and complex population operations with agent-based models: The ALMaSS Population_Manager. Food and Ecological Systems Modelling Journal, 5, Article e117593. https://doi.org/10.3897/fmj.5.117593

Image Credits: AI Generated

DOI: 10.3897/fmj.5.117593

Keywords: ALMaSS, agent-based modelling, population manager, multithreading, ecological modelling, scheduling, OpenMP, simulation software, skylark, C++, Managing, large