"Generator" component classes and property ports

[tclose]

Along the lines of what Ivan was suggesting for the ConnectionRule syntax, combined with my suggestion of a wider variety of ports, what do you think of this proposal for user-defined function components?

<ComponentClass name="myFunc">
  <Parameter name="power"/>
  <Parameter name="scalar"/>
  <ArgPort name="x"/>
  <ReturnPort name="f"/>
  <Function>
    <Alias name="f">
      <MathInline>scalar * x ^ power</MathInline>
    </Alias>
  </Function>
</ComponentClass>

which could then be referenced in another component as

<ComponentClass name="SimpleDynamics">
  <Dynamics>
    <StateVariable name="y"/>
...
    <Alias name="g">
      <Component>
        <Definition>myFunc</Definition>
        <Property name="power">
          <Quantity>
            <SingleValue>2.0</SingleValue>
          </Quantity>
        </Property>
        <Property name="scalar">
          <Quantity>
            <SingleValue>5.0</SingleValue>
          </Quantity>
        </Property>
        <PortConnection name="x">y</PortConnection>
      </Component>
    </Alias>
  </Dynamics>
</ComponentClass>

Thought this format would be general enough that we could even do away with the ConnectionRule and potentially even the RandomDistribution elements. The only problem being that I just realised this is mixing user and abstraction layer components again...

[tclose]

Potentially this could be extended to allow multiple return ports for cases where a single algorithm (i.e. component) generates two different attributes

[tclose]

On a side note, what do you think of the idea of dropping the Quantity tags for dimensionless quantities instead of providing them with no units? Would be easier to read but would introduce another case to handle...

[tclose]

... or maybe we could save this as a way to refer to integer values

[tclose]

I was thinking that Distribution would be a good name for these functions, and that they should only be used to distribute parameters across a container (i.e. population, projection and multi-compartmental neuron models), as this doesn't mix AL and UL (and within AL functions are probably not necessary as they can always be expanded). E.g.

<ComponentClass name="increasingWeights">
  <Parameter name="scalar" dimension="dimensionless"/>
  <Parameter name="power" dimension="dimensionless"/>
  <IndexReceivePort name="i"/>
  <PropertySendPort name="w" dimension="dimensionless"/>
  <Distribution>
    <Alias name="w">
      <MathInline>scalar * i ^ power</MathInline>
    </Alias>
  </Distribution>
</ComponentClass>

[tclose]

This is closely related to the Property/Index ports issue #73, and probably requires them to be practical I think.

[tclose]

From #73

From the dev2.0 spec

Property ports are used in several distinct situations: in order to pass parameters of cells in a population (such as their spatial coordinates) to ConnectionRule or Distribution components, to return properties from Distribution components and to read properties of neighbouring compartments in multi-compartmental models.

and

IndexReceivePorts receive connections from sources that are implicit to the container, whereas IndexSendPorts are used in Distribution elements used to generate multi-compartmental models.

Does this sound okay?

[tclose]

I was also thinking of a SizeSendPort, which could be used to determine the size of a population from the parameters passed to a distribution component, instead of having to always design them in a way that you need to scale with the size of the population.

[NineML-Committee]

The committee decided that the proposal is accepted, however the name is still under review.

[tclose]

Would you be okay with "Generator" instead of "Distribution" Andrew? I realise that this has a sense of a state associated with it, but that is something I could see us needing at some point.

[apdavison]

"Generator" is ok, although I still prefer "Function" (-:

[tclose]

Okay, how about we work with 'Generator' for now then (as 'Function' doesn't really work for component classes that might just be a random distribution for me).

Probably a more pertinent issue is which layer(s) they should be referenced from. I had originally thought they would referenced in the Structure Layer, as that is where the Dynamics and ConnectionRule component classes are to be referenced, and then just parameterised in the Property Layer. However, I have realised that this probably not a good idea as it would be good to have the flexibility to change the generator type between different parameterisations of the same model (I guess this is what you guys had in mind in any case). Also, we will almost certainly want to reuse them for the State Layer, in which case it wouldn't really work to reference them in the Structure Layer.