arbor icon indicating copy to clipboard operation
arbor copied to clipboard

Ignoring subsets of morphology upon loading (from .swc/.asc etc)

Open espenhgn opened this issue 3 years ago • 2 comments

Hi. Discussed briefly with @halfflat whether or not it is possible to ignore/delete certain subsets like axons of morphologies in .swc file format (id tag "2") upon reading them in Arbor, and apparently it is not (except if done manually on the files themselves).

Background: Reconstructions from sources like neuromorpho.org often contain the axon which is good of course for structural analysis, but perhaps less so for simulations focusing on dendritic and somatic responses, as well as recurrent networks. Hence, the elaborate axon geometries are replaced/represented by stylised axons with a few elements (e.g., Mainen & Sejnowski, 1996, https://doi.org/10.1038/382363a0) or an axon stub (Hay et al., 2011, https://doi.org/10.1371/journal.pcbi.1002107). The latter approach is used extensively in the BBP microcircuit neuron models (https://bbp.epfl.ch/nmc-portal/welcome.html).

So basically what I'm looking for is something that would allow me to

  • load a .morphology file
  • delete certain parts of the loaded geometry
  • add new cable elements with geometry of my own choice that is attached to some site on the loaded morphology

espenhgn avatar Jun 21 '21 08:06 espenhgn

Up to now, we'd been working on the assumption that this sort of editing could be performed outside of Arbor, using other tools, and one of the reasons for this was that we thought it would be hard to anticipate the range of possible morphological edits in advance.

That said, you are not alone in wanting such a feature! We've debated on and off how we might supply this.

Would the following schema work?

  1. We operate on the level of the segment tree, rather than the morphology per se.
  2. We support two editing operations: pruning, which splits a tree into two trees; and grafting, which attaches one tree onto another. Segment ids for a pruned or grafted component would be renumbered.
  3. A valid pruning or grafting point is the proximal or distal end of a segment; that segment can be identified by its numeric id, or as the most proximal or most distal segment respectively that has a given tag, if that gives a unique result.

If that's insufficient we could instead do:

  1. Operations are based on morphologies and region/locset expressions.
  2. We support a richer set of composable operations, acting on an enumerated collection of morphologies: i. Prune: remove all subtrees distal to any point in a given locset. ii. Cut: take the subtree distal to a single point defined by a univalent locset. iii. Contract: remove a given region, where for each component in the region, trees distal to that component are attached to the proximal point of that component. iv. Splice: a morphological tree is attached to a point on another morphology defined by a univalent locset.
  3. Only regions and locsets that can be fully determined at the time of evaluation can be used, excluding, for example, random expressions. Labels are interpreted in the context of the morphology on which the selection or mutation operation is being performed.

The latter is much more involved, but would allow, in principle, a declarative description of an editing process to be applied across one or more morphologies. My preference though is for the first option, because it will be much more straightforward to implement.

halfflat avatar Jul 28 '21 14:07 halfflat

Hi @halfflat; For my particular use case I don't see any reason why suggestion 1 should not work. As segment_tree already has the append method I think extending this with say a pop and/or remove operation would make sense (pruning in your terminology). However, if I'm not mistaken, you can not yet expose the corresponding segment_tree after creating a morphology object as morphology=arbor.load_swc_arbor(morphology_file), right?

Have you discussed with other outsiders? I can imagine some would for instance wish to explicitly incorporate spines into their model, in which case only allowing attaching them to the segment prox/distal points could be problematic (even if they would all "see" the same CV membrane voltage).

espenhgn avatar Aug 03 '21 11:08 espenhgn