www.neuron.yale.edu

Hello,

I am working with the Mainen and Sejnowski 1996 model. I was going to experiment with adding the fast potassium current (kv) to the dendritic compartment. Because I am not a seasoned NEURON user, as a sanity check, I added the the kv to the dendritic compartment but set gbar_kv= 0. I tried to do this in two different ways (both of these methods gave the same result):

In demofig1.hoc
Method 1: Method 2: Because I set gbar_kv = 0, I expected that this code should yield the same spiking out put as the original code (without the kv channels inserted in the dendrite). However, I did not find this to be the case. (The difference in spiking behavior is obvious in the pyramid neurons). I looked at kv.mod file equations to see how the current was being calculated:

In kv.mod A gbar = 0 should mean that gk=0 and therefore, ik=0. If no current is being produced when gbar=0, why is the spiking behavior not the same as when the dendritic { insert kv gbar_kv = 0 } command is omitted? Clearly, I don't understand something. Any explanation or advice would be greatly appreciated.

Thank you in advance,
Corinne

Good questions.

Corinne wrote:Method 1:

Code: Select all

  // kv delayed rectifier channels
  iseg { insert kv  gbar_kv = gkv_axon }
  hill { insert kv  gbar_kv = gkv_axon }
  soma { insert kv  gbar_kv = gkv_soma }
  dendritic { insert kv  gbar_kv = 0 } //I ADDED THIS LINE

This tries to treat dendritic as if it were the name of a section. However, dendritic is a SectionList, so the attempt to change the currently accessed section fails. So instead of inserting kv into all of the sections in the dendritic SectionList, the statement
dendritic { insert kv gbar_kv = 0 }
does something else.

"But what else?"

Well,
dendritic { print secname() }
returns
soma

So
dendritic { insert kv gbar_kv = 0 }
changes somatic gbar_kv from a nonzero value to 0. You can verify this by executing
soma print gbar_kv
right after model setup, then execute
dendritic { insert kv gbar_kv = 0 }
and finally
soma print gbar_kv

And that could make the simulation results quite different.

Method 2:

Code: Select all

  // dendritic channels
  forsec dendritic {
    insert km    gbar_km  = gkm_dend
    insert kca   gbar_kca = gkca_dend
    insert ca    gbar_ca = gca_dend
    insert kv 	 gbar_kv = 0  //I ADDED THIS LINE
    insert cad  
  }

Sorry, I don't see any variables called gkm_dend, gkca_dend, or gca_dend in these files. However, let's suppose you meantWell, I happened to notice that this change produced a simulation result identical to what happened with your Method 1, and we know what Method 1 did (set soma gbar_kv to 0). So let's see if the dendritic SectionList just happens to include . . . soma.

In principle I could iterate through the names of all sections in dendritic and look for one called soma, but then I'd have to write a bit of clever code to do that. Instead, is there some other attribute of soma that we could use to see if soma is in dendritic? How about its diameter? At the oc> prompt, type
soma psection()
and note, among other things, that soma diameter is 23.6... um, which seems likely to be larger than any dendrite's diameter.

So at the oc> prompt I enter
forsec dendritic if (diam>20) print secname()
and sure enough hoc prints
soma

Well, then, exit NEURON and restart, select figure 1 again, choose one of the cell morphologies, and execute (type at the oc> prompt)
soma print gbar_kv
Note that gbar_kv is 200 in the soma.

Now execute
forsec dendritic { insert kv gbar_kv = 0 }
and then
soma print gbar_kv
and guess what happened to soma's gbar_kv.

Lessons:

1. Sanity checks are good. Do them often. That's how to learn stuff.
2. Mismatch between expectations and simulation results is often due to mismatch between the model in one's head and the model in the computer.
3. When disagreements occur, the computer is always right.
4. Names don't always mean what one expects them to mean. I certainly didn't expect soma to be a member of the dendritic SectionList. Looking at demofig1.hoc, I now see this telltale bit: which only goes to prove the old saying "It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so." Variously rendered and variously attributed.

In principle I could iterate through the names of all sections in dendritic and look for one called soma, but then I'd have to write a bit of clever code to do that.

Maybe not so clever at all. ifsec should do the job, like so:
forsec dendritic ifsec "som*" print secname()
which will actually print the names of all sections that start with "som"

I tend to forget about ifsec and issection(), but these can be very useful--see their entries in the Programmer's Reference.

Thank you Ted; that was very helpful.

In order to add the gkv just to the dendrites I added the code: This seems to do the trick.

However, I am perplexed by the logic of the original code. Why would the authors include the soma in the dendritic section, set the conductance values and then immediately change the conductance values of the soma. It seems like it would make more sense if the soma and dendrites were separate. In addition, notice that all the conductances set in the soma are actually the same as the dendritic conductances:

From demofig1.hoc:
The only thing I can think of is that the authors originally intended for all of the conductances to be the same in the soma and the dendrite. Then, after the fact, they decided that they would like to be able to alter the soma conductances separately so they added a separate soma conductance section. Then they finally decided to set all the conductances to the original values without cleaning up the code. Does this seem like a probable explanation? Or, do you think I am missing something and this seemingly odd set up is somehow important to the execution of the code?

Thanks again!
Corinne

What is important is the set of model parameters as it exists at the time a simulation is executed. As Mark Twain said, there are many ways to skin a cat--every programmer seems to have his or her own approach to organizing code, and usually there are many ways to accomplish the same end result.