Extend `instance` to include `rotation` attribute

[sanjayankur31]

At the moment, if a network has many Components of the same cell ComponentType but simply rotated at different angles, one must create a new population for each of these Components since instance allows providing location information, but not rotation related information.

Creating a new population for each Component of the same cell ComponentType is tedius---one has to rotate the cell manually, create a new component for it, and then use this in a new population. It also limits the use of other NeuroML tools---such as visualising connectivity between populations since now we have 100s of populations with one instance each.

I've added a method to rotate the cell (PR: NeuroML/pyNeuroML#218), but it still means that the repository is littered with hundreds of new rotated cells.

So, I propose that we discuss extending the instance ComponentType to also include a rotation or angle attribute to allow us to specify rotated instances of the same cell ComponentType in a population.

Note that this means we will have to handle the rotation when generating simulator code also. So, expected changes will be:

• in the schema
• LEMS definitions
• related org.neuroml.model etc. libraries
• org.neuroml.export: where I expect we will need to rotate cells before exporting them into Neuron and other simulator specific formats.
• visualisation tools (pyneuroml) will have to rotate the cells before plotting

So, a little bit of work for NeuroML, but hopefully worth the improvements/advantages for users?

CC NeuroML editors: @spanag @pgleeson @borismarin @sanjayankur31

[spanag]

Is pure rotation needed and sufficient for a specific model? Having non-uniform orientation of cells over a region makes sense, but at that scale the shapes of cells may also be warped in even more detailed and ad-hoc ways, that either custom transformations would have to be encoded to express in NeuroML (unlikely to cover all users), or every instance would have to be dumped from source data (which would take more space).

Aside: practical support for unique cells would cover many use cases with non-uniformity in biophysics as well as morphologies. NEURON can handle such gracefully by design, and stochastic HOC scripts for constructing trees or importing from explicit data files are not uncommon in the ModelDB.

On the other hand, further customisation (like unique morphologies) will be much more taxing to visualise compared to mesh instancing.

About this suggestion for Euler angles: something that would add to the fidelity with little added effort and cost for rendering, would be to include the full 3x3 linear transformation matrix along with positioning (applied to the 3D points), so that can neurons also be scaled, flipped, squashed or skewed while using the same "base" morphology. (But in that case, the neuron's dynamics may change which is not the case for pure rotation.) (But then, how should this affect the diameter of neurites?)