In the grey days between Christmas and the start of the New Year, I spent some time trying to develop a computer-model of a beehive. The first version had been very basic – it considered the egg-laying rate, the time that each bee spends in each stage of its life, and a death-rate. It gave an approximation of the population, but I understood that the processes in the hive were far more complex.
I listed out every element that would need to be considered, including honey-stores, pollen-stores, hive-temperature, cell-space and queen health. There were approximately thirty elements in total. The next stage was to figure out how they fitted together – to understand what could be used calculate each element, and identify what other information I would need.
It was easy to see how some of these elements could be calculated. For example, the total number of cells in the hive can be found by taking the number of cells at the end of previous day, and adding the number of new cells (calculated by multiplying the number of builder-bees by their daily work rate). Or to find the amount of pollen, take the previous day’s pollen-store, add any new pollen that’s been brought in, and subtract any that’s been eaten. The diagram below shows what we would need to calculate this.
Each of the elements had a similarly complex number of variables to consider, many with feedback loops and self-referencing values – the ‘chicken-and-egg’ problems of the hive. For example, the temperature is controlled by the number of bees on ventilation duties, the number of bees on ventilation duties is influenced by the temperature. Where do we start?
At the core of the problem was the challenge of knowing how many bees will be performing each task. Imagine for a moment that you’ve just been appointed Operations Manager of a beehive on a spring morning, and need to keep it running. You have five thousand bees, and need to decide how many will be doing each of the following tasks:
- nectar foraging
- pollen foraging
- guarding the entrance
- removing waste and dead bees
- ventilating the hive
- attending the queen.
There are some things you’d need to know before briefing the workers. If there’s a rainstorm outside you won’t assign many to foraging duties, if the hive-cavity is already full of comb you’ll have no need of builders, and if there are wasps around you might want more guards. But even when you have this information it’s still difficult to balance the number of bees assigned for each task. To build a model, I needed to develop a way to allocate the workforce.
Of course, in the real beehive things don’t work like this. There’s no Operations Manager assigning workers to particular tasks. The decisions are made by the individual bees, influenced by their age and experience, and the by complex communications within the hive: the pheromones, dances and vibrations which each individual experiences. But I did not need to replicate the process of the bees’ decision making, only to produce something with a broadly similar outcome.
In version two of the model, I used colour-coded hive-statuses. At ‘green’ status, all in-hive tasks are assigned as if there is no limitation on the number of bees available.If the hive is an ‘amber’ condition resources are slightly more limited. At ‘red’ status resources are really tight.
Some of the activities needed a complex matrix of requirements. For example, the number of bees on atmospheric-control/ventilation duties would be dependent on the temperature. The number of bees needed to be defined for a range of temperatures, and for each of the three hive-statuses. The actual numbers are not important here – the challenge is developing the mechanisms by which the calculations can be made, rather than the specific values.
So, on a day with a ‘moderate’ outdoor temperature, a hive with seven combs would ideally have 140 bees on ventilation duties. If there were not enough bees available (red status) it could struggle by with thirty-five ventilators and 100 nurse bees. Similar calculations can be used to determine the number of builders, cleaners and queen-attendants.
For the guard bees, I found myself on the MI5 website, adapting the ‘terrorist-threat-level’ terminology. A high number of wasps in the local area could be a ‘SUBSTANTIAL’ threat. If the wasps are showing interest in the hive the level could rise to ‘SEVERE’, becoming ‘CRITICAL’ if an attack seems imminent. As with the ventilation, each threat-level had a defined resource-level for the red, amber and green statuses.
Although the workload-allocation question could be approximately answered through this method, it only partially helped with untangling the complex web of relationships and inter-dependencies. I mapped out a complicated system of production-rates, functional capabilities, temperature-indexes, attack-risks, task-based mortality-rates, egg-laying rates, and drone-to-worker ratios.
But mapping the systems was changing the way I was thinking about the bees. The language I was using was switching from the poetic to the managerial. The bees were no longer ‘foraging for sweet nectar’, but ‘accessing floral resources’. I read a blog post referring to bees as “Apis Production Units”, and realised that was how I was beginning to see them.
It was not improving my understanding – I hadn’t yet include anything relating to the queen – or to swarms, diseases, winter-breaks, beekeeper-activity, or drones – all far to complicated, and it felt as if any measure would so arbitrary and simplified that there would be little to learn from it. It would need a full simulation, rather than a simplified model.
The process has reminded me how extraordinarily complex a bee-society is. I was only scratching the surface, and there are so many other factors that the bees must collectively be considering – trying to model it feels like trying to paint a masterpiece with crayons.