Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connection re mapping via proxies #96

Open
tclose opened this issue Apr 6, 2015 · 2 comments
Open

Connection re mapping via proxies #96

tclose opened this issue Apr 6, 2015 · 2 comments

Comments

@tclose
Copy link
Contributor

tclose commented Apr 6, 2015

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.

@tclose
Copy link
Contributor Author

tclose commented Apr 6, 2015

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 DerivedPropertys 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.

@tclose tclose changed the title Connection re mapping via additional layer(s) Connection re mapping via proxies May 18, 2015
@tclose
Copy link
Contributor Author

tclose commented May 18, 2015

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>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant