-
Notifications
You must be signed in to change notification settings - Fork 221
Open questions: Multicompartmental modeling
See the proposal for a Morphology class.
See the description of the current Morphology class.
There are currently a few problems/inconsistencies with morphologies, especially those created from SWC files:
- While we consider all variables (e.g.
v
) to be taken in the middle of the compartment, coordinatesx
,y
,z
and thedistance
attribute are taken at its end. - In SWC files (and in NEURON), compartments are defined by their start and end points and not by a single 3d coordinate as in Brian at the moment. We can get around this problem for morphologies with a spherical soma (the coordinate defines its center and therefore "anchors" the whole morphology) but for morphologies consisting only of cylindrical compartments (and not starting at the (0, 0, 0) origin) this does not work.
- SWC files/NEURON do not work with cylinders but with truncated cones. In Brian we currently take the diameter at the end of the cone as the diameter for the full cylinder which is not correct.
Proposed solution:
- Either leave
x
,y
,z
,distance
at the end of the compartment and document it clearly, or move everything to the middle for consistency. - Have global (i.e. one per morphology)
origin_x
,origin_y
,origin_z
attributes for each morphology to anchor the morphology at a point. - If we set the diameter of the cylinder to
sqrt(diam_start * diam_end)
, we'll get a cylinder with the equivalent area (and therefore with the equivalent total resistance) to the truncated cone. But this would not give the correct result for the two "half-resistances" which would be equal using this scheme, but different for a truncated cone. So possibly the only solution is to actually have adiameter_start
and adiameter_end
attribute for each compartment. This could be stored in a smart way, since thediameter_end
of one compartment should be identical to thediameter_start
of the following compartment (is this true for branching points as well?) -- on the other hand, it might be worth wasting this negligible amount of memory for simpler code.
See the proposal for a Morphology class for a possible solution.
In SWC files/NEURON, the information about the coordinates is independent from the compartmentalization, i.e. the number of compartments that will be used during the simulation. In Brian, we do not make the difference, i.e. there is one set of coordinates per compartment. This has the disadvantage that detailed reconstructions of neuronal morphologies have many points/compartments, some of them very small/short. We therefore need a mechanism to merge compartments for simulation (splitting compartments is somewhat less important and also easier). The problem is that we cannot merge compartments and at the same time 1) keep the lengths of the compartments consistent with the previous values and 2) keep the spatial coordinates consistent with the lengths.
Proposed solution: Let's not care about the consistency (2), allow morphologies to have inconsistent length and x, y, z values.
To make all of this relatively simple and not too much of a mess:
- All of the morphological attributes can only be set at construction time, i.e.
length
,x
,y
,z
are read-only. I think we can still allow changes todiameter
, this doesn't change anything. - A morphology has a method that returns a new version of the morphology with a different number of compartments. As arguments, this method receives either a target number for the number of compartments or a min/max (electrotonic?) length for each compartment. As mentioned in (1), this morphology would have coordinates that are roughly consistent with the original morphology (mostly for display purposes) but not necessarily with the
length
/distance
information.