Multiple stimulation of POINT_PROCESS per run

When Python is the interpreter, what is a good
design for the interface to the basic NEURON
concepts.

Moderator: hines

Post Reply
parent41
Posts: 6
Joined: Tue May 26, 2020 8:50 am

Multiple stimulation of POINT_PROCESS per run

Post by parent41 »

Hi,

I am trying to stimulate AMPA and NMDA receptors multiple times per run. To do so, I am using the NMDA_Mg_T.mod as the NMDA receptors, release_BMK.mod as the transmitter concentration (POINTER) (modeldb 140828), and the Exp2Syn module as the AMPA receptors.
I am stimulating the Exp2Syn with the vecevent.mod file to specify the spike times.

release_BMK.mod is very similar to the IClamp module and can only be activated once per run (at time onset). Here is the release_BMK code:

Code: Select all

INDEPENDENT {t FROM 0 TO 1 WITH 1 (ms)}

NEURON {
	POINT_PROCESS release
	RANGE T, onset, dur, amp
}

UNITS {
	(mM) = (milli/liter)
}

PARAMETER {
	onset (ms)
	dur (ms)	<0,1e9>
	amp (mM)
}

ASSIGNED {
	T (mM)
}


INITIAL {
	T = 0
}

BREAKPOINT {
	at_time(onset)
	at_time(onset+dur)

	if (t < onset + dur && t > onset) {
		T = amp
	}else{
		T = 0
	}
}
I am wondering what would be the best way to change the code so the release_BMK can release transmitters multiple times per run.
I have 2 ideas on how to implement that:
1. I saw that it was possible to play a vector as the amplitude for the IClamp, but I am wondering how.
2. Put a NET_RECEIVE procedure in the release_BMK so that I can simply connect it to the same vecevent stimulating Exp2Syn with a NetCon. The problem is that I have no idea how to do that, since I am new to NEURON and even more inexperienced in NMDOL (where to put the NET_RECEIVE block, what to write in it, do I have to modify the BREAKPOINT block...).

What do you think would be the best way?

I am working with NEURON as a Python module.

Thank you for your help!
ted
Site Admin
Posts: 5795
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Multiple stimulation of POINT_PROCESS per run

Post by ted »

modeldb.yale.edu/140828's NMDA_Mg_T.mod should be revised so that it is driven by events, instead of using a POINTER to a variable controlled by some other mod file (release_BMK.mod in this case). The changes required are minimal and I will be glad to implement them so you can get on with your project. However, before providing further advice, I need to know what you want to happen if a second "presynaptic spike" ("synaptic activation") occurs at some time t2 while "transmitter is present". Choose one:
1. ignore the second spike
2. extend the "transmitter present" state to t2 + dur so that transmitter concentration remains equal to amp until t = t2 + dur
3. treat each synaptic activation as adding amp to the concentration of transmitter in the synaptic cleft. In other words two "overlapping" synaptic activations would increase transmitter to amp at t = t1 (time of the first synaptic activation), then to 2*amp at t = t2 (time of the second synaptic activation), then back to amp (at t = t1 + dur), then back to 0 (at t = t2 + dur)
parent41
Posts: 6
Joined: Tue May 26, 2020 8:50 am

Re: Multiple stimulation of POINT_PROCESS per run

Post by parent41 »

Hi Ted,

First of all thank you for your help!

In our experiments, that situation shouldn't occur, so the best would be to ignore the second spike and perhaps return an error.
ted
Site Admin
Posts: 5795
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Multiple stimulation of POINT_PROCESS per run

Post by ted »

The original implementation of NMDA_Mg_T did not initialize Mg binding to ion channels correctly. Instead, initialization set channels to "unbound" (i.e. "completely free of Mg") state. Consequently, depending on parameter values, it was necessary to delay synaptic activation for t == 50 ms or more while the
U <-> UMg
transition settled, during which about 90% of channels bound to Mg. The authors' own demonstration program included such a wait, but it seemed likely that future users might naively reuse their code and run into problems, so I fixed initialization before doing anything else. The fixed code is now available from
https://github.com/neuroman314/140828 and I have brought it to the attention of the authors for their approval before updating the ModelDB entry.

While awaiting their approval, I created a new revision of the NMDA_Mg_T mechanism that makes it event-driven and emailed it to you along with hoc and Python demo programs that illustrate its use.
Post Reply