Genesis 2

Genesis 2 is the scripting language of GENESIS, the GEneral NEural SImulation System - a simulation platform written at Caltech in the late 1980s to let neuroscientists build biologically realistic models of nerve cells and the networks they form. The language itself is deliberately small: three data types, C-shaped control flow, and a few dozen commands. Almost all of its expressive power comes from what those commands operate on, a tree of simulation objects implemented in C and wired together by message passing. Learning Genesis 2 is less about learning syntax than about learning the object library.

The name is a retronym. From 1988 until the mid-2000s the software was simply GENESIS; the label “GENESIS 2” came into use only once GENESIS 3 was under development and the project needed a way to distinguish the stable, procedural, script-driven original from its declarative successor. The project’s own home page adopted the split, describing genesis-sim.org/GENESIS as “the home page for the stable, ‘classic’ GENESIS 2 simulator.”

History and Origins

GENESIS was built by Matthew Wilson, Upinder Bhalla, John Uhley and James Bower in the Division of Biology at Caltech, and released in June 1988 for the first annual Methods in Computational Neuroscience course at the Marine Biological Laboratory in Woods Hole. That teaching context shaped everything about it. The system had to be usable by biologists in a summer course, not only by the people who wrote it, so it shipped with a graphical interface - XODUS, the X-based Output and Display Utility for Simulators - and a command language that could be typed at a prompt as readily as saved in a file. Public release beyond the course followed in July 1990.

At the 1988 NIPS conference the group presented the system under what was reportedly a slightly different expansion of the acronym: GEneral NEtwork SImulation System. The paper describes the scripting layer as “a set of simulator and interface functions that can be executed interactively from the keyboard or from text files storing command sequences (scripts),” providing “arithmetic operations and program control functions such as looping, conditional statements, and subprograms or macros.” That is a fair description of the language a quarter-century later. By the time of the second edition of The Book of GENESIS in 1998, the middle word had become NEural, reflecting where the user base had actually gone.

The design constraints of 1988 are visible throughout. The paper reports the simulator at about 20,000 lines of C with a comparable amount of graphics code, and, according to the same source, executables of roughly a megabyte and per-element memory costs on the order of a hundred bytes - the kind of accounting a modeller needed when deciding how large a network would fit in memory. The one published performance figure is similarly period-specific: the piriform cortex model is reported as running at approximately one second per simulated time step on a Sun workstation of the day, with the machine’s few megabytes of RAM as the binding constraint. That is a single 1988 model measured on a single 1988 machine with no comparison baseline, not a general benchmark, and the paper is careful to say that “the overall efficiency of the GENESIS system is highly simulation specific.”

Design Philosophy

Three ideas hold the language together.

Objects and elements. GENESIS distinguishes an object - a compiled C template, such as compartment or a Hodgkin-Huxley channel - from an element, an instance of that template living in the simulation. The documentation is explicit that this inverts the usual vocabulary: a GENESIS object is what Java or C++ would call a class, and a GENESIS element is what they would call an object. Adding new physics to GENESIS means writing a new object in C and linking it in; the scripting language never had to grow to accommodate it.

A filesystem for the model. Elements live in a hierarchy addressed exactly like a Unix path. /net/cell[1]/dend[2]/GABA names an inhibitory synaptic conductance on dendritic compartment 2 of cell 1 of a network. Indices, wildcards and relative paths all work as a shell user would expect. This is the single most quoted design decision in GENESIS, and it made scripts that build thousand-cell networks by looping over indices feel natural rather than clever.

Messages, not calls. Elements do not invoke each other. They exchange messages, established once by addmsg and delivered by the simulation engine on every step. Each object knows its own fields and the actions it performs when the engine issues, say, a PROCESS step - solving the Hodgkin-Huxley equations for a channel, or plotting a point for a graph. The script’s job is construction and control; the numerics happen in C.

Scripting as interface, not as afterthought. Because objects were precompiled and linked in, a modeller could develop a simulation interactively without ever quitting to recompile. In 1988 this was the difference between a usable tool and an unusable one.

The Language

SLI - the Script Language Interpreter - is a shell-like interpretive environment with C-like syntax. Commands take the form routine-name arg1 arg2 -option optarg, statements end at a newline or semicolon, and expressions in braces are evaluated and substituted into arguments. Operating system commands can be run from the same prompt.

There are exactly three variable types:

int    a
float  PI = 3.141593
str    hi = "hello there"

Variables declared inside a function are local; those declared at script level are global. Strings concatenate with @. Control flow is if/elif/else/end, while/end, C-style for (init; test; incr)/end, and foreach/end over an argument list. Functions are declared and terminated by keyword:

function function-name [(arg1 [, arg ...])]
  statements
end

The canonical first program is tutorial1.g, a single compartment with a current injection and a plot:

//genesis script for a simple compartment simulation (Tutorial #1)

// create a parent element
create neutral /cell

// create an instance of the compartment object
create compartment /cell/soma

// set some internal fields
setfield /cell/soma Rm 10 Cm 2 Em 25 inject 5

// create and display a graph inside a form
create xform /data
create xgraph /data/voltage
xshow /data

// set up a message (PLOT Vm) to the graph
addmsg /cell/soma /data/voltage PLOT Vm *volts *red
addmsg /cell/soma /data/voltage PLOT inject *current *blue

// make some buttons to execute simulation commands
create xbutton /data/RESET -script reset
create xbutton /data/RUN -script "step 100"
create xbutton /data/QUIT -script quit

check // perform a consistency check for each element
reset // initialize each element before starting the simulation

Everything characteristic of the language is in those twenty lines. create instantiates an object at a path. setfield assigns named fields. addmsg wires a source to a destination with a message type and arguments. Widgets are elements too, created and messaged the same way as compartments - which is why a GUI can be assembled by the same script that assembles the model. And check, reset, step are the simulation control verbs, available identically from a script, a button, or the prompt.

Evolution

The 2.x line was maintained for two decades, largely by Dave Beeman, who announced essentially every release on the BABEL users list.

The pattern is unusual and worth noticing: twice the project declared a final release, and twice the user community kept contributing enough that another one became necessary. The 2.4 release notes read like a list of things people needed and wrote themselves - spike-timing-dependent plasticity objects that work with the fast hsolve integrator, network connection commands supporting distance-dependent probabilities and periodic boundary conditions, the chemesis library for calcium and second-messenger modelling, and an autoconf build system, so that ./configure was intended to work on then-current Linux and macOS systems.

Platform support followed the same drift. The 1988 system targeted Unix and the X Window System, and was developed on the Sun workstations of the era before being ported to other contemporary Unix hardware. The project’s later documentation states that GENESIS runs “under most UNIX-based systems with the X Window System, including Linux, OS/X and Windows with Cygwin,” though the project publishes no comprehensive tested-platform matrix, and the 2.4 release reportedly added precompiled Cygwin binaries for Windows. The 2.x releases are distributed as open source under the GPL.

Current Relevance

Genesis 2 is dormant rather than dead, and the distinction matters. There is no active development: the last release was in 2014, the GitHub repository’s most recent push was in November 2021, and the genesis-sim.org documentation tree - reference manual, tutorials, the BABEL archives going back to 1994 - is now most reliably read through the Internet Archive. New compartmental modelling work overwhelmingly starts in NEURON, Brian, NEST or MOOSE with a Python interface, not in a bespoke shell language.

But a large body of published models is written in it, and both of its intended successors were designed around that fact. GENESIS 3, built on Neurospaces, made backward compatibility with the older procedural scripts an explicit design goal. MOOSE, from Bhalla’s group at the National Centre for Biological Sciences in Bangalore, reimplements GENESIS capabilities with backward compatibility while exposing a modern Python interface, and still reads GENESIS kkit chemical models and cell.p morphology files. The language stopped being written; its file formats did not stop being read.

Why It Matters

GENESIS was the first broad-scale modelling system in computational biology to actively encourage modellers to develop and share model components rather than each writing their own simulator from scratch - a claim the project makes for itself, and one that its BABEL archive and shared model library substantially support. That cultural contribution outweighs the technical one.

The language’s specific bequest is a set of conventions that felt obvious afterwards and were not obvious in 1988: that a simulation should be a named hierarchy you can browse and address like a filesystem; that components should communicate through declared messages rather than direct calls, so the engine owns the scheduling; that the numerical core should be compiled and the model description interpreted, so that model building is interactive; and that the same scripting layer should drive the model, the solver, and the user interface. MOOSE’s Python bindings and the model-description formats that grew into NeuroML inhabit territory GENESIS mapped; NEURON’s hoc, which predates GENESIS, arrived at a comparable arrangement independently.

It is also a clean specimen of a language type that has since largely vanished: the domain-specific command language, small enough to learn in an afternoon, whose real vocabulary is a library of compiled objects rather than the grammar itself. Genesis 2 got roughly twenty-five years of productive use out of three data types and a for loop, which is a better return on syntactic economy than most languages manage.

Further Reading

• Wilson, M. A., Bhalla, U. S., Uhley, J. D., and Bower, J. M. (1988). GENESIS: A System for Simulating Neural Networks. Advances in Neural Information Processing Systems 1.
• Bower, J. M., and Beeman, D. The Book of GENESIS: Exploring Realistic Neural Models with the GEneral NEural SImulation System, 2nd edition, Springer-Verlag, 1998.
• The GENESIS Reference Manual, chapter on the Script Language Interpreter.
• The genesis-sim/genesis-2.4 repository on GitHub, for the 2.4 sources and post-release fixes.