Use the model specification

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 :

use "Continuous Create"
save this model cell to a hoc file ("export" hoc code)
save this model cell to a hoc file as a class definition (save it as a "cell type")

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
topology()
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.

Turn Continuous Create ON and save the CellBuilder we just built to a session file called mycell.ses
Create a hoc file called init.hoc, and put these statements in it :
```
load_file("nrngui.hoc")
load_file("mycell.ses")
```
Start NEURON and have it read init.hoc
- MSWin -- double click on init.hoc
- OS X -- drag and drop init.hoc onto the nrngui icon
- UNIX/Linux -- at the system prompt type the command nrngui init.hoc
Use the NEURON Main Menu toolbar to construct a custom graphical user interface that has the following items :
- A RunControl panel
- An IClamp that applies a 0.6 nA x 1.0 ms current pulse to the soma starting at t = 5 ms.
- A graph of somatic membrane potential vs. time. Since the CellBuilder automatically makes the soma be the default section, all you have to do is click on
  Graph / Voltage axis
  in the NEURON Main Menu.
Run a test simulation with Tstop = 20 ms to make sure that things work.
Use the Print & File Window Manager to save the RunControl, IClamp, and voltage graph to a session file called iclamprig.ses (after all, this is a "virtual experimental rig").

Exit NEURON and edit init.hoc so that it reads

load_file("nrngui.hoc")
load_file("mycell.ses")
load_file("iclamprig.ses")

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.

stylizedcode.zip contains the files (init.hoc, mycell.ses, and iclamprig.ses that were used to generate this figure.

Modular programming and reusable code

You might think of mycell.ses 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 vclamprig.ses. In that case, it would make sense to have two init files with different contents and descriptive names, like this :

initiclamp.hoc

load_file("nrngui.hoc")
load_file("mycell.ses")
load_file("iclamprig.ses")

initvclamp.hoc

load_file("nrngui.hoc")
load_file("mycell.ses")
load_file("vclamprig.ses")

Also note that iclamprig.ses and vclamprig.ses 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 ]