New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate equations from small multicompartmental models #443

Open
thesamovar opened this Issue Apr 9, 2015 · 5 comments

Comments

Projects
None yet
3 participants
@thesamovar
Member

thesamovar commented Apr 9, 2015

The idea is that you might sometimes want to have a large network of neurons with a small number of compartments. Rather than writing out all the equations by hand, you could use the existing multicompartmental modelling framework (which only works for a single neuron) to generate those equations.

From an email exchange:

@thesamovar: A quick way to make this sort of thing possible would be to use the existing syntax to set up a multicompartmental neuron, but have a method that just returns the generated equations which can then be used in a standard NeuronGroup. You could also give specific variable names to specific variables in specific compartments.

@romainbrette: It's possible but requires a little bit of work. You would need basically to duplicate the equations for all compartments, then add a membrane equation that includes the lateral currents.

@thesamovar thesamovar added this to the 2.x (post 2.0) milestone Apr 9, 2015

@mstimberg

This comment has been minimized.

Show comment
Hide comment
@mstimberg

mstimberg Apr 10, 2015

Member

I'm a bit undecided about the best approach for this. On the one hand, it would be nice if you could just use the Morphology classes and then call some convenience function to create the equations for you, but on the other hand, I'm a bit worried that too much parallelism with the SpatialNeuron will make users think that you can use all of its features. E.g. when you create a SpatialNeuron, you can record the membrane potential from a specific compartment like this:

mon_R = StateMonitor(neuron, 'v', record=morpho.R[75*um])

If neuron is just a NeuronGroup with complex equations, this can't work (it would have to record v_R_17 or something like that). But maybe this is just a documentation issue.

Note that there was support for this kind of equation generation in Brian1 (MembraneEquation and Compartments classes): http://brian.readthedocs.org/en/1.4.1/librarymodels.html

Member

mstimberg commented Apr 10, 2015

I'm a bit undecided about the best approach for this. On the one hand, it would be nice if you could just use the Morphology classes and then call some convenience function to create the equations for you, but on the other hand, I'm a bit worried that too much parallelism with the SpatialNeuron will make users think that you can use all of its features. E.g. when you create a SpatialNeuron, you can record the membrane potential from a specific compartment like this:

mon_R = StateMonitor(neuron, 'v', record=morpho.R[75*um])

If neuron is just a NeuronGroup with complex equations, this can't work (it would have to record v_R_17 or something like that). But maybe this is just a documentation issue.

Note that there was support for this kind of equation generation in Brian1 (MembraneEquation and Compartments classes): http://brian.readthedocs.org/en/1.4.1/librarymodels.html

@thesamovar

This comment has been minimized.

Show comment
Hide comment
@thesamovar

thesamovar Apr 10, 2015

Member

I think you'd need to create names for specific compartments when you created it, e.g.

eqs = morpho.create_equations(r=morpho.R[75*um])
...
G = NeuronGroup(N, eqs, ...)
mon_r = StateMonitor(G, 'r')

Actually since threshold and reset are probably part of it, maybe we should directly create a NeuronGroup from morpho rather than just the equations, e.g. G=morpho.create_group(N, ...).

I would say that it could be a documentation issue in this case. Yes, users might well make mistakes because of not reading the docs but in this case those mistakes won't lead to silent problems, they'll raise errors, so it's not so bad.

I wouldn't like to have an entirely parallel system like the library models from Brian 1: too much duplication.

Member

thesamovar commented Apr 10, 2015

I think you'd need to create names for specific compartments when you created it, e.g.

eqs = morpho.create_equations(r=morpho.R[75*um])
...
G = NeuronGroup(N, eqs, ...)
mon_r = StateMonitor(G, 'r')

Actually since threshold and reset are probably part of it, maybe we should directly create a NeuronGroup from morpho rather than just the equations, e.g. G=morpho.create_group(N, ...).

I would say that it could be a documentation issue in this case. Yes, users might well make mistakes because of not reading the docs but in this case those mistakes won't lead to silent problems, they'll raise errors, so it's not so bad.

I wouldn't like to have an entirely parallel system like the library models from Brian 1: too much duplication.

@romainbrette

This comment has been minimized.

Show comment
Hide comment
@romainbrette

romainbrette Apr 10, 2015

Member

It should probably be kept separate from SpatialNeuron. For the naming:
actually the morphology object already has (optionally) names for the
branches, so those could be used. And the compartments could be numbered
of subscripted with position. Reset and threshold should be added by the
user.

Le 10/04/2015 13:38, Dan Goodman a écrit :

I think you'd need to create names for specific compartments when you
created it, e.g.

|eqs = morpho.create_equations(r=morpho.R[75*um])
...
G = NeuronGroup(N, eqs, ...)
mon_r = StateMonitor(G, 'r')
|

Actually since threshold and reset are probably part of it, maybe we
should directly create a |NeuronGroup| from |morpho| rather than just
the equations, e.g. |G=morpho.create_group(N, ...)|.

I would say that it could be a documentation issue in this case. Yes,
users might well make mistakes because of not reading the docs but in
this case those mistakes won't lead to silent problems, they'll raise
errors, so it's not so bad.

I wouldn't like to have an entirely parallel system like the library
models from Brian 1: too much duplication.


Reply to this email directly or view it on GitHub
#443 (comment).

Twitter: https://twitter.com/RomainBrette
Blog: http://romainbrette.fr/category/blog/

New paper:
Laudanski J, Zheng Y, Brette R (2014). A structural theory of pitch. eNeuro. DOI: 10.1523/ENEURO.0033-14.2014

Member

romainbrette commented Apr 10, 2015

It should probably be kept separate from SpatialNeuron. For the naming:
actually the morphology object already has (optionally) names for the
branches, so those could be used. And the compartments could be numbered
of subscripted with position. Reset and threshold should be added by the
user.

Le 10/04/2015 13:38, Dan Goodman a écrit :

I think you'd need to create names for specific compartments when you
created it, e.g.

|eqs = morpho.create_equations(r=morpho.R[75*um])
...
G = NeuronGroup(N, eqs, ...)
mon_r = StateMonitor(G, 'r')
|

Actually since threshold and reset are probably part of it, maybe we
should directly create a |NeuronGroup| from |morpho| rather than just
the equations, e.g. |G=morpho.create_group(N, ...)|.

I would say that it could be a documentation issue in this case. Yes,
users might well make mistakes because of not reading the docs but in
this case those mistakes won't lead to silent problems, they'll raise
errors, so it's not so bad.

I wouldn't like to have an entirely parallel system like the library
models from Brian 1: too much duplication.


Reply to this email directly or view it on GitHub
#443 (comment).

Twitter: https://twitter.com/RomainBrette
Blog: http://romainbrette.fr/category/blog/

New paper:
Laudanski J, Zheng Y, Brette R (2014). A structural theory of pitch. eNeuro. DOI: 10.1523/ENEURO.0033-14.2014

@mstimberg

This comment has been minimized.

Show comment
Hide comment
@mstimberg

mstimberg Apr 10, 2015

Member

I agree that we don't want to have a parallel system as in Brian 1, and we should certainly keep it separate from SpatialNeuronGroup. On the other hand, the most convenient thing from the user point of view would be to have another class that could be created like SpatialNeuronGroup, i.e. it takes the morphology, a transmembrane current etc. It would basically be a wrapper around NeuronGroup, putting the equations and everything else together. Still, connecting with synapses or recording with monitors would work differently from SpatialNeuronGroup. I'd be happy to help someone working on this (it shouldn't be very difficult in fact), but I think for us it is not a high priority right now.

Member

mstimberg commented Apr 10, 2015

I agree that we don't want to have a parallel system as in Brian 1, and we should certainly keep it separate from SpatialNeuronGroup. On the other hand, the most convenient thing from the user point of view would be to have another class that could be created like SpatialNeuronGroup, i.e. it takes the morphology, a transmembrane current etc. It would basically be a wrapper around NeuronGroup, putting the equations and everything else together. Still, connecting with synapses or recording with monitors would work differently from SpatialNeuronGroup. I'd be happy to help someone working on this (it shouldn't be very difficult in fact), but I think for us it is not a high priority right now.

@romainbrette

This comment has been minimized.

Show comment
Hide comment
@romainbrette

romainbrette Apr 10, 2015

Member

I think you just need something to output the equations and then you can
use NeuronGroup. This could be a method of Morphology.

Le 10/04/2015 15:51, Marcel Stimberg a écrit :

I agree that we don't want to have a parallel system as in Brian 1,
and we should certainly keep it separate from |SpatialNeuronGroup|. On
the other hand, the most convenient thing from the user point of view
would be to have another class that could be /created/ like
|SpatialNeuronGroup|, i.e. it takes the morphology, a transmembrane
current etc. It would basically be a wrapper around |NeuronGroup|,
putting the equations and everything else together. Still, connecting
with synapses or recording with monitors would work differently from
|SpatialNeuronGroup|. I'd be happy to help someone working on this (it
shouldn't be very difficult in fact), but I think for us it is not a
high priority right now.


Reply to this email directly or view it on GitHub
#443 (comment).

Twitter: https://twitter.com/RomainBrette
Blog: http://romainbrette.fr/category/blog/

New paper:
Laudanski J, Zheng Y, Brette R (2014). A structural theory of pitch. eNeuro. DOI: 10.1523/ENEURO.0033-14.2014

Member

romainbrette commented Apr 10, 2015

I think you just need something to output the equations and then you can
use NeuronGroup. This could be a method of Morphology.

Le 10/04/2015 15:51, Marcel Stimberg a écrit :

I agree that we don't want to have a parallel system as in Brian 1,
and we should certainly keep it separate from |SpatialNeuronGroup|. On
the other hand, the most convenient thing from the user point of view
would be to have another class that could be /created/ like
|SpatialNeuronGroup|, i.e. it takes the morphology, a transmembrane
current etc. It would basically be a wrapper around |NeuronGroup|,
putting the equations and everything else together. Still, connecting
with synapses or recording with monitors would work differently from
|SpatialNeuronGroup|. I'd be happy to help someone working on this (it
shouldn't be very difficult in fact), but I think for us it is not a
high priority right now.


Reply to this email directly or view it on GitHub
#443 (comment).

Twitter: https://twitter.com/RomainBrette
Blog: http://romainbrette.fr/category/blog/

New paper:
Laudanski J, Zheng Y, Brette R (2014). A structural theory of pitch. eNeuro. DOI: 10.1523/ENEURO.0033-14.2014

@thesamovar thesamovar removed this from the 2.x (post 2.0) milestone Jul 21, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment