Showing posts with label cell. Show all posts
Showing posts with label cell. Show all posts

Self-Assembly Gets Automated in Reverse of ‘Game of Life’

Mike's Notes

An excellent article from Quanta Magazine. Pipi 9 has some similarities to this.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Quanta Magazine
  • Home > Handbook > 

Last Updated

14/09/2025

Self-Assembly Gets Automated in Reverse of ‘Game of Life’

By: George Musser
Quanta Magazine 10/09/2025

George Musser is a contributing editor at Scientific American magazine and the author of two books, Spooky Action at a Distance and The Complete Idiot’s Guide to String Theory. He is the recipient of the 2011 American Institute of Physics Science Writing Award and the 2010 American Astronomical Society’s Jonathan Eberhart Planetary Sciences Journalism Award. He was a Knight Science Journalism Fellow at MIT from 2014 to 2015. He can be found on Mastodon and Bluesky.

In cellular automata, simple rules create elaborate structures. Now researchers can start with the structures and reverse-engineer the rules.

Alexander Mordvintsev showed me two clumps of pixels on his screen. They pulsed, grew and blossomed into monarch butterflies. As the two butterflies grew, they smashed into each other, and one got the worst of it; its wing withered away. But just as it seemed like a goner, the mutilated butterfly did a kind of backflip and grew a new wing like a salamander regrowing a lost leg.

Mordvintsev, a research scientist at Google Research in Zurich, had not deliberately bred his virtual butterflies to regenerate lost body parts; it happened spontaneously. That was his first inkling, he said, that he was onto something. His project built on a decades-old tradition of creating cellular automata: miniature, chessboard-like computational worlds governed by bare-bones rules. The most famous, the Game of Life, first popularized in 1970, has captivated generations of computer scientists, biologists and physicists, who see it as a metaphor for how a few basic laws of physics can give rise to the vast diversity of the natural world.

In 2020, Mordvintsev brought this into the era of deep learning by creating neural cellular automata, or NCAs. Instead of starting with rules and applying them to see what happened, his approach started with a desired pattern and figured out what simple rules would produce it. “I wanted to reverse this process: to say that here is my objective,” he said. With this inversion, he has made it possible to do “complexity engineering,” as the physicist and cellular-automata researcher Stephen Wolfram proposed in 1986(opens a new tab) — namely, to program the building blocks of a system so that they will self-assemble into whatever form you want. “Imagine you want to build a cathedral, but you don’t design a cathedral,” Mordvintsev said. “You design a brick. What shape should your brick be that, if you take a lot of them and shake them long enough, they build a cathedral for you?”

Such a brick sounds almost magical, but biology is replete with examples of basically that. A starling murmuration or ant colony acts as a coherent whole, and scientists have postulated simple rules that, if each bird or ant follows them, explain the collective behavior.  Similarly, the cells of your body play off one another to shape themselves into a single organism. NCAs are a model for that process, except that they start with the collective behavior and automatically arrive at the rules.

Alexander Mordvintsev created complex cell-based digital systems that use only neighbor-to-neighbor communication.

Courtesy of Alexander Mordvintsev

The possibilities this presents are potentially boundless. If biologists can figure out how Mordvintsev’s butterfly can so ingeniously regenerate a wing, maybe doctors can coax our bodies to regrow a lost limb. For engineers, who often find inspiration in biology, these NCAs are a potential new model for creating fully distributed computers that perform a task without central coordination. In some ways, NCAs may be innately better at problem-solving than neural networks.

Life’s Dreams

Mordvintsev was born in 1985 and grew up in the Russian city of Miass, on the eastern flanks of the Ural Mountains. He taught himself to code on a Soviet-era IBM PC clone by writing simulations of planetary dynamics, gas diffusion and ant colonies. “The idea that you can create a tiny universe inside your computer and then let it run, and have this simulated reality where you have full control, always fascinated me,” he said.

He landed a job at Google’s lab in Zurich in 2014, just as a new image-recognition technology based on multilayer, or “deep,” neural networks was sweeping the tech industry. For all their power, these systems were (and arguably still are) troublingly inscrutable. “I realized that, OK, I need to figure out how it works,” he said.

He came up with “deep dreaming,” a process that takes whatever patterns a neural network discerns in an image, then exaggerates them for effect. For a while, the phantasmagoria that resulted — ordinary photos turned into a psychedelic trip of dog snouts, fish scales and parrot feathers — filled the internet. Mordvintsev became an instant software celebrity.

Among the many scientists who reached out to him was Michael Levin(opens a new tab) of Tufts University, a leading developmental biologist. If neural networks are inscrutable, so are biological organisms, and Levin was curious whether something like deep dreaming might help to make sense of them, too. Levin’s email reawakened Mordvintsev’s fascination with simulating nature, especially with cellular automata.

From a single cell, this neural cellular automata transforms into the shape of a lizard.

The core innovation made by Mordvintsev, Levin and two other Google researchers, Ettore Randazzo and Eyvind Niklasson, was to use a neural network to define the physics of the cellular automaton. In the Game of Life (or just “Life” as it’s commonly called), each cell in the grid is either alive or dead and, at each tick of the simulation clock, either spawns, dies or stays as is. The rules for how each cell behaves appear as a list of conditions: “If a cell has more than three neighbors, it dies,” for example. In Mordvintsev’s system, the neural network takes over that function. Based on the current condition of a cell and its neighbors, the network tells you what will happen to that cell. The same type of network is used to classify an image as, say, a dog or cat, but here it classifies the state of cells. Moreover, you don’t need to specify the rules yourself; the neural network can learn them during the training process.

To start training, you seed the automaton with a single “live” cell. Then you use the network to update the cells over and over again for dozens to thousands of times. You compare the resulting pattern to the desired one. The first time you do this, the result will look nothing like what you intended. So you adjust the neural network’s parameters, rerun the network to see whether it does any better now, make further adjustments, and repeat. If rules exist that can generate the pattern, this procedure should eventually find them.

The adjustments can be made using either backpropagation, the technique that powers most modern deep learning, or a genetic algorithm, an older technique that mimics Darwinian evolution. Backpropagation is much faster, but it doesn’t work in every situation, and it required Mordvintsev to adapt the traditional design of cellular automata. Cell states in Life are binary — dead or alive — and transitions from one state to the other are abrupt jumps, whereas backpropagation demands that all transitions be smooth. So he adopted an approach developed by, among others, Bert Chan at Google’s Tokyo lab in the mid-2010s. Mordvintsev made the cell states continuous values, anything from 0 to 1, so they are never strictly dead or alive, but always somewhere in between.

Mordvintsev also found that he had to endow each cell with “hidden” variables, which do not indicate whether that cell is alive or dead, or what type of cell it is, but nonetheless guide its development. “If you don’t do that, it just doesn’t work,” he said. In addition, he noted that if all the cells updated at the same time, as in Life, the resulting patterns lacked the organic quality he was seeking. “It looked very unnatural,” he said. So he began to update at random intervals.

Finally, he made his neural network fairly beefy — 8,000 parameters. On the face of it, that seems perplexing. A direct translation of Life into a neural network would require just 25 parameters, according to simulations done in 2020 by Jacob Springer, who is now a doctoral student at Carnegie Mellon University, and Garrett Kenyon of Los Alamos National Laboratory. But deep learning practitioners often have to supersize their networks, because learning to perform a task is harder than actually performing it.

Moreover, extra parameters mean extra capability. Although Life can generate immensely rich behaviors, Mordvintsev’s monsters reached another level entirely.

Fixer Upper

The paper that introduced NCAs to the world in 2020 included an applet(opens a new tab) that generated the image of a green lizard. If you swept your mouse through the lizard’s body, you left a trail of erased pixels, but the animal pattern soon rebuilt itself. The power of NCAs not just to create patterns, but to re-create them if they got damaged, entranced biologists. “NCAs have an amazing potential for regeneration,” said Ricard Solé of the Institute of Evolutionary Biology in Barcelona, who was not directly involved in the work.

The butterfly and lizard images are not realistic animal simulations; they do not have hearts, nerves or muscles. They are simply colorful patterns of cells in the shape of an animal. But Levin and others said they do capture key aspects of morphogenesis, the process whereby biological cells form themselves into tissues and bodies. Each cell in a cellular automaton responds only to its neighbors; it does not fall into place under the direction of a master blueprint. Broadly, the same is true of living cells. And if cells can self-organize, it stands to reason that they can self-reorganize.

Cut off the tail of an NCA lizard and the form will regenerate itself.

Sometimes, Mordvintsev found, regeneration came for free. If the rules shaped single pixels into a lizard, they also shaped a lizard with a big gash through it into an intact animal again. Other times, he expressly trained his network to regenerate. He deliberately damaged a pattern and tweaked the rules until the system was able to recover. Redundancy was one way to achieve robustness. For example, if trained to guard against damage to the animal’s eyes, a system might grow backup copies. “It couldn’t make eyes stable enough, so they started proliferating — like, you had three eyes,” he said.

"A kind of computer that looks like an NCA instead would be a vastly more efficient kind of computer." - Blaise Agüera y Arcas

Sebastian Risi(opens a new tab), a computer scientist at the IT University of Copenhagen, has sought to understand what exactly gives NCAs their regenerative powers. One factor, he said, is the unpredictability that Mordvintsev built into the automaton through features such as random update intervals. This unpredictability forces the system to develop mechanisms to cope with whatever life throws at it, so it will take the loss of a body part in stride. A similar principle holds for natural species. “Biological systems are so robust because the substrate they work on is so noisy,” Risi said.

Last year, Risi, Levin and Ben Hartl, a physicist at Tufts and the Vienna University of Technology, used NCAs to investigate how noise leads to robustness. They added one feature to the usual NCA architecture: a memory. This system could reproduce a desired pattern either by adjusting the network parameters or by storing it pixel-by-pixel in its memory. The researchers trained it under various conditions to see which method it adopted.

If all the system had to do was reproduce a pattern, it opted for memorization; fussing with the neural network would have been overkill. But when the researchers added noise to the training process, the network came into play, since it could develop ways to resist noise. And when the researchers switched the target pattern, the network was able to learn it much more rapidly because it had developed transferable skills such as drawing lines, whereas the memorization approach had to start from scratch. In short, systems that are resilient to noise are more flexible in general.

Even if disturbed, the textures created by NCAs have the ability to heal themselves.

The researchers argued that their setup is a model for natural evolution. The genome does not prescribe the shape of an organism directly; instead, it specifies a mechanism that generates the shape. That enables species to adapt more quickly to new situations, since they can repurpose existing capabilities. “This can tremendously speed up an evolutionary process,” Hartl said.

Ken Stanley, an artificial intelligence researcher at Lila Sciences who has studied computational and natural evolution, cautioned that NCAs, powerful though they are, are still an imperfect model for biology. Unlike machine learning, natural evolution does not work toward a specific goal. “It’s not like there was an ideal form of a fish or something which was somehow shown to evolution, and then it figured out how to encode a fish,” he noted. So the lessons from NCAs may not carry over to nature.

Auto Code

In regenerating lost body parts, NCAs demonstrate a kind of problem-solving capability, and Mordvintsev argues that they could be a new model for computation in general. Automata may form visual patterns, but their cell states are ultimately just numerical values processed according to an algorithm. Under the right conditions, a cellular automaton is as fully general as any other type of computer.

The standard model of a computer, developed by John von Neumann in the 1940s, is a central processing unit combined with memory; it executes a series of instructions one after another. Neural networks are a second architecture that distributes computation and memory storage over thousands to billions of interconnected units operating in parallel. Cellular automata are like that, but even more radically distributed. Each cell is linked only to its neighbors, lacking the long-range connections that are found in both the von Neumann and the neural network architectures. (Mordvintsev’s neural cellular automata incorporate a smallish neural network into each cell, but cells still communicate only with their neighbors.)

"You are forcing it not to memorize that answer, but to learn a process to develop the solution." - Stefano Nichele

Long-range connections are a major power drain, so if a cellular automaton could do the job of those other systems, it would save energy. “A kind of computer that looks like an NCA instead would be a vastly more efficient kind of computer,” said Blaise Agüera y Arcas, the chief technology officer of the Technology and Society division at Google.

But how do you write code for such a system? “What you really need to do is come up with [relevant] abstractions, which is what programming languages do for von Neumann–style computation,” said Melanie Mitchell of the Santa Fe Institute. “But we don’t really know how to do that for these massively distributed parallel computations.”

A neural network is not programmed per se. The network acquires its function through a training process. In the 1990s Mitchell, Jim Crutchfield of the University of California, Davis, and Peter Hraber at the Santa Fe Institute showed how cellular automata could do the same. Using a genetic algorithm, they trained automata to perform a particular computational operation, the majority operation: If a majority of the cells are dead, the rest should die too, and if the majority are alive, all the dead cells should come back to life. The cells had to do this without any way to see the big picture. Each could tell how many of its neighbors were alive and how many were dead, but it couldn’t see beyond that. During training, the system spontaneously developed a new computational paradigm. Regions of dead or living cells enlarged or contracted, so that whichever predominated eventually took over the entire automaton. “They came up with a really interesting algorithm, if you want to call it an algorithm,” Mitchell said.

She and her co-authors didn’t develop these ideas further, but Mordvintsev’s system has reinvigorated the programming of cellular automata. In 2020 he and his colleagues created an NCA that read handwritten digits, a classic machine learning test case. If you draw a digit within the automaton, the cells gradually change in color until they all have the same color, identifying the digit. This year, Gabriel Béna of Imperial College London and his authors, building on unpublished work by the software engineer Peter Whidden, created algorithms for matrix multiplication and other mathematical operations. “You can see by eye that it’s learned to do actual matrix multiplication,” Béna said.

Stefano Nichele, a professor at Østfold University College in Norway who specializes in unconventional computer architectures, and his co-authors recently adapted NCAs to solve problems from the Abstraction and Reasoning Corpus, a machine learning benchmark aimed at measuring progress toward general intelligence. These problems look like a classic IQ test. Many consist of pairs of line drawings; you have to figure out how the first drawing is transformed into the second and then apply that rule to a new example. For instance, the first might be a short diagonal line and the second a longer diagonal line, so the rule is to extend the line.

Neural networks typically do horribly, because they are apt to memorize the arrangement of pixels rather than extract the rule. A cellular automaton can’t memorize because, lacking long-range connections, it can’t take in the whole image at once. In the above example, it can’t see that one line is longer than the other. The only way it can relate them is to go through a process of growing the first line to match the second. So it automatically discerns a rule, and that enables it to handle new examples. “You are forcing it not to memorize that answer, but to learn a process to develop the solution,” Nichele said.

Other researchers are starting to use NCAs to program robot swarms. Robot collectives were envisioned by science fiction writers such as Stanisłav Lem in the 1960s and started to become reality in the ’90s. Josh Bongard, a robotics researcher at the University of Vermont, said NCAs could design robots that work so closely together that they cease to be a mere swarm and become a unified organism. “You imagine, like, a writhing ball of insects or bugs or cells,” he said. “They’re crawling over each other and remodeling all the time. That’s what multicellularity is really like. And it seems — I mean, it’s still early days — but it seems like that might be a good way to go for robotics.”

To that end, Hartl, Levin and Andreas Zöttl, a physicist at the University of Vienna, have trained virtual robots — a string of beads in a simulated pond — to wriggle like a tadpole. “This is a super-robust architecture for letting them swim,” Hartl said.

For Mordvintsev, the crossover between biology, computers and robots continues a tradition dating to the early days of computing in the 1940s, when von Neumann and other pioneers freely borrowed ideas from living things. “To these people, the relation between self-organization, life and computing was obvious,” he said. “Those things somehow diverged, and now they are being reunified.”

The Vital Question by Nick Lane – a game-changing book about the origins of life

Mike's Notes

Note

Resources

References

  • The Vital Question. Nick Lane

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Fundamentals Biology
  • Home > Ajabbi Research > Library > Authors > Nick Lane
  • Home > Handbook > 

Last Updated

15/07/2025

The Vital Question by Nick Lane – a game-changing book about the origins of life

By: Peter Forbes
The Guardian: 22/04/2015

Why sex? Why then only two sexes? Why do we age and die? It’s the energy, stupid! This thinking is as important as the Copernican revolution

The “Origin of Life” is a conundrum that could once be safely consigned to wistful armchair musing – we’ll never know so don’t take it too seriously. You will probably imagine that it’s still safe to leave the subject in this speculative limbo, without very much in the way of evidence.

You’d be very wrong, because in the last 20 years, and especially the last decade, a powerful new body of evidence has emerged from genomics, geology, biochemistry and molecular biology. Here is the book that presents all this hard evidence and tightly interlocking theory to a wider audience.

While most researchers have been bedazzled by DNA into focusing on how such replicating molecules have evolved, Nick Lane’s answer could be characterised as “it’s the energy, stupid”. Of all the definitions of life, the one that matters most concerns energy: the churn of metabolic chemistry in the cells and the constant intake of nutrients and expulsion of waste are the essence of life. Information without energy is useless (pull the plug on your computer); information could not have started the whole thing off but energy could.

It is widely recognised that the creation of a viable primitive living cell, capable of reproduction and Darwinian selection, has three requirements: a containing membrane, which acts as an interface between the organism and the environment; replicators able to store the genetic instructions for the organism and to synthesise its chemical apparatus; and a way of taking energy from the environment and putting it to work to run the cell’s processes. Lane shows how all the rest can follow if we put energy first.

He is a researcher in evolutionary biochemistry at University College London who has been developing his grand energy theory of life, the universe and everything for more than two decades, explaining it in the books Oxygen (2002), Power, Sex, Suicide (2005) and Life Ascending (2009), which won the Royal Society book prize in 2010. He is an original researcher and thinker and a passionate and stylish populariser. His theories are ingenious, breathtaking in scope, and challenging in every sense. To read him, it helps, as Richard Dawkins once said of himself when embarking on an intricate passage in The Blind Watchmaker, to bring your “mental running shoes”.

Lane’s research on the energy reactions of living cells has brought him to a theory that can account for some of life’s biggest mysteries: why sex? Why then only two sexes? Why do we age and die? Why are the mitochondria, the cell components that produce all our energy, only inherited from the female line (the male mitochondria being destroyed in the germ cells)? Why do those same mitochondria – once fully fledged, free living bacteria with at least 1,500 genes (before they merged with another cell 1.7-2bn years ago to create the possibility of multicellular life) – have only 13 protein-coding genes left?

Lane has the most plausible answers to these questions so far, but the greatest detective story is that of life’s origin. The evidence now is highly detailed: the essential biochemical machinery of life is known down to the last atom; the remarkable large protein complexes that catalyse the cascade of energy reactions have been, thanks to x-ray crystallography, charted in atomic detail. What these precise structures reveal are clues such as the existence of mineral centres in the otherwise proteinaceous complexes of life’s vital enzymes: iron sulphide is found at the heart of the respiratory enzymes. Why is that significant?

Because the most plausible location for where life on Earth began is the alkaline hydrothermal vents near the Mid-Atlantic Ridge, on the deep ocean floor, and other such formations. These structures, discovered only in 2000 after being predicted by the pioneering geochemist Mike Russell at Nasa’s Jet Propulsion Laboratory, have the right credentials: masses of warm energetic minerals pour out of the ocean bed and form calcium carbonate chimneys full of micropores. In the conditions of the primitive world, they would also have contained the ingredients necessary to create organic chemicals, the precursors of life; the micropores would have contained and concentrated them and the hot chemicals that spewed forth, rich in iron and sulphur, would have created energy gradients.

Russell is one of the key figures in this developing story, along with Lane himself, Bill Martin at the University of Düsseldorf, and Lane’s colleague at UCL Andrew Pomiankowski. If Lane and his colleagues are right on the origin of life, what of the other puzzles: why do animals have sex, grow old and die? The answer, to paraphrase Kenneth Williams’s farmer character in Round the Horne, “lies in the mitochondria”. It is the biochemical mechanisms and structures that evolved from those energetic deep-ocean outpourings that power our cellular batteries, the mitochondria, today. You’re most likely to have heard of them through the recent controversial therapy of mitochondrial replacement. There might only be 13 mitochondrial genes left (the rest have all been incorporated in our main genome or rendered useless by mutation) but that still means that we have two genomes, not one. In fact, the commonly used but misleading term for mitochondrial replacement therapy – “three-parent babies” – would be better described as “Two Parents and 13 Genes Left Over from a 2bn-Year-old Mitochondrion”. Which isn’t to deny the significance of the mitochondrion and its 13 genes; as Lane explains, the subtle interactions between the two genomes can account for all the mysteries of multicellular life.

It might provide all our energy but, genetically, the mitochondrion is a cuckoo in the nest: it has its own genome and reproduces, bacteria-style, without sex. Sex evolved in order to shuffle our genes every generation, allowing us to keep good mutations and lose bad ones. But the energetic, sexless, cuckoo mitochondrion can’t do this. Bad mutations in your battery are extremely dangerous: that’s why most of the genes have dropped out of the mitochondrion into the main genome, so that they can enjoy the advantages of sex. The rump genes, though, have to be close to the mitochondrial machinery for the system to work and it is these genes, when faulty, that would be replaced in mitochondrial therapy.

Why do we only inherit them from the mother? Because her eggs are formed only once, at birth, whereas men make sperm throughout their lives, creating many more opportunities for mutation. This is why male mitochondrial genes are deleted in the sperm cells. Lane goes on to explain how our weird mitochondrial inheritance explains the other great puzzles.

There will be those who question the book’s title: “The Vital Question”? But intellectually what Lane is proposing, if correct, will be as important as the Copernican revolution and perhaps, in some ways, even more so. Life, seen in energetic terms, is a process of reducing carbon dioxide with hydrogen to create biomass and all the interesting consequences that follow from it (us, for instance). The future of life on the planet now seems to hinge on one life‑form (us again) learning to copy this process as a substitute for all that fossil fuel we’ve been burning. There’s a poetic symmetry in this (“in my beginning is my end”) and the work on the origin of life feeds the work on solar biosynthesis. But get this wrong and we’ll have to update TS Eliot: “Our end was our failure to learn from our beginning.”

Markus Covert: How to build a computer model of a cell

Mike's Notes

Another video interview with Marcus Covert. Pipi 6 was built by fusing Pipi with Covert's open-source cellular simulation software.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Authors > Markus Covert
  • Home > Handbook > 

Last Updated

05/06/2025

Markus Covert: How to build a computer model of a cell

By: Stanford Engineering Staff
The Future of Everything podcast: 20/10/2020

When Stanford bioengineer Markus Covert first decided to create a computer model able to simulate the behavior of a single cell, he was held back by more than an incomplete understanding of how a cell functions, but also by a lack of computer power.

His early models would take more than 10 hours to churn through a single simulation and that was when using a supercomputer capable of billions of calculations per second.

Nevertheless, in his quest toward what had been deemed “a grand challenge of the 21st century,” Covert pressed on and eventually published a paper announcing his success in building a model of just one microbe: E. coli, a popular subject in biological research. The model would allow researchers to run experiments not on living bacteria in a lab, but on a simulated cell on a computer.

After all was said and done, however, the greatest takeaway for Covert was that a cell is a very, very complex thing. There were fits and starts and at least one transcendent conceptual leap — which Covert has dubbed “deep curation” — needed to make it all happen, but he found a way. As Covert points out, no model is perfect, but some are useful. And that is how usefulness, not perfection, became the goal of his work, as he tells fellow bioengineer Russ Altman in this episode of Stanford Engineering’s The Future of Everything podcast.

Cell Boundaries: Defining the Scope of a Cell in Cell-based Architecture

Mike's Notes

Pipi uses several different novel cell-like structures in its architecture, unlike the one described in this article. However, there are some good ideas here.

I went with embracing chaos and complexity. The trick is making it work.

Resources

References


Repository

  • Home > 

Last Updated

30/03/2025

Cell Boundaries: Defining the Scope of a Cell in Cell-based Architecture

By: Benjamin Cane
Medium: 2/03/2025

Builder of payments systems & open-source contributor. Writing mostly micro-posts on Medium. https://github.com/madflojo

One of the hardest questions when adopting Cell-based Architecture is defining what should and shouldn’t be within a Cell.

Defining a Cell’s boundary is crucial to ensure you’ve encapsulated everything you need while balancing its size and complexity.

Today, I will share my thought process when defining a Cell’s boundary.

Recap on Cell-based Architecture

For those who may have missed my previous posts, the TL;DR on Cell-based Architecture is that instead of building one massive system, split it into isolated groups called Cells.

Doing so will improve the system’s resilience, performance, and scalability.

To catch up, check out my recent Cell-based Architecture post.

Avoiding a Massive Cell

Ideally, every service a single request may traverse or require as a dependency should be within a Cell.

However, in a complex enterprise, a single request may trigger multiple downstream events and rely on numerous systems.

Since every component within a Cell should be tested, deployed, and failed-over together, managing such a massive system is impractical. Breaking up this customer journey across multiple Cells is better but requires thought and strategy.

Defining some Terms

Before discussing how boundaries are defined, let’s define some terms that will help ensure we are all speaking the same language.

Platform:

For this post, a Platform is a collection of sub-platforms and/or monolith systems that provide a set of functionalities for a customer journey (i.e., payment processing).

Sub-platform:

For this post, a Sub-platform is a collection of microservices that provide a clearly defined capability (e.g., account or request validations).

Region and Availability Zones:

We will also use the public cloud definitions of Regions and Availability Zones, where a Region is a separate geographical area separated by a significant distance, and availability zones are multiple isolated hosting environments close to each other but not relying on a shared resource like power, physical location, or network.

Principles

When defining boundaries, I often apply a set of principles made of rules and guidelines. While these might sound similar, the difference between a rule and a guideline is how much I’m willing to break the guidance.

I do not break the rules; they guide my decisions. A guideline is a bias, something I’m willing to ignore if it makes sense and I have good reasons (which should be written down and captured).

Rules

  • A single Cell does not span regions.

The core concept of Cell-based Architecture is to build multiple isolated systems that are carbon copies of each other rather than a single system that gains its resiliency by spreading across numerous regions.

To ensure availability, we must deploy those carbon copies in multiple Regions, with each Cell acting independently and isolated at the Region level.

A Cell might span multiple Availability Zones within a Region but it is not required.

Keeping cells within a single availability zone may be prudent if you need low latency.

Of course, this deployment approach will add operational overhead, leading to more cells, as you still need to ensure you have carbon copies in other regions. But this decision is one of those infamous trade-off moments.

  • Sub-platforms do not span multiple Cells.

Aside from the performance and failover complexities incurred by a sub-platform spanning multiple cells, keeping a sub-platform within a single cell helps solidify its responsibilities and boundaries.

The idea of a sub-platform is that external systems don’t know the internal workings of the sub-platform, only the external facing interfaces.

Is the sub-platform a microservices design, a monolith, or macroservices? It does not matter.

A sub-platform has a contract, and its owners decide its internal workings.

Extending that internal flexibility across multiple Cells becomes very complex and will likely violate other rules.

  • Components within a Cell must be tested together.

Cells might be a collection of multiple sub-platforms (more on this later), but the idea of a Cell is that it’s a single isolated unit of processing.

Whenever you deploy new capabilities or establish a new Cell, you want to ensure everything works together as expected. The best way to accomplish this is to test the entire customer journey at the Cell level.

If a customer journey spans multiple cells, testing them together may be a good idea, but ideally, the boundaries should be clear enough that cells are independently testable.

  • Failover is at a whole cell level.

In a traditional architecture where a platform is a single entity across regions, you’ll see scenarios where a single microservice fails, and traffic to that microservice is routed to another region to service new requests.

While this approach sounds excellent from an availability perspective, it’s problematic.

When a single microservice fails, the latency of a single cross-region call may not break the system, but what happens when multiple services fail? Now, a single customer request may traverse regions numerous times.

Not only is this a performance killer, but every time you traverse regions, the chances of packet loss, network failures, etc., increase — a classic “death by 1000 microservices” example.

  • Cell-to-cell communications must use fixed contracts and protocols.

Interactions between sub-platforms must follow fixed contracts and protocols, whether a REST API, a Message Queue, gRPC, or a file.

Changes within a sub-platform are okay; typically (but not always), a single team can implement them across the sub-platform.

However, we should always assume that different teams manage different sub-platforms. Changes between sub-platforms require coordination and communication across multiple teams. The same applies to Cells.

Changes between Cells always require extra coordination and testing, so we should manage them like any other API change (with versioning!).

  • Cell to Cell communications can cross Regions, but never Cell internal communications.

When defining a Cell boundary, it’s best to assume that calls between Cells may traverse regions. Cell-based Architecture acknowledges that failures will happen. A Cell will need to failover; when this happens, a request might traverse regions.

While it might be optimal to ensure Cells talk locally within a region, this is an optimization and should not be relied on for performance or resiliency.

When you assume cell-to-cell calls traverse Regions, a new set of non-functional requirements must be considered, such as retries, circuit breakers, latency, etc.

Internal Cell calls should always be local because failover is at the Cell level, not the microservice level. The whole point of Cell-based architecture is to create isolation; if internal communications traverse regions, it breaks the entire design.

Guidelines

  • Avoid Dependencies between Cells.

Some customer journeys are expansive, so encapsulating everything into a single cell can be challenging.

Building dependencies between Cells is okay, but as described above, Cell-to-Cell calls will span regions and have more non-functional concerns such as increased latency and failures.

It’s easier to manage Cells that do not depend on others, but it’s not always practical.

  • A Cell should contain a single sub-platform.

Some may argue that this guideline should be a rule, but I don’t see it as that simple.

If you can draw cell boundaries around each sub-platform, that will simplify a lot of your design. However, the practicality of a cell per sub-platform depends on your system’s use case and requirements.

If your customer journey requires low latency, having each sub-platform act as a Cell can impact your performance.

Having too many Cells also creates operational complexity, which can cause just as many issues as you are trying to prevent with Cell-based Architecture.

It’s okay to have a cell contain multiple sub-platforms; you must design it accordingly.

  • Deploy all components within a Cell together.

I firmly believe that a sub-platform’s components should be deployed together, as this reduces the complexity of releases and testing. Still, I don’t prescribe forcing Cells with multiple sub-platforms to follow this approach.

Deploying the whole Cell as one is a great practice, but it is also okay to do this at a sub-platform level.

Use discretion; this one breaks down to operational overhead, and tooling & team maturity.

  • Use Natural Boundaries to define Cell Boundaries.

A natural boundary is when a customer journey transitions from one type of architecture pattern to another, like a real-time system (REST APIs) to a batch or event-based system (Message Broker).

A real-time system takes a different approach and requires different resilience and performance from an event-based system. These changes in requirements and flow are great places to define Cell boundaries.

This guideline is not a rule, though. Sometimes, you may want to bring multiple sub-platforms and workloads into a single cell, which may mean not defining a boundary at these transition points.

By Example

Let’s explore an example system to help understand the above approach to defining Cells.

In this Example, a simple backend API calls multiple microservices (using an orchestrated microservice pattern) and triggers events to a set of event-driven microservices.

Following our principle of natural borders, the most apparent boundary is where the customer journey goes from API calls to event messages.

The event-driven systems that perform post-processing can be one Cell, while the APIs can be another.

Benefits:

  • Microservice-to-microservice calls are local within each Cell, which improves latency and reduces failure points.
  • APIs and Event-based systems can have different failover mechanisms.
  • Establishing these as two sub-platforms makes testing and releasing easier as there is a clear contract, and we can test them independently.

Why it works:

  • APIs do not have a hard dependency on event-based systems to finalize processing.
  • The event-based system has different needs and SLAs.
  • The Cells do not share the same database (a rule in microservices that applies to Cells).

Final Thoughts

While I covered many principles for defining boundaries, remember that each situation and use case is different. Guidelines are not the same as rules; they can be broken when reasonable.

However, remember the core concepts behind cell-based architecture when ignoring any guidelines.

By creating independent Cells that operate without reliance on a central dependency, you can isolate and reduce the impact and frequency of failures.

Remember these core concepts while focusing on reducing the number of times a request crosses cells, keeping cells small and manageable, and using natural boundaries.

If you do, you’ll have a resilient and performant architecture.

How to deal with parameters for whole-cell modelling

Mike's Notes

Pipi has thousands of parameters, which make it challenging to finely adjust for desired system-level emergent properties.

How to Deal With Parameters for Whole-Cell Modelling is a paper published in the Journal of the Royal Society in 2017. I found the paper listed in the publications from the Theoretical Systems Biology Group at Melbourne University, led by Prof. Michael Stumpf. They are dealing with the same issues. This Research Group could be a great resource.

Resources

References

  • How to Deal With Parameters for Whole-Cell Modelling

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

17/05/2025

Article

By: 
theosybio.com: 25/12/2023

Most models in cell biology are either based on simple networks or stoichiometric metabolic models, or deal only with small pathways. Ultimately we will require models of whole cells. We are interested in combining approaches from text-mining, bioinformatics, comparative genomics, statistical inference, machine learning, and mathematical modelling to arrive at models for whole cells. In the first instance, we are focusing on bacteria.

Ultimately, such models are 

  1. the most stringent test of our understanding; and 
  2. an essential prerequisite for applying rational design and engineering approaches to biological systems. Maintaining the balance of model complexity to explanatory power is a conceptually hugely exciting problem, and tackling parameter inference for thousands of parameters is technically equally exciting.

Representative Publications

WholeCellViz

Mike's Notes

WholeCellViz is a web-based software program for visually analysing whole-cell simulations. Pipi's internal architecture uses many of the same techniques.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

17/05/2025

WholeCellViz

By: 
WholeCellViz: 02/12/2023




Markus Covert and Mycoplasma

Mike's Notes

This is part of why I rebuilt Pipi 6 from memory.

Resources

References

  • Fundamentals of Systems Biology

Repository

  • Home > Ajabbi Research > Library > Authors > Markus Covert
  • Home > Handbook > 

Last Updated

11/05/2025

Markus Covert and Mycoplasma

By: Mike Peters
On a Sandy Beach: 10/03/2022

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

In 2014, I read an article in Scientific American by Markus Covert at Stanford about the successful computer cellular simulation of Mycoplasma. It was a fascinating article that made me think about Pipi and whether it could have been better built during 2005-2008.

When my wife and I left Christchurch in 2014 to start a new life, I became curious about modern cloud computing and read a great deal. Then, I realised that PIPI was a very early form of cloud computing, and many of its features were 10 years ahead of their time. What a waste!

By 2016, I was mad about missing the opportunity and decided to rebuild Pipi as a core platform from memory.

From 2017 to 2019, Pipi 6 was built by fusing the rebuilt core platform with Covert Lab's open-source cellular simulation software. This process was challenging and resulted in an unusual architecture. Every process was given a random probability, with many positive and negative feedback loops. It was like composing music. (In hindsight, synesthesia helped a lot.)

From Wikipedia

Markus W. Covert (born April 24, 1973) 

is a researcher and professor of bioengineering at Stanford University who led the simulation of the first organism in software.[1][2][3] Covert leads an interdisciplinary lab of approximately 10 graduate students and post-doctoral scholars.[4]



From Covert Lab

Scientists Successfully Model a Living Cell with Software

Mike's Notes

This article I read in Scientific American led me to rebuild Pipi.

Resources

  • https://www.scientificamerican.com/article/scientists-successfully-model-a-living-cell-with-software/

References

  • Scientists Successfully Model a Living Cell with Software

Repository

  • Home > Ajabbi Research > Library > Authors > Markus Covert
  • Home > Handbook > 

Last Updated

11/05/2025

Scientists Successfully Model a Living Cell with Software

By: Marcus Covert
Scientific American: 01/01/2014

Reprinted from Scientific American, Jan 1 2014

In creating the first complete computer model of an entire single-celled organism, biologists are forging a powerful new kind of tool for illuminating how life works.

The crucial insight came to me as I leisurely rode my bike home from work. It was Valentine's Day, 2008. While I cruised along, my mind mulled over a problem that had been preoccupying me and others in my field for more than a decade. Was there some way to simulate life—including all the marvelous, mysterious and maddeningly complex biochemistry that makes it work-in software?

A working computer model of living cells, even if it were somewhat sketchy and not quite accurate, would be a fantastically useful tool. Research biologists could try out ideas for experiments before committing time and money to actually do them in the laboratory. Drug developers, for example, could accelerate their search for new antibiotics by homing in on molecules whose inhibition would most disrupt a bacterium. Bioengineers like myself could transplant and rewire the genes of virtual microorganisms to design modified strains having special traits—the ability to fluoresce when infected by a certain virus, say, or perhaps the power to extract hydrogen gas from petroleum—without the risks involved in altering real microbes. Eventually, if we can learn to make models sophisticated enough to simulate human cells, these tools could transform medical research by giving investigators a way to conduct studies that are currently impractical because many kinds of human cells cannot be cultured.

But all that seemed like a pipe dream without a practical way to untangle the web of interlinked chemical reactions and physical connections that make living cells tick. Many previous attempts, by my lab at Stanford University as well as others, had run into roadblocks; some had failed outright.

But as I pedaled slowly through the campus that winter evening, I thought about the work I had been doing recently to record images and video of single living cells. That's when it hit me-a way to make a realistic, functional simulator: choose one of the simplest single-celled microbes out there, a bacterium called Mycoplasma genitalium, and build a model of an individual germ. Limiting the simulation to just one cell would simplify the problem enough that we could, in principle, include every bit of biology known to occur in that cell—the unwinding of every rung of its twisted DNA ladder, the transcription of every message in that DNA into an RNA copy, the manufacture of every enzyme and other protein made from those RNA instructions, and the interactions among every one of those actors and many others, all building to cause the cell to grow and eventually divide into two "daughters." The simulation would generate, nearly from first principles, the entire drama of single-celled life.

Previous attempts had always tried to simulate a whole colony of cells because that is how almost all the data we have on cell behavior were collected: from populations, not individuals. Advances in both biotechnology and computing, however, had started to make single-cell studies much easier to do. Now, I realised, the tools were at hand to try a different approach.

Ideas whirred around in my head. The minute I reached home, I started sketching out plans for a simulator. The next morning, I began writing software code for just a couple of the many, many distinct processes that go on in a living microorganism. Within a week, I had completed several prototype modules, each one a software representation of a particular cellular process. The modules were producing output that looked fairly realistic.

I showed the work to a handful of other biologists. Most of them thought I was nuts. But I felt I was on to something, and two exceptional and daring graduate students, Jonathan R. Karr and Jayodita C. Sanghvi, saw enough potential in the approach that they agreed to work with me on the project.

Completing this model would mean creating dozens of such modules, combing through nearly 1,000 scientific articles for biochemical data, and then using those values to constrain and tweak thousands of parameters, such as how tightly enzymes bind to their target molecules and how often DNA-reading proteins bump one another off the double helix. I suspected that, even with the diligent help of collaborators and graduate students, the project would take years—but I also had a hunch that, at the end, it would work. There was no way to know for sure, except to try.

A Grand Challenge

As we set our sights on summiting this mountain, we took inspiration from the researchers who first dreamed of modeling life. In 1984 Harold Morowitz, then at Yale University, laid out the general route. He observed at the time that the simplest bacteria that biologists had been able to culture, the mycoplasmas, were a logical place to start. In addition to being very small and relatively simple, two species of Mycoplasma cause disease in humans: the sexually transmitted, parasitic germ M. genitalium, which thrives in the vaginal and urinary tracts, and M. pneumoniae, which can cause walking pneumonia. A model of either species could be quite medically useful, as well as a source of insight into basic biology.

The first step, Morowitz proposed, should be to sequence the genome of the selected microbe. J. Craig Venter and his colleagues at The Institute for Genome Research (TIGR)completed that task for M. genitalium in 1995; it has just 525 genes. (Human cells, in contrast, have more than 20,000.)

I was a graduate student in San Diego when, four years later, the TIGR team concluded that only 400 or so of those genes are essential to sustain life (as long as the microbes are grown in a rich culture medium). Venter and his co-workers went on to found Celera and race the federal government to sequence the human genome. They synthesised the essential genes of one Mycoplasma species and showed they functioned in a cell.

To me and other young biologists in the late 1990s, this gang was Led Zeppelin: iconoclastic, larger-than-life personalities playing music we had never heard before. Clyde Hutchinson, one of the biologists in Venter's band, said that the ultimate test of our understanding of simple cells would come when someone modeled one in a computer. You can build a functional cell in the lab by combining pieces without understanding every detail of how they fit together. The same is not true of software.

Morowitz, too, had called for building a cell simulator based on genome data from Mycoplasma. He argued that "every experiment that can be carried out in the lab can also be carried out on the computer. The extent to which these[experimental and simulation results] match measures the completeness of the paradigm of molecular biology"-our working theory of how the DNA and other biomolecules in the cell interact to yield life as we know it. As we put the puzzle together, in other words, it becomes more obvious which pieces and which interactions our theory is missing.

Although high-throughput sequencers and robotic lab equipment have greatly accelerated the search for the missing pieces, the floods of DNA sequences and gene activity patterns that they generate do not come with explanations for how the parts all fit together. The pioneering geneticist Sydney Brenner has called such work "low-input, high-throughput, no-output" biology because too often the experiments are not driven by hypotheses and yield disappointingly few insights about the larger systems that make life function-or malfunction.

This situation partly explains why, despite headlines regularly proclaiming the discovery of new genes associated with cancer, obesity or diabetes, cures for these diseases remain frustratingly elusive. It appears that cures will come only when we untangle the dozens or even hundreds off actors that interact, sometimes in unintuitive ways, to cause these illnesses.

The pioneers of cell modeling understood that simulations of whole cells that included all cellular components and their webs of interactions would be powerful tools for making sense of such jumbled, piecemeal data. By its nature, a whole-cell simulator would distill a comprehensive set of hypotheses about what is going on inside a cell into rigorous, mathematical algorithms. The cartoon like sketches one often sees in journal articles showing that factor X regulates gene Y ... somehow ... are not nearly precise enough for software. Programmers express these processes as equations—one of the simpler examples is Y = aX + b— even if they have to make educated guesses as to the values of variables such as a and b. This demand for precision ultimately reveals which laboratory experiments must be done to fill holes in knowledge of reaction rates and other quantities.

At the same time, it was clear that once models had been verified as accurate, they would take the place of some experiments, saving the costly "wet" work for questions not answerable by simulations alone. And simulated experiments that generated surprising results would help investigators to prioritise their research and increase the pace of scientific discovery. In fact, models offered such tempting tools for untangling cause and effect that, in 2001, Masaru Tomita of Keio University in Japan called whole-cell simulation "a grand challenge of the 21st century."

When still a graduate student, I was impressed by the early results of the leading cell modelers of the time [see box], and I became obsessed with this grand challenge. Even as I set up my own lab and focused on developing techniques for imaging single cells, the challenge remained in my thoughts. And then, on that February bicycle ride home, I saw a way to meet it.

Two Crucial Insights

It was clear that before we could simulate the life cycle of amicrobial species accurately enough to mimic its complex behaviors and make new discoveries in biology, we would have to solve three problems. First, we needed to encode all the functions that matter—from the flow of energy, nutrients and reaction products through the cell (that is, its metabolism), to the synthesis and decay of DNA, RNA and protein, to the activity of myriad enzymes—into mathematical formulas and software algorithms. Second, we had to come up with an overarching framework to integrate all these functions. The final problem was in many ways the hardest: to set upper and lower limits for each of the 1,700-odd parameters in the model so that they took on values that were biologically accurate—or at least in the right ballpark.

I understood that no matter how exhaustively we scrutinised the literature about M. genitalium and its close relations for those parameters (Karr, Sanghvi and I eventually spent two years culling data from some 900 papers), we would have to make do in some cases by making educated guesses or by using results from experiments on very different kinds of bacteria, such as Escherichia coli, to obtain certain numbers, such as how long RNA transcripts hang around in the cell, on average, before enzymes rip them apart to recycle their pieces. Without a way to constrain and check those guesses, we had no hope of success.

In that aha! moment in 2008, I had realised that modeling a single cell—rather than a bunch of cells, as almost all previous studies had done—could give us that constraint we needed. Consider growth and reproduction. A large population of cells grows incrementally; the birth or death of an individual cell does not change things much. But for a single cell, division is a very dramatic event. Before it splits in two, the organism has to double its mass—and not just its overall mass. The amounts of DNA, cell membrane and every kind of protein needed for survival must each double. If the scope of the model is constrained to a single cell, the computer can actually count and track every molecule during the entire life cycle. It can check whether all the numbers balance as one cell becomes two.

Moreover, a single cell reproduces at essentially a set pace.

M.genitalium, for example, typically divides every nine to 10 hours in a normal lab environment. It rarely takes fewer than six hours or more than 15. The requirement that the cell must duplicate all of its contents on this strict schedule would allow us to choose plausible ranges for many variables that would otherwise have been indeterminate, such as those that control when replication of the DNA begins.

I put together a team of physicists, biologists, modelers and even a former Google software engineer, and we discussed what mathematical approaches to use. Michael Shuler, a biomedical engineer at Cornell University who was a pioneer in cell simulation, had built impressive models from ordinary differential equations. Bernhard Palsson, under whom I studied in San Diego, had developed a powerful technique, called flux-balance analysis, that worked well for modeling metabolism. But others had shown that random chance is an important element in gene transcription, and cell division obviously involves a change in the geometry of the cell membrane; those other methods would not address these aspects. Even as a grad student, I had realised that no one technique could model all the functions of a cell; indeed, my dissertation had demonstrated a way to link two distinct mathematical approaches into a single simulator.

We decided, therefore, to create the whole-cell model as a collection of 28 distinct modules, each of which uses the algorithm that best suits the biological process and the degree of knowledge we have about it [see box ]. This strategy led to a patchwork collection of mathematical procedures, however. We needed to sew them all together somehow into one cohesive whole.

I thought back to an undergraduate course I had taken on chemical plant design. For the final class project, we used a powerful simulator package called HYSYS to sketch out a large refinery. HYSYS let us design each principal reaction to occur in a separate vessel. Pipes then connected the output of one vessel to the inputs of others. This framework connected many different kinds of chemical operations into an orderly, predictable system.

It occurred to me that this approach, with some modification, might work for our cell simulator if I was willing to make an important, simplifying assumption: that even though all these biological processes occur simultaneously in a living cell, their actions are effectively independent over periods of less than a second. If that assumption was sound, we could divide the life of the cell into one-second ticks of the clock and run each of the 28 modules, in order, for one tick before updating the pool of cell variables. The model would capture all the interconnectedness of biochemistry—the reliance of gene transcription and DNA synthesis on the energy and nucleotides produced by metabolism, for example—but only on timescales greater than one second.

We had no theoretical proof that this would work. It was a leap of faith.

While constructing our virtual cell, we put in software sensors to measure what was going on inside. Every run of the simulator, covering the entire life cycle of a single cell, churned out 500 megabytes of data. The numerical output flowed into a kind of instrument panel—a collection of dozens of charts and visualisations that, when printed, completely filled a binder.

The results were frustrating at first. For months, as we debugged the code, refined the math, and added more and better lab-derived constraints for the parameters, the cell refused to divide or behaved erratically. For a while it produced huge amounts of the amino acid alanine and very little else.

Then, one day, our cybernetic germ reached the end of its cell cycle and divided successfully. Even more exciting, the doubling time was around nine hours, just like that of living M. genitalium. Many other readings were still way off , but we felt then that success was within reach.

Months later I was at a two-day conference in Bethesda, Md., when I was called to the hotel's front desk between sessions.

"Dr. Covert? This package came for you."

Back in my room, I peeled open the box and pulled out a binder. As I spent the next hours flipping through hundreds of pages of plots and complex visualisations, my heart began to race. The great majority of the data looked just like one would expect from an actual growing cell. And there mainder was intriguing—unexpected but biologically plausible. That is when I knew we had reached the summit of that mountain that loomed so large years ago. The first computer model of an entire living organism was up and running. What would it teach us?

A Window into the Life of a Cell

After about a year of applying our new tool, we still see fascinating things every time we peer inside the workings of the virtual microorganism as it handles the millions of details involved in living and reproducing. We found, to our surprise, that proteins knock one another off the DNA shockingly often—about 30,000 times during every nine-hour life cycle. We also discovered that the microbe's remarkably stable doubling period is actually an emergent property that arises from the complex interplay between two distinct phases of replication, each of which independently varies wildly in duration. And the second-by-second records of the cell's behavior have allowed us to explain why it is that the cell stops dividing immediately when certain genes are disabled but reproduces another 10 times before dying when other essential genes are turned off. Those additional rounds of division can happen whenever the cell stockpiles more copies of the protein made from the gene than it needs in one lifetime—the extra is passed on to its descendants, which perish only when the store at last runs out. These initial results are exciting, but we may need years to understand everything that these simulations are telling us about how these microbes, and cells in general, function.

Our work with M. genitalium is only the first of many steps on the way to modeling human cells or tissues at the level of genes and molecules. The model that we have today is far from perfect, and mycoplasmas are about as simple as self-sustaining life-forms get. We have made all our simulations, source code, knowledge base, visualisation code and experimental data freely available online, and we and other investigators are already working to improve the simulator and extend it to a variety of organisms, such as E. coli and the yeast Saccharomyces cerevisiae, both of which are ubiquitous in academic and industrial labs.

In these species, the regulation of genes is much more complex, and the location within the cell at which events occur is far more important. When those issues have been addressed, I anticipate that the next target will be a mouse or human cell: most likely a cell, such as a macrophage (an attack cell in the immune system), that can be readily cultured and employed as a source of measurements to both tune and validate the model.

I cannot guess how far we are today from such technology. Compared with bacteria, human cells have many more compartments and exhibit far greater genetic control, much of which remains mysterious. Moreover, as team players within multicellular tissues, human cells interact more intimately with other cell types than bacteria do.

On February 13, 2008, I would have said that we were at least a decade away from the goal of modelling the simplest cell, and I would not have even considered attempting to model anything more complex. Now we can at least conceive of trying to simulate a human cell—if only to see how the software fails, which will illuminate the many things we still need to learn about our own cells. Even that would be a pretty big step.