Open tclose opened 9 years ago
As we are still yet to specify exactly how Distributions/Functions/Generators
will be specified within a Population
container (see #63) I propose the following syntax
<Population name="pop">
<Size name="pop_size"/><!-- defer size of population to Property Layer, could possibly contain a SizeSendPort from a generator for derived sizes-->
<Cell>
<Dynamics>
<Definition>
<Reference url="http://blah.com">ACellClass</Reference>
</Definition>
</Dynamics>
<DerivedProperty name="morphologyPointCloud">
<Generator>
<!-- A generator that is run for each cell of the population to create its a set of properties for each cell of the population. Could be used for (stylised) "morphologies" -->
<Definition>
<Reference url="http://woo.com">AMorphologyGenerator</Reference>
</Definition>
</Generator>
<!-- Port connections could go here -->
</DerivedProperty>
</Cell>
<DerivedProperty name="x_position">
<Generator>
<!-- A generator that is run over the population to create single properties for each cell of the population -->
<Definition>
<Reference url="http://waa.com">APositionGenerator</Reference>
</Definition>
</Generator>
<!-- Port connections could go here -->
</DerivedProperty>
</Population>
Not particularly sold on DerivedProperty
so suggestions welcome. Could also put the Generators outside of the DerivedProperty
s to allow multiple ports from each generator (useful for generating 3D positions).
This would specify a one-to-many mapping from source-cell to positions but with some extended syntax for multi-compartmental models we could work in a many-to-many mapping via a connection rule to specify which compartments the connections are made onto.
I was thinking that a better name for these intermediaries would be Proxies
and that instead of being part of the Population
, they could be generated as part of a Selection
, since their role would be conceptually very similar to that of a Selection
, i.e. providing an interface between populations and connection rules in order to simplify the connection rules. e.g.
<Selection>
<Proxies>
<Reference>pop</Reference>
<PortMapping name="AMPA" source="AMPA"/>
<ConnectivityParameter name="xPos" dimension="length"/>
<ConnectivityParameter name="yPos" dimension="length"/>
<ConnectivityParameter name="zPos" dimension="length"/>
</Proxies>
</Selection>
and in the Property Layer
<SelectionProperties>
<ProxiesProperties>
<Size>100</Size>
<Property name="xPos">
<FromGenerator port="xPositions">
<Reference>positions</Reference>
</FromGenerator>
</Property>
<Property name="yPos">
<FromGenerator port="yPositions">
<Reference>positions</Reference>
</FromGenerator>
</Property>
<Property name="zPos">
<FromGenerator port="xPositions">
<Reference>positions</Reference>
</FromGenerator>
</Property>
<SharedGenerator name="positions">
<Reference url="http://nineml.net/catalog/2.0/positiongenerators/uniformwithinball.xml">UniformWithinBall</Reference>
<Property name="xOrigin">
<Quantity units="um">
<SingleValue>0.0</SingleValue>
</Quantity>
</Property>
<Property name="yOrigin">
<Quantity units="um">
<SingleValue>0.0</SingleValue>
</Quantity>
</Property>
<Property name="zOrigin">
<Quantity units="um">
<SingleValue>0.0</SingleValue>
</Quantity>
</Property>
<Property name="radius">
<Quantity units="um">
<SingleValue>1.0</SingleValue>
</Quantity>
</Property>
</SharedGenerator>
</ProxiesProperties>
</SelectionProperties>
NB: This syntax is different from the example above in order to match my recent suggestions in #63 and #98. Also, I am not totally happy with the SharedGenerator
syntax so suggestions welcome :)
This could also be useful for multi-compartmental models, where you want to have different ports for different compartments but treat them the same in the connection rule (or have a connection rule that connects to only one of them per neuron not both) e.g.
<Selection name="popAMPASynapses">
<Proxies>
<Reference>pop</Reference>
<PortMapping name="AMPA" source="compart1AMPA"/>
<ConnectivityParameter name="xPos" dimension="length"/>
<ConnectivityParameter name="yPos" dimension="length"/>
<ConnectivityParameter name="zPos" dimension="length"/>
</Proxies>
<Proxies>
<Reference>pop</Reference>
<PortMapping name="AMPA" source="compart2AMPA"/>
<ConnectivityParameter name="xPos" dimension="length"/>
<ConnectivityParameter name="yPos" dimension="length"/>
<ConnectivityParameter name="zPos" dimension="length"/>
</Proxies>
</Selection>
Looking at the example of patchy connectivity in the CSA paper (see #72), reminded me of a connectivity pattern I will need for one of our models. Similar (if not the same) to the patchy connectivity described in the paper mossy fibres the cerebellar cortex sparsely branch out into rosettes and then densely into glomeruli.
So I was thinking this could be modelled using the current proposal for connection rules by adding an intermediate layer object (maybe called a
ConnectionMap
or something like that) that would represent the rosettes (and potentially daisy-chained into a second representing the glomeruli). The distribution of rosettes in the intermediate layer would be relative to the entry point of the mossy fibre and would be created by some kind of generator, then the connectivity would be modelled between the granule cells and the intermediate layer which pass the connections back to the mossy fibre source (I think this is conceptually similar, if not the same, to Mikael's approach).This approach could be generalised by adding arbitrary connection rules between the ConnectionMap and the source cell, and could then probably be used to to map detailed-morphology based connectivity rules (like those in BREP) onto simpler compartmental structures for modelling.