New mod seems to run unreasonably slowly

[Bill Connelly]

Hi,

The model of a synaptic depression I wrote means that my network model takes 105s to run (instead of 45s using the in-built ExpSyn). I appreciate that I'm asking NEURON to solve 4 exponential equations rather than just 1 for each synaptic mechanism; but if that was the sole cause of the increase (and the work load increase linearly with the number of exponents), that would mean that solving the expsyn mechanism was taking nearly half of the computational time in the original network (i.e. each exponential requires 20s). That seems hard to believe with all the huge number of computations that must be going on in the network. Is there some mistake I have made in this model that causes it's inclusion to be so deleterious to computational efficiency?

Code: Select all

NEURON {
POINT_PROCESS expi
NONSPECIFIC_CURRENT i
RANGE i, e, tau, kA, kB, kC, dec
}

PARAMETER {
e = 0 (millivolts)
tau = 4 (ms)
kA = 0.00017 (/ms)
kB = 0.012 (/ms)
kC = 0.05 (/ms)
dec = 0.6
}

STATE {
O
A
B
C
F
g
}

INITIAL {
A = 0
B = 0
C = 0
O = 1
g = 0
}

ASSIGNED {
  v (millivolt)
  i (nanoamp)
}

BREAKPOINT {
SOLVE state METHOD cnexp
F = A * 0.4 + B * 0.4 + C/3 * 0.2
O = 1 - F
i = g * (v - e)
}

DERIVATIVE state {
A' = -kA * A
B' = -kB * B
C' = -kC * C
g' = -g/tau
}

NET_RECEIVE(weight (microsiemens)) {
g = (g + weight) * O
O = O * O * dec
F = 1 - O
A = F
B = F
C = F
}

[ted]

This mechanism does not implement stream-specific plasticity, so you need a separate instance per NetCon. Also, each instance must numerically integrate each of the state variables at each time step (not just the one that immediately governs synaptic conductance, but also those that determine the amount by which g is perturbed when a new event arrives). Depending on the degree of convergence, a network that uses this synaptic mechanism could spend a lot of time grinding away at numerical integration. If you want to see whether this mechanism is responsible for the slow execution you're experiencing, you might try replacing all instances with ExpSyns, taking advantage of each ExpSyn's ability to handle multiple input streams, and see what happens to run time. The test isn't perfect, because the total number of spikes in the net will be different. But if the ExpSyn net fires more spikes in a shorter run time, it's a fair bet that expi is slowing things down.

The solution is to revise expi by taking advantage of the fact that the plasticity ODEs have an analytic solution, so their states need to be updated only when a new event arrives. That will reduce the number of states that must be numerically integrated per epsi instance. You will also be able to save each stream's plasticity states (A, B, C) and "time of last event" in the weight vector, so that streams that converge onto a single segment can be handled by a single epsi instance. For examples of this, see accession numbers 3264 and 3815 in ModelDB.