Step 6. Use the model specification

Now that the CellBuilder contains a complete specifcation of our model, how do we use it? We have three alternatives : Let's consider each of these.

Using "Continuous Create"

It may come as a surprise, but if you followed the instructions up to this point, no sections will actually exist. You can test this for yourself by executing a couple of simple hoc commands.

At the hoc interpreter's oc> prompt, type
If sections exist, you will see a crude but informative on-screen printout that shows how they are interconnected.

Now see what happens when you type the command
    forall psection()
This prints a brief text summary of the properties of each existing section.

But there aren't any sections yet, so these commands print out nothing.

It might help to think of the CellBuilder as being roughly analogous to one of those on-line airline ticket sellers. You can tinker with origin and destination, dates of departure and return, connecting flights, etc., as much as you like, but you don't get a ticket until you click on the "Submit order" button.

The most convenient way to work with the CellBuilder, at least during model development, is to use the Continuous Create checkbox.

Turning Continuous Create ON . . .

 . . . makes the CellBuilder send hoc code straight to NEURON's interpreter without bothering to write a hoc file.
Presto! Suddenly, your model cell exists (test this with topology() and forall psection()).

Any changes made to the model while Continuous Create is ON will automatically be echoed to NEURON's interpreter. This lets you immediately test the model you just created or revised.

Automatic updates may bog things down if you are dealing with a large model on a slow machine. If this happens, just turn Continuous Create OFF.

Then make whatever changes you want, and when you're done just toggle Continuous Create ON and then OFF again.

A very practical way to work with a configured CellBuilder, at least for single cell modeling, is to save it to a session file with Continuous Create ON. Then reading this file will automatically recreate the model cell.

Here's a concrete example of how to do this.

  1. Turn Continuous Create ON and save the CellBuilder we just built to a session file called
  2. Create a hoc file called init.hoc, and put these statements in it :
  3. Start NEURON and have it read init.hoc
  4. Use the NEURON Main Menu toolbar to construct a custom graphical user interface that has the following items :
  5. Run a test simulation with Tstop = 20 ms to make sure that things work.
  6. Use the Print & File Window Manager to save the RunControl, IClamp, and voltage graph to a session file called (after all, this is a "virtual experimental rig").
  7. Exit NEURON and edit init.hoc so that it reads
Now when you use NEURON to execute init.hoc, up comes your CellBuilder, which recreates your model cell, and you also get your custom experimental rig, all ready for you to run some current clamp simulations, as shown here :

The CellBuilder was hidden for this illustration, in order to save screen space. contains the files (init.hoc,, and that were used to generate this figure.

Modular programming and reusable code

You might think of as being roughly analogous to the wet lab experimentalist's neuron in a brain slice or tissue culture. It's a "virtual experimental preparation," and it's reusable--you can construct many different kinds of "custom experimental rigs" to do "virtual experiments" on it.

For instance, you could set up an interface that uses an SEClamp to do voltage clamp experiments, and save it to a file called something imaginative like In that case, it would make sense to have two init files with different contents and descriptive names, like this :


Also note that and are reusable with any model that happens to have a default section called soma.

This is an example of the benefits of "modular programming" (i.e. keeping the model specification (CellBuilder) separate from the specification of the instrumentation (RunControl + IClamp + graph)) and "reusable code."

Exporting hoc code vs. saving a cell type

The Management page contains the CellBuilder's controls for exporting hoc code and saving a model as a cell type. This page also can be used to import models, which we will consider in the second tutorial.

The Export button is for saving a hoc file that contains the basic specification of the model cell. This is OK if you intend to work on a single cell model.

If your aim is to define a new cell class for use in a network model, you'll want to click on the Cell Type radio button.

Always save your configured CellBuilder to a session file

Experience shows that, sooner or later, most models need to be revised. This is especially true of models that seem at first to be perfect in all regards. Saving a configured CellBuilder to a session file usually simplifies future revisions, because it's easier to use the CellBuilder than to decipher idiosyncratic old code. Especially somebody else's idiosyncratic old code. You should save your configured CellBuilder to a session file even if you have already written a hoc file with the Management page's Export or Cell Type functions.

"But wait," someone asks, "can't the CellBuilder import a model cell?"

Not entirely. At present the CellBuilder can import topology and pt3d information, which is very useful, as we will see in the next tutorial. However, it can't import subsets, geometry (L, diam, and nseg), or biophysical properties. So throwing away a CellBuilder is "breaking the mold"--you lose all the time and effort you invested setting it up.

[ Outline | Previous ]

Copyright © 1999-2008 by N.T. Carnevale and M.L. Hines, All Rights Reserved.