<< Note: the original version of this post was incorrect. The create statement that needs to be commented out is the one in proc init(). My lesson, for the nth time where n is a large number, is to proofread my posts more carefully. >>
Thanks for the tip. The cause of the problem is that the template itself contains a user-generated bug. Specifically, it has two
create statements, one of which is executed outside of any proc or func (it's the second line inside the template). This statement is OK. The other create statement is executed inside proc init() and is a mistake written by the person who developed this template. Both statements "create" sections that have the same names. Consequently, if you execute
objref cell
cell = new Mit()
or the equivalent Python
cell = h.Mit()
you actually get two different objects--one called Mit, which is generated by the incorrect create statement, and another called Mit[0]. Mit[0] is produced by the create statement that is not in proc init(), and its topology and anatomical and biophysical properties are as specified by the statements in proc init(). Mit, however, is just a bag of sections that have the default properties that any section has when it is first created (membrane specific capacitance, cytoplasmic resistivity, and size appropriate for squid axon, but no ion channels), and none of these sections are connected to each other. This is bad because it could easily result in a lot of confusion and incorrect results (e.g. a user could easily try assigning properties to, or recording values from, a section that actually belongs to Mit, not Mit[0]).
If you intend to reuse that code, you should comment out the superfluous create statement in mitral.tem, i.e. change the
Code: Select all
create soma, glom, prim, dend[100], s2d, s2p, p2g
inside proc init() to
Code: Select all
// create soma, glom, prim, dend[100], s2d, s2p, p2g
All of the templates used by ModelDB entry 116094 have the same problem and should be fixed. I wonder how many other user-written templates in ModelDB also have this problem.
NEURON itself should probably be revised so that the template parsing code detects and rejects templates that have this problem.
Does NEURON's NeuroML export feature really have a bug when there is more than one instance of a cell class defined by a well-formed template? A very simple test I tried with a couple of instances of a ball and stick class didn't reveal any error, but I invite others to see what they discover.
What lessons should NEURON users draw from this?
1. Always test your code. Had the original author(s) of this model tested their code, they would have discovered their error and fixed it.
2. Always test code that you get from others. Your default assumption should be that it has bugs until you have verified that it really is what it is supposed to be. In this case, a simple count of the total number of sections would have provided a big clue that something was wrong. Simply using the ModelView tool's GUI would have immediately revealed that
cell = h.Mit()
actually produced two cells.
3. To those who would write their own hoc templates a strong suggestion: less than 5 minutes using the CellBuilder to generate a template for a toy model cell would have produced a hoc file that contains all the structure and other hints you need to do the job correctly.