Genetic Algorithm for Bio-Electric Exploration

Name Last Update
examples Loading commit data...
gabee Loading commit data...
README.md Loading commit data...
ez-install-tufts.sh Loading commit data...


GABEE (Genetic Algorithm for Bio-Electric Exploration) is a genetic algorithm harness designed to search for autonomous pattern-forming phenomena. It runs parallel copies of a subsidiary simulation (currently BETSE -- the Bio-Electric Tissue Simulation Engine), either locally or on a compute cluster configured with the SLURM cluster-management system, and it selects among the resulting patterns with a user-specified fitness function.


GABEE is an optimization and search tool for pattern-forming tissue simulations, automatically seeking simulation parameters that lead to desired pattern properties. GABEE works by taking a user-supplied template configuration for a BETSE simulation and randomly changing the values of selected parameters. A population of modified configurations is simulated concurrently, the results are evaluated, and then a new population is generated by preferentially selecting good results from the previous generation and further mutating their configurations. Progress can be monitored with real-time plots (rendered via Matplotlib), and individuals of interest can be extracted from the population history or the final population.

For GABEE, an individual configuration consists of a directory of arbitrary files, which is replicated and modified for each distinct simulation run. Mutations are applied by patching specified YAML-formatted configuration files within a configuration directory. Mutable loci are specified with a user-supplied YAML "patch file" that identifies values that may be modified and under what parameters (max, min, step size, etc.).

When a round of simulations are finished, cell-by-cell output results from each individual simulation are automatically imported and are evaluated with a user-supplied "fitness function". A library of template functions for common operations is included, so that simple fitness functions may be specified compactly from the command line.


For the Tufts cluster and other similar clusters equipped with SLURM and Python 3, a quick and easy installation script is available. Otherwise, see more detailed instructions below. You will first need to obtain a cluster account and familiarize yourself with basic use of the cluster. You then connect to the cluster login node via SSH, for example, as follows:

ssh -YC mbrods01@login.cluster.tufts.edu

X11 forwarding (-Y) is required to be able to run GABEE. More information about connecting to the Tufts cluster is available here. If you are using Windows, it's recommended to install Cygwin to get SSH and X11, although you can also use the web-based FastX login portal.

Once you are connected, use the following commands to download and install GABEE into the "gabee-install" directory (you may substitute another location name):

mkdir gabee-install
cd gabee-install
wget https://gitlab.com/micahbro/ga-scratchwork/raw/master/ez-install-tufts.sh
sh ez-install-tufts.sh

This will download the latest version of GABEE, an appropriate version of BETSE, and all dependencies, installing into a local Python venv. BETSE and GABEE may then be run via the betse.sh and gabee.sh scripts created in the install directory.

Installation Details

As with BETSE, GABEE is a Python 3 application. GABEE requires BETSE and all its dependencies to be available to the Python interpreter. BETSE can be run by GABEE as is, without any patches, so BETSE may be installed as per the instructions on its website. However it is recommended to install BETSE within a Python venv, especially on clusters where root access is unavailable. BETSE itself may be installed globally, included in PYTHONPATH, or accessed from the current directory. The GABEE package must be included in PYTHONPATH or placed in the current directory. GABEE requires no additional dependencies.

A simple script is included for fetching and installing BETSE, GABEE, and all dependencies for a single (non-root) user on environments like the Tufts research cluster. (Slight modifications may be necessary on other SLURM clusters.) To invoke, CD to the directory you wish to install in and run the included ez-install-tufts.sh. (Note that this pulls fresh copies of everything via git and pip.) At the end, a gabee.sh will be created that handles all the work of starting the Python venv, setting PYTHONPATH, and launching GABEE. A betse.sh is similarly created for launching the associated copy of BETSE. If the setup script does not work for you, you will need to install BETSE, fetch GABEE, and configure Python manually. (See BETSE's detailed install instructions.) The complete GABEE source package can be fetched manually via git by issuing git clone https://gitlab.com/micahbro/ga-scratchwork.git.

As BETSE is continually evolving independently of GABEE, incompatible changes are occasionally introduced. The most recent commit of BETSE tested to be compatible is df15bd52. ez-install-tufts.sh automatically fetches this version. If you are adventurous, you may CD to the BETSE directory and issue git checkout master to switch to the latest (untested) version of BETSE. Most typically, the BETSE configuration format may have changed, and so the example configuration files may need adjustment.

Example session

Here is a typical example of using GABEE on a cluster:

[mbrods01@login001 ~]$ cd gabee-install  # Change to the directory where we ran the install script
[mbrods01@login001 ~/gabee-install]$ salloc -n 90 -t 6:00:00 --exclusive  # Request 90 CPUs from SLURM for up to 6h
  srun --x11=first --pty -N1 -n1   # Launch a one-cpu job (the master job) with X11
      --workpath testruns/examplerun/runs/          # Where to put configurations
      --templatepath testruns/examplerun/template/  # Template configuration
                                                    # (using defaults of config.yaml for configuration and patches.yaml for patches)
      --fitness "reduce_stdev() / (1 + reduce_rms(deltaval))"  # Use standard deviation of final Vmem (with a penalty on dVmem/dt) for fitness
      --popsize 89    # Population size (master job needs one CPU)
      --gen-count 80  # Number of generations to run
      --init-mix-rounds 50  # Avg number of mutations to introduce in
                            # first generation
      --save-trajectory testruns/examplerun/trajectory.yaml
      --monitor-image "RESULTS/sim_planaria_1/anim_while_solving/Vmem/Vmem_0000038.png"  # Live display an image file from best current individual

salloc: Granted job allocation 12254162

INFO: GABEE starting up...

<lots and lots of spam from BETSE...>

See ./gabee.sh --help or Command line options reference below for more options.

Other important options include --init-trajectory to resume a prior trajectory rather than generating a new population and --wait to keep GABEE and its plots open until they are manually dismissed by the user. Several additional options are available to adjust the properties of mutation and selection, to produce various diagnostic plots, and to limit the amount of concurrency to less than the total population size, if desired.

A typical run will take several hours to complete, depending on the complexity of the BETSE simulation and the number of generations requested. Progress is shown live plots, updated every generation. On the Tufts cluster, generations typically take 2-5 minutes each for simulations of similar complexity to the examples, and as many as 100 generations may be needed to reach steady state.

If you manually installed GABEE and BETSE rather than using the install script, you would use python -m gabee.cli instead of ./gabee.sh, and issue something like this:

[mbrods01@login001 ~]$ source envs/betsevenv/bin/activate  # Start up our Python venv (where we have installed BETSE's dependencies)
(betsevenv) [mbrods01@login001 ~]$ cd checkouts/betse      # Change to the directory where we have extracted both BETSE and GABEE packages
                                                           # (we're running from current directory rather than PYTHONPATH)
(betsevenv) [mbrods01@login001 ~/checkouts/betse]$ salloc -n 90 -t 6:00:00 --exclusive  # Request 90 CPUs from SLURM for up to 6h
salloc: Granted job allocation 12254162
(betsevenv) [mbrods01@login001 ~/checkouts/betse]$ srun --x11=first --pty -N1 -n1       # Launch a one-cpu job (the master job) with X11
    python -m gabee.cli

The template configuration in testruns/examplerun/template must be prepared in advance (with betse.sh config or otherwise). It is typically recommended to run betse.sh seed ahead of time on this template configuration, which will prepare a common cell cluster layout to be used by all mutated individuals. (If you used ez-install-tufts.sh, both these steps have been performed in advance for you for the examplerun configuration.) Otherwise, a new layout will be generated for every individual run, which will make the evolutionary trajectory noisier and slower (although results may be more robust to artifacts of cell shape and layout).

(Note: Generation start-up overhead can be reduced by replacing shared, read-only components of the template configuration, such as the BETSE world seed file, with symbolic links. For large cell clusters, the difference can be significant. In the future, this may be automated by GABEE.)

A patch file must also be placed in the template directory. The above example assumes the default config filename of config.yaml and patch filename of patches.yaml. Here is an example fragment of the patch file used above:

  - name: 'A'
    growth and decay:
      production rate:
          Name: prod_A
          Max: 10
      decay rate:
          Name: dec_A
          Max: 10
          Name: Km_A
          Max: 5.0
          Name: n_A
          Max: 5.0
  - name: 'B'
    growth and decay:
      production rate: 
          Name: prod_B
          Max: 10
      decay rate: 
          Name: dec_B
          Max: 10
          Name: Km_B
          Max: 5.0
          Name: n_B
          Max: 5.0

The structure here mirrors fragments of the target BETSE configuration file config.yaml, except for the introduction of $match blocks, each of which calls out a value that may be mutated. Within a $match block, Name: specifies a user-readable identifier for the locus, and Max: specifies the maximum value. (Zero is assumed to be the the minimum unless Min: is specified. Step size defaults to 10% of the total range unless Stepsize: is specified.) Initial parameter values are taken from the corresponding values in config.yaml unless specified explicitly with a Value: entry.

Patch files are described in more detail under Patch Files below.

The working path, where individual mutated configurations are stored, must have several GB free space (at a minimum) and must be shared among all cluster nodes. By default, GABEE deletes all individuals after their simulation completes, except for the top scoring individual in each generation and the individuals comprising the final generation. However, this still requires several GB, depending on the population size and the size of the BETSE simulation.

(On the Tufts cluster, the default home directory quota of 5GB can be inadequate. A convenient alternative location for the working path is under /cluster/shared/USERNAME, which is not backed up and in which old files are culled every 14 days, but which has no quota limit. You will need to copy out any configurations of interest before they are culled, or you will need to regenerate them later from a trajectory file using --rerun-trajectory.)

Example live monitoring plots:

Live fitness plot

Live output view

A complete sequence of the history of individuals and their fitnesses is available in the trajectory file (specified via --save-trajectory) in semi-human-readable YAML format. The final generation's population and its mutable parameter values are also included in the trajectory file. Details of an individual may be extracted from the individual's complete BETSE configuration file or from the delta_config.yaml file generated alongside each patched configuration -- a patch file augmented with the mutated parameter values. A shorter, human-readable YAML parameter summary can be extracted with a command such as the following:

[mbrods01@login001 ~/gabee-install]$ ./patchtool.sh
      --configfile testruns/examplerun/template/config.yaml
      --patchfile testruns/examplerun/runs/INDIV_tgqfpwmrc2607/delta_config.yaml

- {Max: 5.0, Name: Km_A, Value: 0.5}
- {OrigValue: 0.5}
- {Max: 5.0, Name: Km_B, Value: 0.5}
- {OrigValue: 0.5}
- {Max: 5.0, Name: Km_C, Value: 0.8513014695088492}
- {OrigValue: 1.0}
- {Max: 5.0, Name: Km_X, Value: 0.987428491916231}
- {OrigValue: 1.0}
- {Max: 5.0, Name: act_Km_C_A, Value: 0.7}
- {OrigValue: 0.7}
- {Max: 5.0, Name: act_n_C_A, Value: 3.0}
- {OrigValue: 3.0}
- {Max: 10, Name: dec_A, Value: 0.01}
- {OrigValue: 0.01}
- {Max: 10, Name: dec_B, Value: 0}
- {OrigValue: 0.01}
- {Max: 10, Name: dec_C, Value: 0}
- {OrigValue: 0.05}
- {Max: 10, Name: dec_X, Value: 1.0}
- {OrigValue: 1.0}
- {Max: 5.0, Name: inh_Km_X_B, Value: 0.4958488589573108}
- {OrigValue: 1.0}


(Substitute python -m gabee.patchtool for a manual installation.)

The final output figures from an existing trajectory file may be reviewed by passing --init-trajectory, --smoke-test, and --wait together. If the individuals' configuration directories still exist, you can also supply --aux-plot-func or --aux-plot-pointfunc to plot various functions of the best individuals' outputs. The combination of --monitor-image and --animate may also be used to view an animation of the selected images from the best individual of each generation. --rerun-trajectory may be used to regenerate the configuration directories of the best scoring individuals, optionally under new settings. (Note that you cannot regenerate configuration directories in-place; you must specify a suffix to add to the individuals' names. You can save an updated trajectory file pointing to the new configuration directories by combining --rerun-trajectory with --save-trajectory.)

Detailed Examples

Complete example config and patch files for a variety of substrates, along with fitness functions and output screenshots, are found in the Examples folder:

  • pureelectric -- Introductory, "pure bioelectric" examples

  • bistable -- Bistable memory in a pure bioelectric system

  • rdpattern -- "Reaction-diffusion"-like patterning examples using chemically gated channels

  • gradamp -- Polarization via amplification of a seed gradient in a chemically gated system

  • overfit-surgery -- Overfitting-prone attempt at polarization that can regenerate when sliced

  • spontanepol -- Spontaneous polarization in a chemically gated system

  • stripespot -- Stripes and spots in an extended "Reaction-diffusion"-like chemically gated system

Fitness Functions

Fitness functions report to GABEE how desirable a configuration is, distilling the results of a simulation run into a single number. Fitness functions are provided to GABEE as mathematical expressions in a simple Python-based mini-language. Through the use of this fitness language, GABEE can be adapted to select for an arbitrarily wide variety of goals. However, this does demand some ingenuity and design iteration to produce an effective fitness function for any particular goal. Several examples of fitness functions that have been shown to work well for particular goals of interest are showcased below and in the Examples folder.

Fitness functions will typically reflect multiple sub-goals -- for example, stability in time, certain properties in one part of the domain, certain properties in another part, or separate assessments for spectral properties and distributional properties. A fitness function is often constructed by designing metrics that reflect each of these sub-goals, then algebraically combining the metrics into a single large formula. Multiplication is frequently a good means of combination.

Fitness functions are supplied to GABEE on the command line (via --fitness). A fitness function typically consists of an arithmetic combination of one or more "reduction operators", functions that summarize information across all the cells of the cell cluster. The following are the built-in reduction operators:

  • reduce_sum() -- compute the sum

  • reduce_avg() -- compute the average

  • reduce_rms() -- compute the root-mean-square

  • reduce_stdev() -- compute the standard deviation

  • reduce_stat_moment(order) -- compute the normalized statistical moment of order order (3 = skewness, 4 = kurtosis)

  • dipole(axis = None) -- compute the dipole moment; optional argument axis supplies a vector to measure against, otherwise the magnitude of the dipole moment is returned

  • moment_magnitude(i) -- compute the magnitude of the i-th order spatial moment (simple non-orthogonal moments, adjusted to have zero mean response, normalized to size of cell cluster)

  • global_directionality(range = 30, steps = 6) -- compute a metric of anisotropy, or "directionality", due to the variance in power among different directional averages

By default, reduction operators operate on the value of Vmem in the final frame of the simulation. All of them accept an optional final argument, a "point function", that indicates the value to be summarized. A point function consists of an arithmetic combination of one or more of the following:

  • defval -- Vmem in the final frame ("default value")

  • deltaval -- The difference in Vmem between the final two frames

  • movingavg(range, func = defval) -- A circular moving average of defval (or another optionally supplied point function) over specified range (in microns)

  • medianfilter(range, func = defval) -- A circular median filter applied to defval (or other point function) over specified range (in microns)

  • absvariation(func = defval) -- Sum of absolute values of deltas between neighbors in defval (or other point function); integrate over a domain to compute "total variation"

  • neighborcount -- Number of Voronoi neighbors of the given cell (note that this is similar to but not presently identical to the number of neighbor cells in BETSE; useful for boundary detection)

  • imagemask(pathname, worldsize) -- True / 1 where the specified image file is black, False / 0 otherwise; compatible with BETSE geometry masks

  • posvec -- An (x, y) tuple of coordinates for the current cell (indexable with [0], [1])

Reduction operations can also be included in point function arithmetic expressions. For example, defval - reduce_avg() computes Vmem adjusted to zero mean.

The following mathematical functions can be incorporated in addition to the basic arithmetic and relational operators (+, -, *, /, **, >, <, >=, <=, ==, !=): abs, sqrt, exp, log, sin, cos, tan, atan, tanh, min, max, smax

Example -- A Gaussian fitness function (mean -35, standard deviation 10) that favors uniform Vmem values close to -35mV:

reduce_avg(exp(-(defval + 35) ** 2 / 100))

Example -- An image moment fitness function that favors large-scale, steady spatial patterns:

(moment_magnitude(1) + moment_magnitude(2)) / (1 + reduce_rms(deltaval))

Example -- A filtered "total variation" fitness function that favors stable spatial patterns with a length scale of several cells (not too fine, not too coarse):

reduce_avg(absvariation(movingavg(15))) / (1 + reduce_rms(deltaval))

Fitness sub-expressions may be restricted to particular regions via the within operator, which narrows the domain of reduction operators within its scope:

  • within(<region-expression>, <fitness-expression>)

where <region-expression> may be any point function, and the points where it evaluates to True or nonzero define the domain for <fitness-expression>. imagemask, neighborcount, and posvec expressions are typical choices for <region-expression>.

Fitness sub-expressions may also be evaluated at a different point in time of the simulation output with the atframe operator:

  • atframe(<frame-number>, <fitness-expression>)

where <frame-number> is a constant integer interpreted according to Python indexing conventions: zero represents the first snapshot frame, and negative numbers may be used in order to count backward from the last frame. The default frame is -1, the final frame.

Example -- Fitness function that selects for Vmem uniformly below -30mV early in the simulation (at frame 9), but below -30mV at the end of the simulation only outside a "spot" region, and otherwise above 30mV. tanh is used as a soft threshold function, and '200' is the world size (microns).

within(imagemask('testruns/examplerun/template/geo/circle/spot.png', 200),
       reduce_avg(1 + tanh(defval / 10 + 3))) *
  within(1 - imagemask('testruns/examplerun/template/geo/circle/spot.png', 200),
         reduce_avg(1 - tanh(defval / 10 + 3))) *
  atframe(9, reduce_avg(1 - tanh(defval / 10 + 3)))

The following miscellaneous functions are also available for use in fitness expressions:

  • trait('traitname') -- Value of the named trait in the individual's configuration
  • runtime -- Simulation running time for individual, in seconds

A simulation where BETSE exits with an error or fails to output sufficient data is automatically assigned zero fitness and reported as a failure in the GABEE monitoring plots. A run where the user-specified fitness function returns exactly zero is also reported as a failed run. Negative fitness values are allowed if using tournament selection (the default) but discouraged.

Patch Files

Patch files are special YAML configuration files that specify to GABEE what variables are available for mutation, how they may be mutated, and how the results are to be recorded in a BETSE configuration file. Patch files operate like a "find-and-replace" operation: They consist of fragments of BETSE configuration, each sufficient to identify a section of interest in the template configuration file, along with marked variables indicating which included values may be changed. Several reusable patch files are included with the GABEE examples. However, modifying or creating new patch files is commonly required, either for new simulation configurations or as BETSE's configuration format changes.

Patch files operate in a similar manner to regular expressions. The patch file represents a YAML expression that must "match" against the template configuration file. The patch file may omit elements, but the structure of a patch file mirrors the structure of the configuration file it targets. An easy way to construct a new patch file is to copy and paste the template configuration file and then slim it down by pruning sections that contain no mutable variables of interest. Each subsection should contain enough detail to uniquely identify it, but additional extraneous elements can be removed. Then, values to be targeted for mutation may be replaced with $match blocks (described below).

A mapping (also known as a dictionary or associative array) in a patch file is considered to match if every key/value pair it contains matches some key/value pair in the corresponding mapping in the template configuration. Additional non-matching key/value pairs in the template configuration are ignored. A list in a patch file is considered to match if every element it contains matches elements appearing, in the same order, in the corresponding list in the template configuration. Additional elements appearing before, after, or in between matched elements are ignored. (One must take care that these undesired elements do not inadvertently match a listed element.) A key/value pair is considered to match if the keys are exactly identical and the value expression in the patch file matches the value in the template configuration. Comparisons of strings are case-sensitive. If a given patch file fails to match the associated template configuration, GABEE will quit with an error and print out a representation of the configuration elements that failed to match.

Any value or expression may be replaced in the patch file by a $match block, indicating a mutable variable. (Note that only certain types are supported for mutation, currently limited to floating-point numbers, Boolean values, and sets of symbolic values.) $match blocks automatically match against any corresponding expression without regard to type or value, unless further restricted by a Containing subexpression. The following fields can be used inside a $match: block:

  • Name: -- Specifies a name for the mutable trait. Must be unique.

  • Value: -- Specifies the initial value to be used for the trait. If Value is not specified, the corresponding value from the template configuration is used. (Does not restrict what value may appear in the template configuration.)

  • Min: -- Specifies the lower bound for numerical traits. Defaults to zero.

  • Max: -- Specifies the upper bound for numerical traits. Required for numerical traits.

  • Logscale: True -- Specifies that mutations operate on the logarithm of the trait value. Requires a positive Min value. Recommended for values that range over many orders of magnitude.

  • Stepsize: -- Specifies the fraction of total range for a typical numerical mutation (exact interpretation depends on mutation distribution). Defaults to 0.1 (10%), or 0.2 (20%) if Logscale: True is specified.

  • Mutable: False -- Specifies that evolution of the given trait is disabled.

  • Derived: -- Specifies a Python expression for procedurally computing the value of the trait based on other traits, retrieved via the trait('<name>') function, where <name> is the name of the target trait as specified under Name. Trait will have no heritable value of its own and is not directly mutated.

  • Containing: -- Specifies additional details about what the matched value or expression may be. Required for set traits.

In Containing subexpressions, the following fields may be used:

  • Type: -- Determines the type of the matched trait. Either set or singleton.

  • Alternatives: -- A list of alternative possible YAML expressions. A singleton must match one of the alternatives, while a set must consist of a list of matching items.

Example -- A patch file fragment allowing any combination of the supported voltage-gated K+ channels and total conductivity between 0 and 10-5 S/m2 :

voltage gated K+:
    turn on: True
    apply to: ['all']
    max value:
        Name: vg_K_max
        Max: 1.0e-5
    channel type:
        Name: vg_K_types
          Type: set
          Alternatives: ['Kv1p1', 'Kv1p2', 'Kv1p3', 'Kv1p5', 'K_Slow', 'K_Fast', 'Kv2p1']

Example -- A patch file fragment allowing membrane sodium permeability to vary between 10-15 and 10-20 (logarithmically weighted) and enforcing that identical permeability is specified in each of two regions, "all" and "spot":

tissue profile definition:
        - type: tissue
          name: all            # unique profile name
          diffusion constants: # constants applied to all targeted cells
                  Name: Dm_Na
                  Max: 1.0e-15
                  Min: 1.0e-20
                  Logscale: True
        - type: tissue
          name: spot           # unique profile name
          diffusion constants: # constants applied to all targeted cells
                  Name: Dm_Na_spot
                  Derived: trait('Dm_Na')

Command-line options reference

gabee.sh / python -m gabee.cli command line options:

  • -h, --help --- show this help message and exit

  • --workpath WORKPATH --- directory to store mutated configurations (REQUIRED)

  • --templatepath TEMPLATEPATH --- template configuration directory (REQUIRED)

  • --fitness FITNESS --- Python expression for fitness function (REQUIRED)

  • --outputdatapath OUTPUTDATAPATH --- path suffix in configuration dir where output results can be found post-simulation

  • --configfile CONFIGFILE --- path to template configuration file ((WARNING: Option not completely working)) (defaults to TEMPLATEPATH/config.yaml)

  • --patchfile PATCHFILE --- path to configuration patch file (defaults to TEMPLATEPATH/patches.yaml)

  • --popsize POPSIZE --- population size to initialize

  • --init-mix-rounds INIT_MIX_ROUNDS --- number of rounds of selection-less mutations to apply to a newly initialized population

  • --max-concurrency MAX_CONCURRENCY --- maximum number of concurrent simulation jobs to launch (defaults to population size)

  • --gen-count GEN_COUNT --- number of generations to simulate

  • --init-trajectory INIT_TRAJECTORY --- initialize from specified trajectory file (containing population and history)

  • --save-trajectory SAVE_TRAJECTORY --- save checkpoints to specified trajectory file

  • --monitor-image MONITOR_IMAGE --- display image from best current individual found at specified path suffix in configuration directory

  • --monitor-image-tableau NUM_INDIVS --- display tableau of images from NUM_INDIVS individuals evenly spaced throughout the population (requires --monitor-image)

  • --aux-plot-function AUX_PLOT_FUNCTION --- plot additional fitness-like function (or bracketed list of functions), evaluated on max fitness individuals

  • --aux-plot-pointfunc AUX_PLOT_POINTFUNC --- plot a point function evaluated at each cell of the current max fitness individual

  • --avg-mutation-count AVG_MUTATION_COUNT --- expected number of mutations per individual (defaults to 1.0)

  • --mutation-distribution {normalrandom,powerlawrandom,uniformrandom} --- distribution used for real-valued mutations

  • --crossover-fraction CROSSOVER_FRACTION --- expected fraction of traits from second parent in parameterized uniform crossover (defaults to 0)

  • --tournament-size TOURNAMENT_SIZE --- tournament size for parent tournament selection (defaults to 3); specify 0 for fitness-proportional selection

  • --relative-step-size RELATIVE_STEP_SIZE --- multiplicative scale factor to apply to all locus step sizes

  • --wait --- wait until all figure windows have been dismissed before exiting

  • --animate --- show looping animation of best individuals (requires --monitor-image and --wait)

  • --smoke-test --- configuration smoke test; do not actually prepare and launch population

  • --rerun-trajectory RERUN-SUFFIX --- re-run best scoring individuals under new settings, named with the given suffix attached (requires --init-trajectory)

  • --local-concurrency NUMBER-OF-THREADS --- number of threads or child processes to use for housekeeping tasks (defaults to 8; try reducing if running into memory quota limits); does not affect concurrency of simulation jobs


GABEE is under development by Micah Z. Brodsky for the Allen Discovery Center at Tufts University. GABEE is planned to be free and open source software, anticipated to be available under the BSD 2-clause license.