Compartment condensation

[chbehrens]

Hi all,

I'm not sure whether this is the way to bring this up here, but I drafted an implementation of compartment condensation for extended morphologies. Realistic morphologies e.g. based on EM data and loaded via .swc files often contain thousands of nodes and thus by default thousands of compartments in brian2. In order to speed up simulations it is useful to be able to reduce the number of compartments while still maintaining the overall structure. So I added a condense function to the Morphology class to condense compartments within sections.

The level of condensation can be controlled by a parameter lambda that is in principle related to the ratio of membrane conductivity to internal conductivity of a compartment - though these are not yet defined at the level of the morphology, so here area and cross section divided by length (resp. r_length_1/2) are used instead.

Any suggestions on how to improve this and make it more useful are welcome!
Thanks,
Christian

[mstimberg]

Hi @chbehrens, apologies for not commenting on this for such a long time... In any case, a PR is the perfect way of discussing this.

I'll be away again soon for a week, but here is some quick feedback:

As you say, in principle we would like to have conductivity information that is not available when dealing with a Morphology. I therefore wonder whether it would not make sense to somehow integrate this into SpatialNeuron. On the other hand, I'd say it feels natural to have this of part of the Morphology, there are other things besides this condensation that you might do to prepare the morphology before you create a SpatialNeuron object. Maybe it would actually make sense to make Ri and Cm part of the Morphology definition instead of the SpatialNeuron definition (we'd still keep it backwards compatible, though)? Or doing it based on length/diameter as you do currently is actually enough? I think this is what @romainbrette was proposing in #636 ?

One other thought: in your current implementation, the condense method changes the Morphology in place, I think it might be better if it returned a new object instead (potentially something like a CondensedMorphology with an additional attribute for the index mapping?)

Somewhat related: you currently calculate things like the per compartment area once and store it into an attribute instead of recalculating it on-demand. I certainly get the reasoning behind it, but we made this choice on purpose because we found that changing values like the diameter or length of a compartment after creation could be useful. A typical use case would be to correct/change some values in a morphology of a loaded SWC file.

CC @rcaze who was interested in (and started working on) all this quite some time ago...