Integration of Markov channel models

[romainbrette]

To accurately account for channel noise requires considering Markov models of ionic channels (there's a paper showing that Langevin approximations are not good enough). The standard method is described in Chow & White (Biophysical Journal 1996). We might require new syntax (a couple of flags probably).

[pfeffer90]

An accurate handling of channel noise would be great. I have discovered the proposal browsing through the wiki.

What is the state of the proposal? I would be interested in supporting the idea. I am PhD student in neuroscience from Berlin, have used brian2 and work on a project where we simulate channel noise.

Maybe of interest: A novel paper, which reviews the algorithm used by Chow & White and proposes an additional, similar one is by Anderson & Ermentrout (Journal of Computational Neuroscience, 2015).

[mstimberg]

I don't think there has been any progress on this since the proposal was made... There are several aspects to this feature, and the best would be probably to implement it step-by-step. First, we'd need to define a syntax for these models -- Romain already made a few suggestions in the wiki. Then, at least for deterministic models, we could have a first stage where this syntax would be translated into equations, e.g. something like (where alpha, beta are some functions of V)

C -> O, alpha
O -> C, beta

should be transformed into something like

dC/dt = beta*O - alpha*C : 1
O = 1 - C : 1

This would be quite straightforward to implement and would basically need no changes to the Brian core (another question would be whether we want a user to do this explicitly, or whether the Markov model description would be included in the equations string, and converted automatically by Brian).

Then, there's the whole question of integration. Do we need to separate the integration of these variables from the rest? E.g. solve the equation for C exactly, but assuming a V that is constant over a time step. And if yes, how would we expose this functionality to the user (you can already do something like this using two separate NeuronGroups and linked variables, but well, this is not very user-friendly).

Finally, there's the question of channel noise models. I don't know anything about such models, but again the first question would be how to define the user-facing syntax. Then, we'd have to think about the integration and whether we can express it using Brian's general mechanism, i.e. via "abstract code", or whether we have to create new target-language dependent code (which means writing code for numpy, Cython, C++...).

So, everything is doable, but given our limited resources in the team I think this feature needs some significant involvement from someone else (at least until we need the feature for our own work ;) ).

[pfeffer90]

Thanks for the quick reply. This seem like very self-contained steps, which is handy.

First, we'd need to define a syntax for these models

How could I support this process? In my eyes, the proposal by Romain is promising, it is easy to read and for the single gated channel model completely specifies the model. Maybe a series of use cases would be interesting, e.g. specifying typical channel models to test whether the syntax is sufficient to cover more complex cases?

Translation in a deterministic equation

This seems like a doable step once the syntax is fixed. I have been digging into the source code of Brian2 a little bit, because I am using the Equation class in one of my projects, but it would help me a lot, when you would introduce me to the model parsing part of brian2.

(another question would be whether we want a user to do this explicitly, or whether the Markov model description would be included in the equations string, and converted automatically by Brian).

I think the answer to this is connected to the channel noise aspect. Is there a way that in the Markov model syntax the user can specify, whether the model should be deterministic or stochastic (could be Langevin or the real jump process)? Such a specification would be in a way similar to the already available automatic detection of stochastic parts in the equations. If this is possible, e.g. via a flag or so, then the user can intentionally choose, which I think is preferable.

Then, there's the whole question of integration. Do we need to separate the integration of these variables from the rest?

Why do you think this is an issue for the deterministic case? Why shjuldn't the translated equation just be treated as any other equation of the model?

Finally, there's the question of channel noise models. I don't know anything about such models, but again the first question would be how to define the user-facing syntax. Then, we'd have to think about the integration and whether we can express it using Brian's general mechanism, i.e. via "abstract code", or whether we have to create new target-language dependent code (which means writing code for numpy, Cython, C++...).

I think that is the real interesting part and should be considered already in the discussion of the syntax to be sure that also the requirements of this use case are covered. Update algorithms are described in the above mentioned Anderson paper (Next reaction method, SSA or a fixed time step procedure).Whether they can be translated into abstract code would need some thought.

So, everything is doable, but given our limited resources in the team I think this feature needs some significant involvement from someone else (at least until we need the feature for our own work ;) ).

In general, I would be happy to work on this project, also because it fits quite well with my PhD project. A postdoc from my lab, Jan-Hendrik Schleimer, and I have been thinking about this already for a while. We use our own custom neuron models to simulate channel noise. Currently, our custom software is sufficient for us, but it would be great to use brian2 for this. Maybe it would be helpful for this feature to have a nice motivating aim like reproducing one of the important channel noise studies with brian2?

[ttxtea]

As for the notation. IMO, it is very usefull to be compatible with either the dot language or something that the python package networkx can read (i.e. json). The delayed rectifier in DOT would be

"""digraph K_dr { n0 -> n1 [label="4*a"];
                     n1 -> n2 [label="3*a"];
                     n2 -> n3 [label="2*a"];
                     n3 -> n4 [label="a"];
                     n4 -> n3 [label="4*b"];
                     n3 -> n2 [label="3*b"];
                     n2 -> n1 [label="2*b"];
                     n1 -> n0 [label="b"];
                     }"""

(another question would be whether we want a user to do this explicitly, or whether the Markov model description would be included in the equations string, and converted automatically by Brian)

Isn't it more transparent if this stays a preprocessing step. There is ambiguitity in what one would do with such a markov model (conversion to rates equations, diffusion approximation, SSA algorithm, ...). The user should probably decide this by converting the graph description to ODE, SDE, ... and then use brian2 to simulate.

Finally, there's the question of channel noise models.

We basically have some code for doing the diffusion approximations (at least 2 different kinds of), again as a preprocessing step converting the graph to SDEs. The resulting SDEs can then be simulated in brian2.

An actually exact or Gillespie implementation for brian2 would probably be more complicated, yet nice. Only then it would make sense to have Markov models as part of the equation string.

[romainbrette]

Hi all,

Just a few quick comments. This thread touches on two distinct issues. On the wiki, I was concerned with the issue of writing and integrating deterministic models that are described by state transitions. One could transform them into ODEs, but the problem is that the integration methods we use in Brian2 are not well adapted to models of this kind. Typically you can have very small time constants (eg in models of the Na channel) and that means you need an implicit solver. But the implicit solver used by Brian2 for HH equations (exponential_euler) works only if the equations are conditionally linear on the state variable, which is not the general case for Markov models, which are linear with respect to the vector of state variables (eg dm1/dt = a(v)m1 + b(v)m2). So we need a specific integration method. Then there is the issue of mixing that integration method with the integration of the rest of the neuron model (a simple but not very elegant possibility is through linked_var).

The second issue is channel noise. Here indeed there are different ways to simulate it. We could perhaps use the "method" keyword, but there's again the issue of combining it with the integration method of the rest of the neuron; also there is an additional parameter, which is number of channels (in the deterministic case you only need max conductance).

In the end it seems that it might make sense to have a Channel object (or rather ChannelGroup). I would favor a Brianesque syntax, with maybe possibility to import/export to other formats.