Translate Morphology

[noraabiakar]

Move a morphology/segment tree in space. We already have some support for this using pw_lin and isometry, it would be useful to have the option to modify the morphology itself.

[bcumming]

There are two ways to work directly with morphologies

1. an interface for mutating the morphology, e.g. morphology::apply_isometry(const isometry&)
2. a non-mutating functional interface, e.g. morphology apply_isometry(const morphology&, const isometry&);

In either case, when a model requires a translated copy of every cell, a unique copy of each cell will be created using either technique. So the second approach is preferable, because it maintains our current non-mutating morphology interface.

[halfflat]

Could the use case be made a bit more explicit? I ask because spatial queries for morphologies are handled by embed_pwlin place_pwlin, which already includes the isometry of course.

Translating a morphology for the purposes of making a new cell placed in space would be redundant: we should use the same morphology and a different placement. But if the motivation is to perform manipulations of the point data that goes into constructing a morphology, then segment trees might be the right thing to operate on, rather than morphologies.

[noraabiakar]

I'm going to tag @Helveg because he's the one who requested this feature. We are using embed_pwlin for the time being, but I think he wants the morphology to be the source of truth for other sorts of calculations (this is quite vague, I don't remember the entire context.)

[Helveg]

The purpose is to sanitize the input. The current interface doesn't allow me to read out results of operations on morphologies (does it?).

[halfflat]

The placement interface can provide the results of isometric transformations, but the interface acts on cables, not on regions, and I think we still don't have a Python interface for turning regions into cables.

But at the input stage, you can apply isometries to point-like structs in the C++ API, or to 3-tuples (or n-tuples with n≥3) in the Python API.

[Helveg]

My user need here is to iterate over the tree and get all the 3d points out again that I had put in with a segment tree or by parsing a file. Is that possible? Preferably this addition has the same API (or type if you will) as an untransformed object, so that no special considerations for transformed morphologies are required, i.e.:

duck_morphology = arbor.load_asc("hello.asc")
if sun_is_shining():
  duck_morphology = arbor.apply_isometry(duck_morphology, ...)
duck_should_still_quack(duck_morphology)

I'd like whatever duck_should_still_quack does to work both when the sun is or isn't shining :)

[halfflat]

Hmm .. how does the duck quack test work? :)

If it's testing something about the geometry, then it should either be examining the points in the segment tree — meaning we should be providing a segment tree interface to things like load_asc so that this is easy — or it should be looking at what happens after it is 'placed', in which case the isometry should be used with the placement API and we should be providing methods to make it easier to inspect placed morphologies.

Otherwise, anything simulation related just won't see the effect of applied isometries, unless the displacements are so extreme that rounding error comes into play.

[bcumming]

What does "sanitize the input" mean in this context? I.e. which invariant are you trying to assert?

As @halfflat has pointed out, two cells based on the same morphology with different isometries applied will produce the same results in a simulation. If your duck quacks when a simulation produces the same result, then he will quack after an isometry has been applied.

[Helveg]

It's for purposes outside of simulation and piggyback on arbor's parsers :) In this case it's non-soma/root centered morphologies.

[halfflat]

For this purpose, I'd suggest we should look at the possibility of segment-tree interfaces to the morphology loaders, and ensure that we make it straightforward to apply an isometry to a segment-tree.

[thorstenhater]

1957 allows loading some file formats as segment_trees (plus some more).

1959 allows converting all morphologies into an arbitrary segment_tree.

Since @Helveg is planning on using Arbor for his own nefarious goals, I'll consider the rest his problem.

[thorstenhater]

@Helveg is that ok? If not I'd need a better justification than 'piggy-backing on our parsers' before we invest more effort here.

Note that a segment tree gives you a list of segment = (mpoint d, mpoint p, id), to each endpoint you can apply an isometry which is exposed to Python. Thus, load_swc_raw and fold_map iso.apply(p) over it, constructing a new segment tree with the same structure but translated points.

[Helveg]

Piggy-backing was written down that way for comedic effect. Often, always, people will nitpick for NEURON comparisons. Having read access to the data arbor concretely ends up simulating, is crucial for being able to reconstruct equivalent objects in NEURON.

[thorstenhater]

Then I am less sure how translation specifically is going to help, could you explain? Reason for that is that both Arbor and Neuron get rid of the 3d information and flatten it down to a 1.5d tree, ie all CVs are characterised via length and radius plus parent/child relations.

Also, be aware that even if you had the same segment tree, the discretised CVs will look different. Among other reasons, the terms section and segment do not have the same meaning in Arbor as in Neuron. That's unfortunate, but there's only so many words for these things.