Problem with saturating synapse model

NMODL and the Channel Builder.
Post Reply
szabolcs
Posts: 8
Joined: Fri Aug 06, 2010 10:37 am

Problem with saturating synapse model

Post by szabolcs »

I am trying to use the the saturating synapse model described in Chapter 10 of the NEURON Book in a network simulation. I compile the .mod file listed as ampa.mod in the book, and then attempt to drive a generic conductance-based linear integrate-and-fire neuron through synapses of this type. I actually access Neuron (v. 7.1) through PyNN, and the IF neuron model containing the saturating synapse is created by subclassing the StandardIF cell type in PyNN (by defining an additional type of synapse in analogy to the two existing ones). The resulting model neuron receives and integrates inputs through the saturating synapse perfectly when there is only a single such synapse. If the additional synapse type is a simple, nonsaturating one with a biexponential time course, even multiple inputs are handled well, and large networks with these types of cells and synapses can be run. However, with multiple inputs of the saturating type, certain patterns of input spikes lead to an error such as the following:

NEURON: No event with flag=1 for net_move in AMPA_S[0]
near line 0
{initializer._initialize()}
^
ParallelContext[0].psolve(20)
oc_restore_code tobj_count=1 should be 0
Traceback (most recent call last):
File "test6_ampasyn.py", line 70, in <module>
run(20.0)
File "/home/kali/lib/python2.6/site-packages/pyNN/neuron/__init__.py", line 76, in run
simulator.run(simtime)
File "/home/kali/lib/python2.6/site-packages/pyNN/neuron/simulator.py", line 207, in run
state.parallel_context.psolve(state.tstop)
RuntimeError: hoc error

Three spikes in two separate input streams appears to be the minimum condition to trigger this error, when neighboring spikes are closer to each other than the duration of the transmitter pulse.

What could be the source of the problem (I realize it might come from a variety of sources, including PyNN and my own tinkering)? Is this .mod file supposed to be used in this way? Or am I doing this completely wrong?

Thank you,

Szabolcs
ted
Site Admin
Posts: 6289
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Problem with saturating synapse model

Post by ted »

First thing I would try, on the off chance that the problem is a bug in 7.1, is to switch to version 7.2 of NEURON--either the latest alpha version, or the most recent development code from the mercurial repository.

If that doesn't work, the next step depends on what you mean by "defining an additional type of synapse in analogy to the two existing ones." If this means that you wrote your own NMODL code, or modified somebody else's NMODL code, to create some other kind of synaptic mechanism, that's where the problem may lie. That's also what this error message suggests--

Code: Select all

No event with flag=1 for net_move in AMPA_S[0]
szabolcs
Posts: 8
Joined: Fri Aug 06, 2010 10:37 am

Re: Problem with saturating synapse model

Post by szabolcs »

Thanks for the reply. By "defining an additional type of synapse in analogy to the two existing ones," I meant only that the synapse defined by the ampa.mod file had to be added to the cell template "StandardIF" in PyNN which already had two other (simpler, non-saturating) synapses.

However, this is now mostly irrelevant since I managed to reproduce the error using the Neuron GUI as well, and the problem persists in the 7.2 alpha version (although I noted that, for some reason, reinstalling Neuron from nrn-7.2.alpha-500.tar.gz left me with release 445 from last June).

What I do is the following: I simply create a passive one-compartment neuron, insert a synapse from ampa.mod, and add two inputs from NetStim objects, which then provide the simple three-spike sequence mentioned earlier.

In fact, when I first tried this with the file ampa.mod from the NEURON Book, I got the error

Code: Select all

oc>/usr/local/nrn/x86_64/bin/nrniv: Cdur not in this property
 in mynet3.ses near line 155
 }
  ^
        MechanismStandard[17].set("Cdur", 0.3, 0)
      xopen("mynet3.ses")
    NEURONMainMenu[0].execute1("{xopen("mynet3.ses")}")
  NEURONMainMenu[0].load_file(1, "/home/kali/pynn/wm/mynet3.ses")
and others
Then I found (after looking at some working synapse models in ModelDB) that if I replaced the line

Code: Select all

GLOBAL Cdur, Alpha, Beta, Erev, Rinf, Rtau
in the NEURON block of ampa.mod by

Code: Select all

RANGE Cdur, Alpha, Beta, Erev, Rinf, Rtau
then the model worked under most circumstances, but with some combinations of input spikes, I again got the error

Code: Select all

oc>/usr/local/nrn/x86_64/bin/nrniv: No event with flag=1 for net_move in  AMPA_S[0]
 near line 10
 {run()}
        ^
        fadvance()
      advance()
    step()
  continuerun(20)
and others
What is the next step in this case?
ted
Site Admin
Posts: 6289
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Problem with saturating synapse model

Post by ted »

OK, you have discovered a bug in the mod file. Declaring the variables RANGE or GLOBAL is not the fix. The problem emerges when a mechanism instance has more than one outstanding self-event, and then calls net_move()--which of the events should be moved? My own limited tests found that in a situation in which the earlier event should be moved, it was the later event that was moved. While a fix for this is being developed (allow specification of the self-event that is to be moved?), the interim workaround is to limit each instance of the saturating synapse mechanism AMPA_S to a single input stream per instance--that is, one NetCon per AMPA_S instance.
szabolcs
Posts: 8
Joined: Fri Aug 06, 2010 10:37 am

Re: Problem with saturating synapse model

Post by szabolcs »

ted wrote:OK, you have discovered a bug in the mod file. Declaring the variables RANGE or GLOBAL is not the fix.
Yes, I realize that these are two independent issues - still, I do not understand why the synapse model does not work at all (with any kind of input) when parameters such as synaptic time constants are declared GLOBAL (naively, this would seem more logical) - although I now see that all similar variables are declared RANGE in the other related .mod files in the book. Anyway, this is not critical for my problem (and probably involves a lot of technical details about NMODL that I am not aware of), so I am just being curious.
ted wrote:The problem emerges when a mechanism instance has more than one outstanding self-event, and then calls net_move()--which of the events should be moved? My own limited tests found that in a situation in which the earlier event should be moved, it was the later event that was moved. While a fix for this is being developed (allow specification of the self-event that is to be moved?), the interim workaround is to limit each instance of the saturating synapse mechanism AMPA_S to a single input stream per instance--that is, one NetCon per AMPA_S instance.
Is this approach workable in a large-scale model (1000's of synapses onto each single-compartment cell)? What amount of overhead (in terms of memory and CPU time) can I expect?

Thanks a lot,

Szabolcs
ted
Site Admin
Posts: 6289
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Problem with saturating synapse model

Post by ted »

szabolcs wrote:
ted wrote:While a fix for this is being developed (allow specification of the self-event that is to be moved?), the interim workaround is to limit each instance of the saturating synapse mechanism AMPA_S to a single input stream per instance--that is, one NetCon per AMPA_S instance.
. . .
What amount of overhead (in terms of memory and CPU time) can I expect?
Each AMPA_S instance adds two 1st order ODEs.
Is this approach workable in a large-scale model (1000's of synapses onto each single-compartment cell)?
Run times will suffer, but whether this is fatal or only a nuisance is something only you can determine.

Unless you are absolutely sure that receptor saturation is essential to the phenomenon you are studying, you might consider starting with a model that uses a synaptic mechanism that works with multiple afferent streams, like Exp2Syn, to generate a set of "control" simulations. Then replace each Exp2Syn with as many AMPA_S mechanisms as necessary and generate a "test" set.* If {the test set is qualitatively similar to the control set} AND {the test run times are intolerably longer than the control run times} then you might want to proceed with the control model (the model implementation that uses Exp2Syn). If there is a qualitative difference between the test and control set, you're going to have to use the test model (the implementation that uses AMPA_S)--BUT you might still want to proceed first with the control model, because otherwise you won't be able to answer the question "what does saturability do to the performance of the network? does it prevent or endow the net with the ability to accomplish some function?"

*--assumes you have adjusted the Exp2Syn time constants and weight so that a single activation produces a psp that is qualitatively similar to the psp generated by a single activation of AMPA_S.


A comment on design and implementation of model setup code:
The code that sets up a network model can be organized as a sequence of procedures, each of which accomplishes a specific task, e.g.

Code: Select all

proc mkcells() // creates instances of cell classes
proc mksyn() // for each cell instance, create and attach synaptic mechanisms
proc connectcells()
the synapse defined by the ampa.mod file had to be added to the cell template "StandardIF" in PyNN which already had two other (simpler, non-saturating) synapses.
This is fine as long as {the synaptic mechanisms attached to each cell instance} will not be one of the independent variables that are explored in the course of the modeling project. However, if the number and nature of the synaptic mechanisms _are_ going to be varied, you're going to need multiple templates, and this complicates management of code development, revision, and testing. In such cases, it may be easier not to build the creation and attachment of synaptic mechanism into the cell class, but instead to factor this out into a procedure. The program structure would then be

Code: Select all

proc mkcells() // creates instances of cell classes
proc mksyn() // for each cell instance, create and attach synaptic mechanisms
proc connectcells()
This design reduces the difficulty of changing the number and type of synaptic mechanisms, by eliminates the need to revise the cell templates. Instead, just revise mksyn() and connectcells(), which were going to have to change anyway.
szabolcs
Posts: 8
Joined: Fri Aug 06, 2010 10:37 am

Re: Problem with saturating synapse model

Post by szabolcs »

Thanks for the detailed response.
ted wrote:
szabolcs wrote:
ted wrote:While a fix for this is being developed (allow specification of the self-event that is to be moved?), the interim workaround is to limit each instance of the saturating synapse mechanism AMPA_S to a single input stream per instance--that is, one NetCon per AMPA_S instance.
. . .
What amount of overhead (in terms of memory and CPU time) can I expect?
Each AMPA_S instance adds two 1st order ODEs.
Is this approach workable in a large-scale model (1000's of synapses onto each single-compartment cell)?
Run times will suffer, but whether this is fatal or only a nuisance is something only you can determine.
In fact, I was more worried about memory issues, and I do not know enough about the inner workings of Neuron to be able to predict how much having a separate receptor instance for each NetCon would increase the memory requirement, and I was hoping that someone more knowledgeable might be able to provide a rough estimate. For instance, in a network of 1000 (simple IF) neurons with 1,000,000 synapses, would the memory load increase, say, 3-fold, which I can live with, or 100-fold, which would make the whole enterprise hopeless. Indeed, I could determine this experimentally, but this would involve a fair amount of programming, so I would appreciate a hint as to whether the effort is likely to succeed.
ted wrote:Unless you are absolutely sure that receptor saturation is essential to the phenomenon you are studying, you might consider starting with a model that uses a synaptic mechanism that works with multiple afferent streams, like Exp2Syn, to generate a set of "control" simulations. Then replace each Exp2Syn with as many AMPA_S mechanisms as necessary and generate a "test" set.* If {the test set is qualitatively similar to the control set} AND {the test run times are intolerably longer than the control run times} then you might want to proceed with the control model (the model implementation that uses Exp2Syn). If there is a qualitative difference between the test and control set, you're going to have to use the test model (the implementation that uses AMPA_S)--BUT you might still want to proceed first with the control model, because otherwise you won't be able to answer the question "what does saturability do to the performance of the network? does it prevent or endow the net with the ability to accomplish some function?"

*--assumes you have adjusted the Exp2Syn time constants and weight so that a single activation produces a psp that is qualitatively similar to the psp generated by a single activation of AMPA_S.
What I actually want to use is not AMPA, but NMDA type synapses (or combinations of the two), where saturation is generally thought to be important, and also specifically for the function (working memory) that I am trying to model. When I first discovered the bug in my simulation based on the .mod file I constructed for the NMDA receptor, I tried to identify the source of the error, and found that it could be reproduced using the ampa.mod file in the Neuron Book.

So I guess the real question is (which I think is potentially relevant for many people in the community): How can one model NMDA-receptor-mediated synaptic transmission in a large-scale network model in Neuron (preferably such that it behaves properly with multiple NetCons per receptor, which is likely to be important in models based on simplified neurons). I have looked at a large number of NMDA receptor models in ModelDB, but none of them seems to satisfy these requirements.
ted wrote:A comment on design and implementation of model setup code:
The code that sets up a network model can be organized as a sequence of procedures, each of which accomplishes a specific task, e.g.

Code: Select all

proc mkcells() // creates instances of cell classes
proc mksyn() // for each cell instance, create and attach synaptic mechanisms
proc connectcells()
the synapse defined by the ampa.mod file had to be added to the cell template "StandardIF" in PyNN which already had two other (simpler, non-saturating) synapses.
This is fine as long as {the synaptic mechanisms attached to each cell instance} will not be one of the independent variables that are explored in the course of the modeling project. However, if the number and nature of the synaptic mechanisms _are_ going to be varied, you're going to need multiple templates, and this complicates management of code development, revision, and testing. In such cases, it may be easier not to build the creation and attachment of synaptic mechanism into the cell class, but instead to factor this out into a procedure. The program structure would then be

Code: Select all

proc mkcells() // creates instances of cell classes
proc mksyn() // for each cell instance, create and attach synaptic mechanisms
proc connectcells()
This design reduces the difficulty of changing the number and type of synaptic mechanisms, by eliminates the need to revise the cell templates. Instead, just revise mksyn() and connectcells(), which were going to have to change anyway.
It seems that you may have accidentally pasted the same code into both examples, but I think I got the idea anyway.

Szabolcs
shyam_u2
Posts: 77
Joined: Sun Feb 20, 2011 7:15 pm

Re: Problem with saturating synapse model

Post by shyam_u2 »

While a fix for this is being developed (allow specification of the self-event that is to be moved?), the interim workaround is to limit each instance of the saturating synapse mechanism AMPA_S to a single input stream per instance--that is, one NetCon per AMPA_S instance.
Is this bug fixed ?
ted
Site Admin
Posts: 6289
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Problem with saturating synapse model

Post by ted »

Bug is present in 7.3 (927:f3dcf53fbe74) 2013-07-27.
This one either fell through the cracks, or had been fixed and crept back in.
Will look into it.
Post Reply