Changing parameters when an existing comp is used in a ComponentReference

[pgleeson]

e.g. ionChannel in channelDensity

<HHCell id="hhcellScale2" capacitance="1pF" injection="4pA" v0="-60mV">
    <ChannelPopulation channel="na" number="6000"  erev="50mV" />
    <ChannelPopulation channel="kscale" number="1800" erev="-77mV" >
        <set component="kscale" scale="0.5"/>
    </ChannelPopulation>
</HHCell>

See example in development here: https://github.com/LEMS/jLEMS/blob/nml2beta3/src/test/resources/example-channelshift.xml

[pgleeson]

@borismarin this is the issue I mentioned

[borismarin]

Thanks, working on it.

On 12 November 2014 12:32, Padraig Gleeson notifications@github.com wrote:

@borismarin https://github.com/borismarin this is the issue I mentioned

Reply to this email directly or view it on GitHub https://github.com/LEMS/jLEMS/issues/32#issuecomment-62711360.

[borismarin]

It seems to me that a better solution would be having ChannelPopulation define channel as a Child, instead of a ComponentReference. This way, we can use an "anonymous" (i.e. no profusion of id's) Channel that extends a base channel Component (not ComponentType), and set only the "variable" parameter:

 <HHChannelScale id="kscale" conductance="20pS" scale="1">
        <HHGate id="n" power="4">
            <Forward .... />
            <Reverse .... />
        </HHGate>
    </HHChannelScale>

<HHCell id="hhcellScale2" capacitance="1pF" injection="4pA" v0="-60mV">
    <ChannelPopulation number="1800" erev="-77mV" >
        <Channel extends="kscale" scale="0.5"/>
    </ChannelPopulation>
</HHCell>

Currently, it seems that Component extensions do copy attribute values from the parent but not children, so the above code won't work. @robertcannon, are Component extensions supposed to behave like that (i.e., inherit "type" and "state" from the parent)? Would it make sense to make them inherit (copies?) of the parent's Child, Children as well? @pgleeson, what do you think of this solution?

[pgleeson]

Using an extension of an existing, named Component should be fine for the time being. However, this would require a different implementation of ChannelPopulation, which looked for the ion channel as child, as opposed to a ComponentReference.

Using a ComponentReference & defining the ion channel externally should still be the default way to express a ChannelPopulation, since this allows the ion channel to be defined in a separate file, which chould be encouraged.

The new method could be expressed by defining a ComponentType ChannelPopulationModified (or some better name...) and using

<ChannelPopulation type="ChannelPopulationModified" number="1800" erev="-77mV" >
    <Channel extends="kscale" scale="0.5"/>
</ChannelPopulation>

[robertcannon]

Hmm, I'm still not sure what is best.

If you can extend components and override some of their parameters then the extension ought to inherit their children. I'd regard the fact that it doesn't as a bug. ...but, then you also need a mechanism that allows you to override a parameter in a child or you have a rather arbitrary limitation on what you can and can't override.

I don't think local parameters are what you want here because they operate per-instance, not on the model level: in LEMS terms your individually modified cell+channels entity is still a 'model' of which there may be many 'instance's containing the states of the channels but all instances of a particular flavour of model will share the same scale value. Though you could do this with local parameters if, say, you had a 3-compartment model and wanted different scale values on each. But if you had 300 compartments and only 3 distinct values for the scale parameter, you'd end up with lots of duplication.

One solution to Padraig's point would be to remove the distinction between a locally defined component (a Child) and a reference to a component defined elsewhere (a ComponentReference) as far as the schema is concerned. The parent/child hierarchy gives a preferred ancestry for any component and a tree to contain everything that you can easily traverse and be sure to get everything just once. This is convenient for the implementation, but not essential. We should consider what things would look like if there was just a "SubComponent" element that could, interchangeably (ie at the model definition stage, without any difference in the ComponentType), be either a locally defined component or a reference to a component elsewhere.

[borismarin]

In my previous example, nothing prevents the "parent" channel to be defined elsewhere. From a broader point of view, I think we need to decide if we want to allow two different ways of describing the same model (i.e. having channel as an attribute[ComponentReference] or as a Child of ChannelPopulation)? BTW, @robertcannon, do you see a clear conceptual difference in this case?

I'll open a new issue for the "children inheritance" investigation.

[robertcannon]

2nd December, UCL.

We will remove ComponentReference in favour of Child source="..." Override parameter="path" value="new-value"

where the Override is only needed if any parameters are to be changed. Without the source= attribute, a child has to define properties and children in-place as before.

This means some of the Structure elements can be removed too. Structure and Dynamics resolving to be moved into separate classes in jLEMS.