Copyright © U.S. Bhalla, NCBS, 2026

This document is released under the Creative Commons Attribution License CC-BY 4.0.

Table of Contents

Jardesigner stands for Javascript App for Reaction Diffusion and Electrical SIGnaling in NEuRons. It combines three things:

1. A JSON format for specifying multiscale neuronal models, successor to rdesigneur format.

2. A MOOSE-based model simuator to run jardesigner.json files.

3. A GUI for building and running multiscale models using the above two.

This document explains how to use the jardesigner GUI to build and run multiscale neuronal models.

Here is a six-click demo to build and run a single-compartment neuronal model:

Jardesigner builds and runs neuronal models which incorporate both electrophysiology and chemical signaling. It supports plotting, 3D displays, stimuli, standard file import, file I/O and tutorials.

Jardesigner builds morphologically detailed models with HH-format ion channels, synaptic channels and simple Ca dynamics. This runs on MOOSE which uses the Hines decomposition of the branched nerve equation, and Crank-Nicolson integration to handle channels. MOOSE sends synaptic and other signals around using message-passing.

 

Jardesigner handles reaction-diffusion chemistry including molecules, reactions, mass-action and Michaelis-Menten enzymes, and transport/pores between compartments. MOOSE formulates the chemical system in each compartment into a matrix form with a stochiometry matrix and reaction velocities. Each voxel of the model is solved separately. It can solve these equations using a range of methods. The default for deterministic kinetics is LSODA, and for stochastic kinetics is a fast variant of the Gillespie Stochastic Systems algorithm. Diffusion is handled using an implicit backward Euler solver with probabilistic integer conversion if voxels are stochastic.

 

 

A key capability of Jardesigner (and MOOSE) is to build multiscale models combining electrical and chemical signaling. This is implemented using adaptors, which on every timestep map electrical quantities (such as Calcium ion flux) into chemical quantities (such as Ca concentration), and vice-versa.

Jardesigner specifies stimuli, plots, 3D displays, file I/O and other things needed to build, run and save models.

Jardesigner reads standard formats and talks to databases which host resources for morphology, ephys, and chemistry. Our database coverage is not exhaustive, but given a simple database API we can add more.

The Jardesigner project is developing documentation (which you see now) and has numerous tutorials as part of this documentation.

Jardesigner was explicitly designed for multiscale (ephys + chemical) neuronal models. It uses standard formats for morphology, channels and reactions. It provides controls to build, plot, stimulate and run models. It provides documentation.

Jardesigner does number-crunching and model building on a server, and all the user-interface operations work within your browser.

The Jardesigner uses the Build-on-close approach. This means that the model is entirely rebuilt on the server every time you close a menu box, or open a new one. This has the following implications:

• •It is not instantaneous. Many React interfaces update everything with every keystroke. Jardesigner does not. This is because the model rebuilding is a lot of work. 

• •There is no final compile step. You know as soon as you close a menu if the entire model was built successfully. 

• •There is a record of every change you make. You can download this. 

• •Jardesigner provides an iconified representation of every part of your model as the building progresses. This is in the SETUP 3D display, illustrated above 

In this section we have outlined how Jardesigner works in a client-server fashion: your browser is the client, which does the display, and you can use the official server or your own installation to run the number crunching.

Conceptually, a model in Jardesigner (and MOOSE) is assembled from parts. The parts include physiological entities like compartments, ion channels, molecules and reactions. They also include I/O classes, stimulus control, and functional modules like random number generators and evaluated math expressions. A Jardesigner project is not a program, it is a declarative specification of a model and how to assemble the parts to run it. It is for MOOSE (or in principle, any other simulator) to do the assembly and run the model.

The components of a Jardesigner project are:

Jardesigner  uses the JSON (JavaScript Object Notation) format to formally specify how to assemble neuronal electrical and chemical parts and run them. There may be additional information about how to plot data, how to deliver stimuli, and even documentation. The format is tightly structured and uniquely human-readable. In computer terms, there is a jardesignerSchema.json file which says exactly what can be in the jardesigner .json file. Here is the entirety of the simplest possible Jardesigner JSON file, which defines nothing:

 

Here is a snippet from a more typical Jardesigner file:

 

The Jardesigner interface provides a panel to look at its JSON specification. This panel is continually updated as the model is assembled.

Jardesigner is modular. It can assemble components which are specified in other standard formats. To recap from an earlier section, it currently takes three kinds of external files:

A complex model may have a morphology file, several channel definitions, and distinct signaling pathway models for presynaptic input, spine-heads, spine bodies, and more. Thus a complete jardesigner model specification may involve several files.

The Jardesigner JSON file has a field for brief notes, but a full model explanation may require considerably more complex information including figures. Jardesigner supports attachment of a single xhtml file (an HTML file in which figures are embedded) for such documentation. All the tutorials for jardesigner use such .html files. The Jardesigner GUI allows one to upload such an html file, so any user can provide documentation for their model. This appears in the Model Notes tab under Documentation.

 

From the above, it is clear that a single jardesigner model may require half a dozen files or more. This is untidy. To avoid issues where a model may be missing one of its parts, the GUI supports an additional format which we call .jardes. This is simply a zip file with all the model components in a flat layout. You can make such a file like this:

zip mymodel.jardes mymodel.json mymorpho.swc mychannel.xml myreaction.xml mydocs.html

The only essential part of the .jardes file is the JSON file. If your model does not need anything more and you do not need to add documentation, that is enough. In such situations one can also use the regular JSON file definition of a project.

The core of the jardesigner specification is a declarative JSON file telling the simulator how to assemble the model. It may refer to supplementary files in standard formats for morphology, channels, and reactions. It may also refer to an html file for documentation. A typical project needs several such files to fully specify the model, hence we use the .jardes format which is just the zipfile containing all the components.

 Start the Jardesigner GUI and select the TUTORIALS tab under DOCUMENTATION.

 

Select the tutorial Multiscale Demo For GUI

To learn how MOOSE does its internal calculations, see: