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.

Sign up for GitHub

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

Jump to bottom

Multi-component dynamic models #4

Open
tclose opened this issue Aug 25, 2014 · 22 comments
Open

Multi-component dynamic models #4

tclose opened this issue Aug 25, 2014 · 22 comments
Assignees
@tclose
Labels
accepted dynamics enhancement in develop branch Priority standard extension
Milestone
Version 2.0

Comments

@tclose
Copy link
Contributor

tclose commented Aug 25, 2014

Example:

    <ComponentClass name="Foo">
        <Parameter name="barG" dimension="membrane_conductance"/>
        <Parameter name="C" dimension="membrane_capacitance"/>
        <Parameter name="threshold" dimension="voltage"/>
        <AnalogPort mode="recv" name="celsius" dimension="temperature"/>
        <EventPort name="spike" mode="send"/>
        <Component name="Bar">
            <Definition link="../bar.xml">BarClass</Definition>
            <Property name="g">barG</Property>
            <Property name="e">
                <Value units="mV">-70</Value>
            </Property>
        </Component>
        <Dynamics>
            <StateVariable name="v" dimension="voltage">
                <Initital>
                    <Value units="mV">-65.0</Value>
                </Initital>
            </StateVariable>
            <ComponentDynamics name="BarDyn" component="Bar">
                <ReceivePort name="v">v</ReceivePort>
                <ReceivePort name="celsius">celsius</ReceivePort>
            </ComponentDynamics>
            <Alias name="iBar">
                <ComponentPort compDynamics="BarDyn" port="i"/>
            </Alias>
            <Regime>
                <TimeDerivative variable="v">
                    <MathInline>iBar / C</MathInline>
                </TimeDerivative>
                <OnCondition>
                    <Trigger>
                        <MathML xmlns="http://www.w3.org/...">
                            <gt/>
                            <ci>v</ci>
                            <ci>threshold</ci>
                        </MathML>
                    </Trigger>
                    <EventOut port="spike"/>
                </OnCondition>
            </Regime>
        </Dynamics>
    </ComponentClass>
@tclose
Copy link
Contributor Author

tclose commented Aug 25, 2014

This should allow biophysical point-process models to be (feasibly) implemented in 9ml. It also has the nice side benefit of allowing component classes with partial parameter specifications to be derived from more general classes by including the general class as a sub-component. SBML has a similar hierarchical structure as an extension to the core SBML, which is an approach we could follow. However, I think it would be nice if this made it into the core-9ml specification, thoughts?

The only real complication I can think of is whether to allow regimes within subcomponents or not. This is because it could prove a little tricky flattening regimes back to a single dynamics block, especially when different sub-components are transitioning on potentially different triggers. It could still be possible by generating a new regime in the flattened dynamics block for every combination of sub-component regimes, but it may be simpler for now at least to just prevent sub-components from having multiple regimes.

@apdavison
Copy link
Member

This is already implemented in the Python lib9ml, although without direct XML export (you have to flatten the nested structure before exporting). I will try to come up with a proposal for non-flattened XML export which reflects the approach taken in the Python API, and then we can compare this to Tom’s proposal above.

@iraikov
Copy link
Contributor

iraikov commented Sep 10, 2014

I would suggest adding some kind of type identifier to the subcomponents, similar to how SBML submodels have id and name. Other than that, this proposal seems reasonable.

@tclose
Copy link
Contributor Author

tclose commented Sep 11, 2014

What is the difference between id and name in SBML submodels? In my thinking the 'name' attribute would be a "unique identifier".

@apdavison
Copy link
Member

I strongly dislike mixing user layer and abstraction layer constructs within an abstraction layer definition; put more generally, I dislike mixing model specification and model parameterisation. It was a fundamental design decision of NineML to separate these into different layers.

I think it's fine to have sub-component-classes inside component class definitions. This could look something like:

<ComponentClass name="Hodgkin_Huxley_Na">
    <Dynamics>
        ...
    </Dynamics>
    ...
</ComponentClass>
...
<ComponentClass name="Hodgkin_Huxley_combined">
    <SubComponent name="na">Hodgkin_Huxley_Na</SubComponent>
    <SubComponent name="k">Hodgkin_Huxley_K</SubComponent>
    <SubComponent name="memb">Hodgkin_Huxley_Base</SubComponent>
    <PortConnection from="memb.V" to="na.V"/>
    <PortConnection from="memb.V" to="k.V"/>
    <PortConnection from="na.i" to="memb.i"/>
    <PortConnection from="k.i" to="memb.i"/>
</ComponentClass>

In the user layer, you would use this something like:

<Component name="Hodkgin-Huxley single compartment">
    <Definition link="hh_combined.xml">Hodgkin_Huxley_combined</Definition>
    <Property name="na.gbar">
        <Value units="uS">0.036</Value>
    </Property>
    <Property name="na.e_rev">
        <Value units="mV">40.0</Value>
    </Property>
    <Property name="na.gbar">
        <Value units="uS">0.036</Value>
    </Property>
    <Property name="k.gbar">
        ...
    </Property>
    ...
</Component>

@tclose
Copy link
Contributor Author

tclose commented Sep 19, 2014

Having a default "membrane" sub-component so that you can avoid having to mix sub-components and dynamics blocks is a much better idea than what I proposed. Although I am not a big fan of using '.' notation within the name attributes for referencing the sub-components since it adds another layer of parsing (however trivial) that can't be done with a standard XML parser, so I would prefer a format for the "mixin" component class along the lines of

<ComponentClass name="Hodgkin_Huxley_combined">
  <SubComponent name="na" class="Hodgkin_Huxley_Na">
    <ReceivePort name="V">
      <SendPort component="memb" name="V"/>
    </ReceivePort>
  </SubComponent>
  <SubComponent name="k" class="Hodgkin_Huxley_K">
    <ReceivePort name="V">
      <SendPort component="memb" name="V"/>
    </ReceivePort> 
  </SubComponent>
  <SubComponent name="memb" class="Hodgkin_Huxley_Base">
    <ReceivePort name="i">
      <SendPort component="na" name="i"/>
      <SendPort component="k" name="i"/>
    </ReceivePort> 
  </SubComponent>
</ComponentClass>

which has the added benefit of grouping all the ports that connect to a single "reduce" receive port.

I am fully behind separating the model specification and parameterisation but I don't think that pushing all the parameters for cell model level is going to be practical for complex neuron models. Take the Golgi cell model published by Solineas et al. 2008 for example, the full parameterisation of the cell model would look like this

<?xml version='1.0' encoding='UTF-8'?>
<NineML>
  <component xmlns="http://nineml.incf.org/9ML/0.3" name="Golgi">
    <definition language="NineML">
      <link>/home/tclose/git/kbrain/external/fabios_network/9ml/classes/Golgi.xml</link>
    </definition>
    <property name="BK/Aalpha_c">
      <quantity units="1/ms">
        <scalar>7.0</scalar>
      </quantity>
    </property>
    <property name="BK/Abeta_c">
      <quantity units="1/ms">
        <scalar>1.0</scalar>
      </quantity>
    </property>
    <property name="BK/Balpha_c">
      <quantity units="mM">
        <scalar>0.0015</scalar>
      </quantity>
    </property>
    <property name="BK/Bbeta_c">
      <quantity units="mM">
        <scalar>0.00015</scalar>
      </quantity>
    </property>
    <property name="BK/Kalpha_c">
      <quantity units="mV">
        <scalar>-11.765</scalar>
      </quantity>
    </property>
    <property name="BK/Kbeta_c">
      <quantity units="mV">
        <scalar>-11.765</scalar>
      </quantity>
    </property>
    <property name="BK/Q10">
      <quantity units="dimensionless">
        <scalar>3.0</scalar>
      </quantity>
    </property>
    <property name="BK/gkbar">
      <quantity units="mho/cm^2">
        <scalar>0.003</scalar>
      </quantity>
    </property>
    <property name="Ca_HVA/Aalpha_s">
      <quantity units="1/ms">
        <scalar>0.04944</scalar>
      </quantity>
    </property>
    <property name="Ca_HVA/Aalpha_u">
      <quantity units="1/ms">
        <scalar>0.0013</scalar>
      </quantity>
    </property>
    <property name="Ca_HVA/Abeta_s">
      <quantity units="1/ms">
        <scalar>0.08298</scalar>
      </quantity>
    </property>
    <property name="Ca_HVA/Abeta_u">
      <quantity units="1/ms">
        <scalar>0.0013</scalar>
      </quantity>
    </property>
    <property name="Ca_HVA/Kalpha_s">
      <quantity units="mV">
        <scalar>15.87301587302</scalar>
      </quantity>
    </property>
    <property name="Ca_HVA/Kalpha_u">
      <quantity units="mV">
        <scalar>-18.183</scalar>
      </quantity>
    </property>
    <property name="Ca_HVA/Kbeta_s">
      <quantity units="mV">
        <scalar>-25.641</scalar>
      </quantity>
    </property>
    <property name="Ca_HVA/Kbeta_u">
      <quantity units="mV">
        <scalar>83.33</scalar>
      </quantity>
    </property>
    <property name="Ca_HVA/Q10">
      <quantity units="dimensionless">
        <scalar>3.0</scalar>
      </quantity>
    </property>
    <property name="Ca_HVA/V0alpha_s">
      <quantity units="mV">
        <scalar>-29.06</scalar>
      </quantity>
    </property>
    <property name="Ca_HVA/V0alpha_u">
      <quantity units="mV">
        <scalar>-48.0</scalar>
      </quantity>
    </property>
    <property name="Ca_HVA/V0beta_s">
      <quantity units="mV">
        <scalar>-18.66</scalar>
      </quantity>
    </property>
    <property name="Ca_HVA/V0beta_u">
      <quantity units="mV">
        <scalar>-48.0</scalar>
      </quantity>
    </property>
    <property name="Ca_HVA/gcabar">
      <quantity units="mho/cm^2">
        <scalar>0.00046</scalar>
      </quantity>
    </property>
    <property name="CALC_ca2/beta">
      <quantity units="1/ms">
        <scalar>1.3</scalar>
      </quantity>
    </property>
    <property name="CALC_ca2/ca2i0">
      <quantity units="mM">
        <scalar>5e-05</scalar>
      </quantity>
    </property>
    <property name="CALC_ca2/d">
      <quantity units="um">
        <scalar>0.2</scalar>
      </quantity>
    </property>
    <property name="CALC/beta">
      <quantity units="1/ms">
        <scalar>1.3</scalar>
      </quantity>
    </property>
    <property name="CALC/cai0">
      <quantity units="mM">
        <scalar>5e-05</scalar>
      </quantity>
    </property>
    <property name="CALC/d">
      <quantity units="um">
        <scalar>0.2</scalar>
      </quantity>
    </property>
    <property name="Ca_LVA/A_tau_h">
      <quantity units="dimensionless">
        <scalar>1.0</scalar>
      </quantity>
    </property>
    <property name="Ca_LVA/A_tau_m">
      <quantity units="dimensionless">
        <scalar>1.0</scalar>
      </quantity>
    </property>
    <property name="Ca_LVA/C_tau_h">
      <quantity units="dimensionless">
        <scalar>85.0</scalar>
      </quantity>
    </property>
    <property name="Ca_LVA/C_tau_m">
      <quantity units="dimensionless">
        <scalar>3.0</scalar>
      </quantity>
    </property>
    <property name="Ca_LVA/gca2bar">
      <quantity units="mho/cm^2">
        <scalar>0.00025</scalar>
      </quantity>
    </property>
    <property name="Ca_LVA/k_h_inf">
      <quantity units="mV">
        <scalar>5.0</scalar>
      </quantity>
    </property>
    <property name="Ca_LVA/k_m_inf">
      <quantity units="mV">
        <scalar>-7.4</scalar>
      </quantity>
    </property>
    <property name="Ca_LVA/k_tau_h1">
      <quantity units="mV">
        <scalar>4.0</scalar>
      </quantity>
    </property>
    <property name="Ca_LVA/k_tau_h2">
      <quantity units="mV">
        <scalar>-50.0</scalar>
      </quantity>
    </property>
    <property name="Ca_LVA/k_tau_m1">
      <quantity units="mV">
        <scalar>10.0</scalar>
      </quantity>
    </property>
    <property name="Ca_LVA/k_tau_m2">
      <quantity units="mV">
        <scalar>-15.0</scalar>
      </quantity>
    </property>
    <property name="Ca_LVA/shift">
      <quantity units="mV">
        <scalar>2.0</scalar>
      </quantity>
    </property>
    <property name="Ca_LVA/v0_h_inf">
      <quantity units="mV">
        <scalar>-78.0</scalar>
      </quantity>
    </property>
    <property name="Ca_LVA/v0_m_inf">
      <quantity units="mV">
        <scalar>-50.0</scalar>
      </quantity>
    </property>
    <property name="Ca_LVA/v0_tau_h1">
      <quantity units="mV">
        <scalar>-46.0</scalar>
      </quantity>
    </property>
    <property name="Ca_LVA/v0_tau_h2">
      <quantity units="mV">
        <scalar>-405.0</scalar>
      </quantity>
    </property>
    <property name="Ca_LVA/v0_tau_m1">
      <quantity units="mV">
        <scalar>-25.0</scalar>
      </quantity>
    </property>
    <property name="Ca_LVA/v0_tau_m2">
      <quantity units="mV">
        <scalar>-100.0</scalar>
      </quantity>
    </property>
    <property name="hcn1/Ehalf">
      <quantity units="mV">
        <scalar>-72.49</scalar>
      </quantity>
    </property>
    <property name="hcn1/Erev">
      <quantity units="mV">
        <scalar>-20.0</scalar>
      </quantity>
    </property>
    <property name="hcn1/c">
      <quantity units="1/mV">
        <scalar>0.11305</scalar>
      </quantity>
    </property>
    <property name="hcn1/gbar">
      <quantity units="S/cm^2">
        <scalar>5e-05</scalar>
      </quantity>
    </property>
    <property name="hcn1/q_10">
      <quantity units="dimensionless">
        <scalar>3.0</scalar>
      </quantity>
    </property>
    <property name="hcn1/rA">
      <quantity units="1/mV">
        <scalar>0.002096</scalar>
      </quantity>
    </property>
    <property name="hcn1/rB">
      <quantity units="dimensionless">
        <scalar>0.97596</scalar>
      </quantity>
    </property>
    <property name="hcn1/tCf">
      <quantity units="dimensionless">
        <scalar>0.01371</scalar>
      </quantity>
    </property>
    <property name="hcn1/tCs">
      <quantity units="dimensionless">
        <scalar>0.01451</scalar>
      </quantity>
    </property>
    <property name="hcn1/tDf">
      <quantity units="mV">
        <scalar>-3.368</scalar>
      </quantity>
    </property>
    <property name="hcn1/tDs">
      <quantity units="mV">
        <scalar>-4.056</scalar>
      </quantity>
    </property>
    <property name="hcn1/tEf">
      <quantity units="1/mV">
        <scalar>2.302585092</scalar>
      </quantity>
    </property>
    <property name="hcn1/tEs">
      <quantity units="1/mV">
        <scalar>2.302585092</scalar>
      </quantity>
    </property>
    <property name="hcn2/Ehalf">
      <quantity units="mV">
        <scalar>-81.95</scalar>
      </quantity>
    </property>
    <property name="hcn2/c">
      <quantity units="1/mV">
        <scalar>0.1661</scalar>
      </quantity>
    </property>
    <property name="hcn2/ehcn2">
      <quantity units="mV">
        <scalar>-20.0</scalar>
      </quantity>
    </property>
    <property name="hcn2/gbar">
      <quantity units="S/cm^2">
        <scalar>8e-05</scalar>
      </quantity>
    </property>
    <property name="hcn2/q_10">
      <quantity units="dimensionless">
        <scalar>3.0</scalar>
      </quantity>
    </property>
    <property name="hcn2/rA">
      <quantity units="1/mV">
        <scalar>-0.0227</scalar>
      </quantity>
    </property>
    <property name="hcn2/rB">
      <quantity units="dimensionless">
        <scalar>-1.4694</scalar>
      </quantity>
    </property>
    <property name="hcn2/tCf">
      <quantity units="dimensionless">
        <scalar>0.0269</scalar>
      </quantity>
    </property>
    <property name="hcn2/tCs">
      <quantity units="dimensionless">
        <scalar>0.0152</scalar>
      </quantity>
    </property>
    <property name="hcn2/tDf">
      <quantity units="mV">
        <scalar>-5.6111</scalar>
      </quantity>
    </property>
    <property name="hcn2/tDs">
      <quantity units="mV">
        <scalar>-5.2944</scalar>
      </quantity>
    </property>
    <property name="hcn2/tEf">
      <quantity units="1/mV">
        <scalar>2.3026</scalar>
      </quantity>
    </property>
    <property name="hcn2/tEs">
      <quantity units="1/mV">
        <scalar>2.3026</scalar>
      </quantity>
    </property>
    <property name="KA/Aalpha_a">
      <quantity units="1/ms">
        <scalar>0.8147</scalar>
      </quantity>
    </property>
    <property name="KA/Aalpha_b">
      <quantity units="1/ms">
        <scalar>0.0368</scalar>
      </quantity>
    </property>
    <property name="KA/Abeta_a">
      <quantity units="1/ms">
        <scalar>0.1655</scalar>
      </quantity>
    </property>
    <property name="KA/Abeta_b">
      <quantity units="1/ms">
        <scalar>0.0345</scalar>
      </quantity>
    </property>
    <property name="KA/K_ainf">
      <quantity units="mV">
        <scalar>-17.0</scalar>
      </quantity>
    </property>
    <property name="KA/K_binf">
      <quantity units="mV">
        <scalar>8.4</scalar>
      </quantity>
    </property>
    <property name="KA/Kalpha_a">
      <quantity units="mV">
        <scalar>-23.32708</scalar>
      </quantity>
    </property>
    <property name="KA/Kalpha_b">
      <quantity units="mV">
        <scalar>12.8433</scalar>
      </quantity>
    </property>
    <property name="KA/Kbeta_a">
      <quantity units="mV">
        <scalar>19.47175</scalar>
      </quantity>
    </property>
    <property name="KA/Kbeta_b">
      <quantity units="mV">
        <scalar>-8.90123</scalar>
      </quantity>
    </property>
    <property name="KA/Q10">
      <quantity units="dimensionless">
        <scalar>3.0</scalar>
      </quantity>
    </property>
    <property name="KA/V0_ainf">
      <quantity units="mV">
        <scalar>-38.0</scalar>
      </quantity>
    </property>
    <property name="KA/V0_binf">
      <quantity units="mV">
        <scalar>-78.8</scalar>
      </quantity>
    </property>
    <property name="KA/V0alpha_a">
      <quantity units="mV">
        <scalar>-9.17203</scalar>
      </quantity>
    </property>
    <property name="KA/V0alpha_b">
      <quantity units="mV">
        <scalar>-111.33209</scalar>
      </quantity>
    </property>
    <property name="KA/V0beta_a">
      <quantity units="mV">
        <scalar>-18.27914</scalar>
      </quantity>
    </property>
    <property name="KA/V0beta_b">
      <quantity units="mV">
        <scalar>-49.9537</scalar>
      </quantity>
    </property>
    <property name="KA/gkbar">
      <quantity units="mho/cm^2">
        <scalar>0.008</scalar>
      </quantity>
    </property>
    <property name="KM/Aalpha_n">
      <quantity units="1/ms">
        <scalar>0.0033</scalar>
      </quantity>
    </property>
    <property name="KM/Abeta_n">
      <quantity units="1/ms">
        <scalar>0.0033</scalar>
      </quantity>
    </property>
    <property name="KM/B_ninf">
      <quantity units="mV">
        <scalar>6.0</scalar>
      </quantity>
    </property>
    <property name="KM/Kalpha_n">
      <quantity units="mV">
        <scalar>40.0</scalar>
      </quantity>
    </property>
    <property name="KM/Kbeta_n">
      <quantity units="mV">
        <scalar>-20.0</scalar>
      </quantity>
    </property>
    <property name="KM/Q10">
      <quantity units="dimensionless">
        <scalar>3.0</scalar>
      </quantity>
    </property>
    <property name="KM/V0_ninf">
      <quantity units="mV">
        <scalar>-35.0</scalar>
      </quantity>
    </property>
    <property name="KM/V0alpha_n">
      <quantity units="mV">
        <scalar>-30.0</scalar>
      </quantity>
    </property>
    <property name="KM/V0beta_n">
      <quantity units="mV">
        <scalar>-30.0</scalar>
      </quantity>
    </property>
    <property name="KM/gkbar">
      <quantity units="mho/cm^2">
        <scalar>0.001</scalar>
      </quantity>
    </property>
    <property name="KV/Aalpha_n">
      <quantity units="dimensionless">
        <scalar>-0.01</scalar>
      </quantity>
    </property>
    <property name="KV/Abeta_n">
      <quantity units="1/ms">
        <scalar>0.125</scalar>
      </quantity>
    </property>
    <property name="KV/Kalpha_n">
      <quantity units="mV">
        <scalar>-10.0</scalar>
      </quantity>
    </property>
    <property name="KV/Kbeta_n">
      <quantity units="mV">
        <scalar>-80.0</scalar>
      </quantity>
    </property>
    <property name="KV/Q10">
      <quantity units="dimensionless">
        <scalar>3.0</scalar>
      </quantity>
    </property>
    <property name="KV/V0alpha_n">
      <quantity units="mV">
        <scalar>-26.0</scalar>
      </quantity>
    </property>
    <property name="KV/V0beta_n">
      <quantity units="mV">
        <scalar>-36.0</scalar>
      </quantity>
    </property>
    <property name="KV/gkbar">
      <quantity units="mho/cm^2">
        <scalar>0.032</scalar>
      </quantity>
    </property>
    <property name="lkg/el">
      <quantity units="mV">
        <randomDistribution>
          <definition>
            <link>../nineml_catalog/randomdistributions/uniform_distribution.xml
            </link>
          </definition>
          <property name="low">
            <quantity units="dimensionless">
              <scalar>-19.8</scalar>
            </quantity>
          </parameter>
          <property name="high">
            <quantity units="dimensionless">
              <scalar>-13.2</scalar>
            </quantity>
          </parameter>
        </randomDistribution>                             
      </quantity>
    </property>
    <property name="lkg/glbar">
      <quantity units="mho/cm^2">
        <scalar>2.1e-05</scalar>
      </quantity>
    </property>
    <property name="NaP/Aalpha_m">
      <quantity units="dimensionless">
        <scalar>-0.91</scalar>
      </quantity>
    </property>
    <property name="NaP/Abeta_m">
      <quantity units="dimensionless">
        <scalar>0.62</scalar>
      </quantity>
    </property>
    <property name="NaP/B_minf">
      <quantity units="mV">
        <scalar>5.0</scalar>
      </quantity>
    </property>
    <property name="NaP/Kalpha_m">
      <quantity units="mV">
        <scalar>-5.0</scalar>
      </quantity>
    </property>
    <property name="NaP/Kbeta_m">
      <quantity units="mV">
        <scalar>5.0</scalar>
      </quantity>
    </property>
    <property name="NaP/Q10">
      <quantity units="dimensionless">
        <scalar>3.0</scalar>
      </quantity>
    </property>
    <property name="NaP/V0_minf">
      <quantity units="mV">
        <scalar>-43.0</scalar>
      </quantity>
    </property>
    <property name="NaP/V0alpha_m">
      <quantity units="mV">
        <scalar>-40.0</scalar>
      </quantity>
    </property>
    <property name="NaP/V0beta_m">
      <quantity units="mV">
        <scalar>-40.0</scalar>
      </quantity>
    </property>
    <property name="NaP/gbar">
      <quantity units="mho/cm^2">
        <scalar>0.00019</scalar>
      </quantity>
    </property>
    <property name="NaR/Aalpha_f">
      <quantity units="1/ms">
        <scalar>0.31836</scalar>
      </quantity>
    </property>
    <property name="NaR/Aalpha_s">
      <quantity units="1/ms">
        <scalar>-0.00493</scalar>
      </quantity>
    </property>
    <property name="NaR/Abeta_f">
      <quantity units="1/ms">
        <scalar>0.01014</scalar>
      </quantity>
    </property>
    <property name="NaR/Abeta_s">
      <quantity units="1/ms">
        <scalar>0.01558</scalar>
      </quantity>
    </property>
    <property name="NaR/Kalpha_f">
      <quantity units="mV">
        <scalar>-62.5262</scalar>
      </quantity>
    </property>
    <property name="NaR/Kalpha_s">
      <quantity units="mV">
        <scalar>-6.81881</scalar>
      </quantity>
    </property>
    <property name="NaR/Kbeta_f">
      <quantity units="mV">
        <scalar>16.0538</scalar>
      </quantity>
    </property>
    <property name="NaR/Kbeta_s">
      <quantity units="mV">
        <scalar>0.10818</scalar>
      </quantity>
    </property>
    <property name="NaR/Q10">
      <quantity units="dimensionless">
        <scalar>3.0</scalar>
      </quantity>
    </property>
    <property name="NaR/Shiftalpha_s">
      <quantity units="1/ms">
        <scalar>8e-05</scalar>
      </quantity>
    </property>
    <property name="NaR/Shiftbeta_s">
      <quantity units="1/ms">
        <scalar>0.04752</scalar>
      </quantity>
    </property>
    <property name="NaR/V0alpha_f">
      <quantity units="mV">
        <scalar>-80.0</scalar>
      </quantity>
    </property>
    <property name="NaR/V0alpha_s">
      <quantity units="mV">
        <scalar>-4.48754</scalar>
      </quantity>
    </property>
    <property name="NaR/V0beta_f">
      <quantity units="mV">
        <scalar>-83.3332</scalar>
      </quantity>
    </property>
    <property name="NaR/V0beta_s">
      <quantity units="mV">
        <scalar>43.9749</scalar>
      </quantity>
    </property>
    <property name="NaR/gnabar">
      <quantity units="mho/cm^2">
        <scalar>0.0017</scalar>
      </quantity>
    </property>
    <property name="Na/Aalpha_h">
      <quantity units="1/ms">
        <scalar>0.21</scalar>
      </quantity>
    </property>
    <property name="Na/Aalpha_m">
      <quantity units="dimensionless">
        <scalar>0.3</scalar>
      </quantity>
    </property>
    <property name="Na/Abeta_h">
      <quantity units="1/ms">
        <scalar>3.0</scalar>
      </quantity>
    </property>
    <property name="Na/Abeta_m">
      <quantity units="1/ms">
        <scalar>12.0</scalar>
      </quantity>
    </property>
    <property name="Na/Kalpha_h">
      <quantity units="mV">
        <scalar>-3.333</scalar>
      </quantity>
    </property>
    <property name="Na/Kalpha_m">
      <quantity units="mV">
        <scalar>-10.0</scalar>
      </quantity>
    </property>
    <property name="Na/Kbeta_h">
      <quantity units="mV">
        <scalar>-5.0</scalar>
      </quantity>
    </property>
    <property name="Na/Kbeta_m">
      <quantity units="mV">
        <scalar>-18.182</scalar>
      </quantity>
    </property>
    <property name="Na/Q10">
      <quantity units="dimensionless">
        <scalar>3.0</scalar>
      </quantity>
    </property>
    <property name="Na/V0alpha_h">
      <quantity units="mV">
        <scalar>-50.0</scalar>
      </quantity>
    </property>
    <property name="Na/V0alpha_m">
      <quantity units="mV">
        <scalar>-25.0</scalar>
      </quantity>
    </property>
    <property name="Na/V0beta_h">
      <quantity units="mV">
        <scalar>-17.0</scalar>
      </quantity>
    </property>
    <property name="Na/V0beta_m">
      <quantity units="mV">
        <scalar>-50.0</scalar>
      </quantity>
    </property>
    <property name="Na/gnabar">
      <quantity units="mho/cm^2">
        <scalar>0.048</scalar>
      </quantity>
    </property>
    <property name="SK2/Q10">
      <quantity units="dimensionless">
        <scalar>3.0</scalar>
      </quantity>
    </property>
    <property name="SK2/diff">
      <quantity units="dimensionless">
        <scalar>3.0</scalar>
      </quantity>
    </property>
    <property name="SK2/dirc2">
      <quantity units="dimensionless">
        <scalar>200.0</scalar>
      </quantity>
    </property>
    <property name="SK2/dirc3">
      <quantity units="dimensionless">
        <scalar>160.0</scalar>
      </quantity>
    </property>
    <property name="SK2/dirc4">
      <quantity units="dimensionless">
        <scalar>80.0</scalar>
      </quantity>
    </property>
    <property name="SK2/diro1">
      <quantity units="dimensionless">
        <scalar>0.16</scalar>
      </quantity>
    </property>
    <property name="SK2/diro2">
      <quantity units="dimensionless">
        <scalar>1.2</scalar>
      </quantity>
    </property>
    <property name="SK2/gkbar">
      <quantity units="mho/cm^2">
        <scalar>0.038</scalar>
      </quantity>
    </property>
    <property name="SK2/invc1">
      <quantity units="dimensionless">
        <scalar>0.08</scalar>
      </quantity>
    </property>
    <property name="SK2/invc2">
      <quantity units="dimensionless">
        <scalar>0.08</scalar>
      </quantity>
    </property>
    <property name="SK2/invc3">
      <quantity units="dimensionless">
        <scalar>0.2</scalar>
      </quantity>
    </property>
    <property name="SK2/invo1">
      <quantity units="dimensionless">
        <scalar>1.0</scalar>
      </quantity>
    </property>
    <property name="SK2/invo2">
      <quantity units="dimensionless">
        <scalar>0.1</scalar>
      </quantity>
    </property>
  </component>
</NineML>

Also, many of the ion-channels are reused between different models, which would then lead to a lot of duplication of the parameters. Any changes could then become quite unmanageable particularly given the long lists of parameters that need to be searched. It also becomes more difficult to spot parameters that are distributed across the network (or dendritic tree) as they are lost in amongst the more "stable" kinetics parameters.

So if we agree that the abstraction layer shouldn't contain any parameters, maybe the question should be where we draw the line between abstraction and user layer in these cases. A solution could be to allow "partial specifications" of component classes within the user layer, which could then be used in lieu of component classes in other user layer specifications. The partial specifications would then pass down their parameters to sub-components, enabling the definition of relationships between sub-component parameters, eg.

<ComponentPartial name="Pyramidal_cell">
    <Parameter name="gbar_na" dimension="membrane_conductance">
    <Component>
      <Definition link="hh_combined.xml">Hodgkin_Huxley_combined</Definition>
      <Property name="na/gbar">
        gbar_na
      </Property>
      <Property name="na/e_rev">
        <Value units="mV">40.0</Value>
      </Property>
      <Property name="k/gbar">
        <MathInline>gbar_na * 10</MathInline>
      </Property>
     <Component>
    ...
</ComponentPartial>

It then should be obvious which parameters are to be varied across the population/dendritic tree (typically the most interesting) and which are constant.

Perhaps the "mixin" component class could even become part of the user layer too, which would align us more closely with how NeuroML2 does things I think. Each of the sub-components could then be partially specified, and then combined together in the mixin class, which could potentially use the same tags as the partial specification

<ComponentPartial name="Pyramidal_cell">
    <Parameter name="g_leak" dimension="membrane_conductance">
    <Component name="Na">
      <Definition>PyramidalNa</Definition>
      <Property name="gbar">
        <quantity units="uS">0.0036</quantity>
      </Property>
    </Component>
    <Component name="K">
      <Definition>PyramidalK</Definition>
      <Property name="gbar">
        <quantity units="uS">0.0025</quantity>
      </Property>
    </Component>
    <Component name="leak">
      <Definition>Leak</Definition>
      <Property name="g">g_leak</Property>
      <Property name="e_rev">
        <quantity units="mV">-21</quantity>
      </Property>
    </Component>
    ...
</ComponentPartial>

This is also a bit nicer since the distribution of ion channels would be specified at the cell level (as part of the gbar parameter) whereas the kinetics are specified at the ion channel level.

@apdavison
Copy link
Member

Whew, long post! On the issue of the dot notation, I agree with you, I just couldn't think of a good notation to avoid it. I really like your proposal, although I'm a little worried that the names <SendPort> and <ReceivePort> will cause confusion due to the similarity to <EventPort>, <AnalogPort>, etc., which have a quite different meaning.

How about something like:

    <PortConnection receiver="i">
      <Sender component="na" name="i"/>
      <Sender component="k" name="i"/>
    </PortConnection>

? although I don't much like that either.

@apdavison
Copy link
Member

The idea of "partial specifications" rings a bell. I have a vague memory that we discussed something like this, and that it even went into the specification at some point. The idea was a little different: rather than a partial specification, you would give a full specification of one component and then other components would be based on this one, with "patches" to define those parameters that differ.

I'm not sure at this point whether I prefer this "prototype-plus-changes" idea or your "partial-specification" proposal.

Finally, I think I agree that if we allow a nested structure in the abstraction layer, we should really have a nested structure in the user layer as well, something like what you propose. This should allow us to avoid the problem of repetition in parameterisation. We are then getting pretty close to LEMS, I think. I really need to take another close look at LEMS to remind myself how it works.

@tclose
Copy link
Contributor Author

tclose commented Sep 19, 2014

Yes sorry, it was a bit ridiculously long. I have been working on a Hoc/NMODL to 9ML converter and was able to spit out all the parameters and thought it would illustrate my point nicely but it was probably a tiny bit excessive ;)

I am not attached to the names of the "Send" and "Receive" ports so would be happy to go with PortConnection/Sender if you prefer.

I meant to include the port structure in that last example so it would look like

<ComponentPartial name="Pyramidal_cell">
    <Parameter name="g_leak" dimension="membrane_conductance">
    <Component name="Na">
      <Definition>PyramidalNa</Definition>
      <Property name="gbar">
        <quantity units="uS">0.0036</quantity>
      </Property>
      <PortConnection receiver="V">
        <Sender component="memb" name="V"/>
      </PortConnection>
    </Component>
    <Component name="K">
      <Definition>PyramidalK</Definition>
      <Property name="gbar">
        <quantity units="uS">0.0025</quantity>
      </Property>
      <PortConnection receiver="V">
        <Sender component="memb" name="V"/>
      </PortConnection>
    </Component>
    <Component name="leak">
      <Definition>Leak</Definition>
      <Property name="g">g_leak</Property>
      <Property name="e_rev">
        <quantity units="mV">-21</quantity>
      </Property>
      <PortConnection receiver="V">
        <Sender component="memb" name="V"/>
      </PortConnection>
    </Component>
   <Component name="memb" class="Hodgkin_Huxley_Base">
      <Definition>Membrane</Definition>
      <Property name="cm">
        <Quantity units="uF/cm^2">
          <Scalar>1.0</Scalar>
        </Quantity>
      </Property>
      <PortConnection receiver="i">
        <Sender component="na" name="i"/>
        <Sender component="k" name="i"/>
      </PortConnection>
  </Component>
</ComponentPartial>

@tclose
Copy link
Contributor Author

tclose commented Sep 19, 2014

Patches on existing models would be an interesting idea, and would make it particularly easy to extend existing models but my feeling is this could get quite messy. For example, if you were looking through the template code (where most of the parameters would be stored) you wouldn't know which values were overridden or not, which is one of my pet hates with NMODL/Hoc.

@tclose
Copy link
Contributor Author

tclose commented Sep 19, 2014

I was speaking with Padraig the other day and trying to work out the main differences between NeuroML2/LEMS and where we are headed with NineML. It seems to me that the main ones are that some things in NeuroML2, such as "port" connections to membrane voltage and ion concentrations, are handled implicitly, which reduces a fair bit of overhead on the designer but can lead you into some sticky situations if you want to do advanced handling of ionic concentrations.

Other than that, the only other issue I would have with LEMS is that it favours attributes over elements, which limits the flexibility you have to extend those attributes/elements later on in my book. Also, I think the inheritance structure is a bit of an unnecessary burden on implementers. Otherwise, I think we are headed in a fairly similar direction and hopefully we can converge at some point down the line.

@tclose
Copy link
Contributor Author

tclose commented Sep 21, 2014

I was thinking after my last post that putting the port connections in the user layer wasn't what you had in mind Andrew, so came up with an alternative format in which the port connections are in the abstraction layer:

<ComponentClass name="HodgkinHuxleyContainer" type="dynamics_container">
  <Domain>
    <SubComponent target="Na">
      <PortConnection receiver="V">
        <Sender component="memb" name="V"/>
      </PortConnection>
    </SubComponent>
    <SubComponent target="K">
      <PortConnection receiver="V">
        <Sender component="memb" name="V"/>
      </PortConnection>
    </SubComponent>
    <SubComponent target="leak">
      <PortConnection receiver="V">
        <Sender component="memb" name="V"/>
      </PortConnection>
    </SubComponent>
    <SubComponent target="membrane">
      <PortConnection receiver="i">
        <Sender component="na" name="i"/>
        <Sender component="k" name="i"/>
      </PortConnection>
    </SubComponent>
  </Domain>
</ComponentClass>

and all the parameters in the user layer

<ComponentPartial name="Pyramidal_cell">
  <Definition>HodgkinHuxeleyContainer</Definition>
  <Parameter name="g_leak" dimension="membrane_conductance"/>
  <Component name="Na">
    <Definition>PyramidalNa</Definition>
    <Property name="gbar">
      <Quantity units="uS">
        <Scalar>0.0036</Scalar>
      </Quantity>
    </Property>
  </Component>
  <Component name="K">
    <Definition>PyramidalK</Definition>
    <Property name="gbar">
      <Quantity units="uS">
        <Scalar>0.0025</Scalar>
      </Quantity>
    </Property>
  </Component>
  <Component name="leak">
    <Definition>Leak</Definition>
    <Property name="g">g_leak</Property>
    <Property name="e_rev">
      <Quantity units="mV">
        <Scalar>-21</Scalar>
      </Quantity>
    </Property>
  </Component>
  <Component name="membrane">
    <Definition>Membrane</Definition>
    <Property name="cm">
      <Quantity units="uF/cm^2">
        <Scalar>1.0</Scalar>
      </Quantity>
    </Property>
  </Component>
</ComponentPartial>

where the components in the user layer could be parameterising component classes directly or partially specified components. I had thought of specifying the component class of each subcomponent in the component class definition but this way would allow duck typing of sub-component classes on with the sole requirement being the analog ports they specify. The 'domain' tag in the component class, is me trying to look ahead to multi-compartment definitions as I have in mind "domains" of spatial compartments which contain the same sub-components and interactions between sub-components (I will create a new issue expanding on this idea at some point).

I quite like the idea of duck-typing sub-components and so am quite happy with this format. However, I am still not sure whether the "container" class belongs in the user or abstraction layer. I suppose it depends what we want the user layer to represent, just the parameterisation or anything a "user" (I am envisaging wet-lab scientist with limited computing knowledge) would be interested in changing, which would almost certainly include the types of ion channels that are included.

@pgleeson
Copy link

Regarding usage of subcomponents, I would highly recommend looking again at how LEMS does it. It's all described in the paper (http://journal.frontiersin.org/Journal/10.3389/fninf.2014.00079/abstract) and leads to a much more compact description of channels and cells. While readability isn't a priority with NineML, remember that most modellers still write their own scripts, and if an application developer can read a short file and understand what it does their more likely to support the format.

Bear in mind too that:

  • this way of specifying child components has been used in LEMS for >4 years and has required no major changes in that time
  • We've used it to specify multiple types of channels & cells incl Nernst & GHK currents and some unconventional channels
  • Components can be flattened easily and there already exists stable mappings from this format to NEURON.

@tclose I get your concern that that using the containment of components to connect currents etc. "can lead you into some sticky situations if you want to do advanced handling of ionic concentrations", but it's handled almost everything we've thrown at it so far, and it's probably better to get a straightforward way to handle 95% of cases rather than try designing from the start something to handle all the edge cases too. Also, inheritance/extension has been absolutely crucial to building NeuroML 2 on top of LEMS; otherwise there would be nothing to link channels/cells/synapses as being of the same class of model apart from strings/metadata that may change in the future.

In short, a lot of these issues above have already been solved in working code (this holds for units/dimensions too). Perfectly fine for you to reimplement/redesign all of this, but I do think you could move forward a long way by incorporating some of these ideas.

@tclose
Copy link
Contributor Author

tclose commented Sep 30, 2014

Hi Padraig,

I understand that you guys have put a lot of work into this problem over the last 4 years and as I said I don't expect we will end up too far from where you have gone with LEMS/NeuroML2. However, I think there is still a significant philosophical difference between the two approaches, highlighted but the implicit vs explicit handling of ion concentrations, which warrants us continuing to work on an alternative to LEMS/NeuroML2.

I definitely see the benefit of of compact representations, especially since I see myself mainly hand-writing/reading code for the foreseeable future. However, in my mind, sacrificing compactness to ensure smooth handling of corner cases is a fundamental tenet of NineML for a number of reasons. For one, it should make it much easier to implement if corner cases don't require special treatment. In my opinion, explicit models are actually easier to understand despite the extra code involved, especially for researchers who are new to the field. But perhaps most important is that we are never quite sure where the field will go, and it may turn out that those 5% of cases become a key area of research in the future (which would actually be my guess).

Re inheritance, I could be wrong but I think that with the explicit handling of analog-ports/events in NineML I don't envisage needing to explicitly distinguish between channels/cells/synapses.

I appreciate that you have come up with strong solutions to many problems in your LEMS/NeuroML2 NEURON implementation. However, considering that the current uptake of declarative model languages in the community is still unfortunately quite low, I don't see the harm in exploring different solutions while working on implementations for different target simulators, since they raise different issues to the ones you have faced in targeting NEURON. In any case, it could well be that LEMS/NineML end up converging at some point in the future, but if not, or in the mean time, I don't think it will be difficult to write conversion scripts from LEMS/NeuroML2 to NineML and NineML channel/synapse representations to LEMS so I don't see it being a major problem.

All that said, we will definitely keep an eye on the way things are done in LEMS/NeuroML2 and try follow your lead on any arbitrary design decisions that we run into. Thanks for providing your input, it is much appreciated.

Cheers,

Tom

@tclose tclose mentioned this issue Sep 30, 2014
Open
@robertcannon
Copy link

Hi Tom,
I would suggest things aren't actually implicit in LEMS, rather that there is another layer of structure based around the physical geometry of a model that resolves things. Eg if a channel is in the membrane of a cell than it can only experience the potentials on either side. We therefore deliberately exclude any possibility of making a connection between that channel and any other component of the model that is not physically adjacent to it. This does, however, make it impossible to specify a whole range of logical rather than physical models. I guess that is your point about philosophical differences?

So, rather than calling them corner cases, I'd say these things which need arbitrary continuous (as opposed to event) connections are a whole different category of models. We're not targetting them in NeuroML but I can see why you might want to in NineML.

Cheers,
Robert

@tclose
Copy link
Contributor Author

tclose commented Oct 8, 2014

Hi Robert,

By implicit handling in LEMS, I was meaning implicit to the model/component-type descriptions (i.e. the XML code). I could be wrong but isn't that the other layer of resolving structure in LEMS part of the language definition/simulator implementation? If so, then that resolving structure carries with it a number of assumptions, which are then set in stone in the language.

In my proposal here (and what I believe to be the original vision for NineML) the resolving structure would be explicitly defined in the XML component-class description. This perhaps places an additional burden on the component-class developer, although given a catalog of existing models/sub-component (and hopefully a GUI at some point in the future) I expect it will be a minor burden at most, but at the same time give them more power to explore classes of models (in a non-hackish way) that don't conform to typical assumptions made of that resolving structure. This would include the class of neuron models you mentioned but could potentially also include more or less accurate approximations of the physical structure/molecular-interactions depending on the requirements of a particular modelling application.

Whether you call these different classes of models or corner cases I don't know. In calling them corner cases, I was mainly referring to Padraig's comment about the philosophical decision taken in the development of NeuroML2/LEMS to target a straightforward way to implement 95% of cases instead of going down the route of a more general approach. The relative utility of this proposal compared the approach you guys have taken will only become apparent with use over time I suppose though.

Cheers,

Tom

@robertcannon
Copy link

Hi Tom,
Yes, the Requirement/Exposure mechanism is part of the language: if a
component has a requirement for a particular variable, then
it can only be used in a nested context where one of the enclosing
components "exposes" that variable. We don't explicitly say which of the
enclosing components that is so there is a resolving step required. If the
requirement can't be met then the model is invalid. But there is no
requirement on the modeler to declare any Requirement and Exposure
elements. If they don't, then there won't be any continuous connections
between components.
At present there is a "sloppy" resolving mode in jLEMS where it will accept
a model without explicit Exposure elements as long as it can find the
variable in the enclosing element but I think we should get rid of this.

Although you don't have to use Requirements and Exposures, there is
currently no other mechanism for setting up continuous connections :) It
will be interesting to see what models you come across that need something
more. I'm not intrinsically averse to generic analog ports, but my goal
with LEMS is to stick with the physical constraints ("in", "on", "adjacent"
etc) for component relationships so each time we find a need for more
connections the solution is to enrich the geometrical model. This way the
model
is forced to contain more semantic information about the structure being
described. Eg there is a new "Tunnel" element to support gap junctions. At
present it just exposes the potentials of two cells to each other, but it
has to be there in the model, which means
you could also use it, say, to verify that gap junctions in a 3D model only
occur between adjacent processes.

We could avoid the need to extend the geometry like this by implementing
generic ports but then it wouldn't be LEMS. However, I think it is
certainly useful to have a declarative language that does to that.

Cheers,
Robert

Robert Cannon
Annotate.co, Textensor Limited, Edinburgh, EH2 2JR, UK
Tel: +44 131 629 1424

On 8 October 2014 04:15, Tom Close notifications@github.com wrote:

Hi Robert,

By implicit handling in LEMS, I was meaning implicit to the
model/component-type descriptions (i.e. the XML code). I could be wrong but
isn't that the other layer of resolving structure in LEMS part of the
language definition/simulator implementation? If so, then that resolving
structure carries with it a number of assumptions, which are then set in
stone in the language.

In my proposal here (and what I believe to be the original vision for
NineML) the resolving structure would be explicitly defined in the XML
component-class description. This perhaps places an additional burden on
the component-class developer, although given a catalog of existing
models/sub-component (and hopefully a GUI at some point in the future) I
expect it will be a minor burden at least, but at the same time give them
more power to explore classes of models (in a non-hackish way) that don't
conform to typical assumptions made of that resolving structure. This would
include the class of neuron models you mentioned but could potentially also
include more or less accurate approximations of the physical
structure/molecular-interactions depending on the requirements of a
particular modelling application.

Whether you call these different classes of models or corner cases I don't
know. In calling them corner cases, I was mainly referring to Padraig's
comment about the philosophical decision taken in the development of
NeuroML2/LEMS to target a straightforward way to implement 95% of cases
instead of going down the route of a more general approach. The relative
utility of this proposal compared the approach you guys have taken will
only become apparent with use over time I suppose though.

Cheers,

Tom

—
Reply to this email directly or view it on GitHub
#4 (comment).

@tclose tclose modified the milestone: Version 2.0 Oct 15, 2014
@tclose
Copy link
Contributor Author

tclose commented Oct 15, 2014

NineML standards committee meeting:

Subcomponent containers, "ComponentClassGroup"s, should be part of the user layer. To expose ports external the component container the syntax will be as follows

  <ComponentGroupClass name="HodgkinHuxleyContainer">
    <PortExposure name="membraneVoltage" component="membrane" port="V"/>
    <PortExposure name="membraneCurrent" component="membrane" port="i">
      <Annotation><Text>This can be used to connect synaptic input</Text></Annotation>
    </PortExposure>
    <SubComponentClass target="Na">
      <Definition>PyramidalNa</Definition>
      <PortConnection receiver="V">
        <Sender component="membrane" name="V"/>
      </PortConnection>
    </SubComponentClass>
    <SubComponentClass target="K">
      <Definition>PyramidalK</Definition>
      <PortConnection receiver="V">
        <Sender component="membrane" name="V"/>
      </PortConnection>
    </SubComponentClass>
    <SubComponentClass target="leak">
      <Definition>Leak</Definition>
      <PortConnection receiver="V">
        <Sender component="membrane" name="V"/>
      </PortConnection>
    </SubComponentClass>
    <SubComponentClass target="membrane">
      <Definition url="nineml.org/9ML/0.3/catalog/default_membrane.xml"/>
      <PortConnection receiver="i">
        <Sender component="na" name="i"/>
        <Sender component="k" name="i"/>
        <Sender component="leak" name="i"/>
      </PortConnection>
    </SubComponentClass>
  </ComponentGroupClass>

@tclose tclose self-assigned this Oct 15, 2014
@tclose
Copy link
Contributor Author

tclose commented Oct 15, 2014

NineML standards meeting:

The parameterisation of component groups would look like

<ComponentGroup name="PyramidalCell">
    <SubComponent target="PyramidalNa">
      <Property name="gbar">
        <quantity units="uS">0.0036</quantity>
      </Property>
    </SubComponent>
    <SubComponent target="PyramidalK">
      <Property name="gbar">
        <quantity units="uS">0.0025</quantity>
      </Property>
    </SubComponent>
    <SubComponent target="leak">
      <PortConnection receiver="V">
        <Sender component="membrane" name="V"/>
      </PortConnection>
    </SubComponent>
    <SubComponent target="membrane">
      <Property name="g">0.001</Property>
      <Property name="e_rev">
        <quantity units="mV">-21</quantity>
      </Property>
    </SubComponent>
</ComponentGroup>

@tclose
Copy link
Contributor Author

tclose commented Jan 17, 2015

Syntax proposed in dev2.0 branch spec:

<?xml version="1.0" encoding="UTF-8"?>
<NineML xmlns="http://nineml.net/9ML/2.0">
  <MultiComponent name="HodgkinHuxleyContainer">
    <SubComponent name="Na">
      <Component>
        <Definition>PyramidalNa</Definition>
        <Property name="gbar" units="uS">
          <SingleValue>0.0025</SingleValue>
        </Property>
      </Component>
      <PortConnection port="V">
        <FromSister component="membrane" port="V"/>
      </PortConnection>
    </SubComponent>
    <SubComponent name="K">
      <Component>
        <Prototype>PyramidalK</Prototype>
        <Property name="gbar" units="uS">
          <SingleValue>0.0036</SingleValue>
        </Property>
      </Component>
      <PortConnection port="V">
        <FromSister component="membrane" port="V"/>
      </PortConnection>
    </SubComponent>
    <SubComponent name="leak">
      <Component>
        <Definition>Leak</Definition>
        <Property name="g" units="uS">
          <SingleValue>0.001</SingleValue>
        </Property>
        <Property name="e_rev" units="mV">
          <SingleValue>-21</SingleValue>
        </Property>
      </Component>
      <PortConnection port="V">
        <FromSister component="membrane" port="V"/>
      </PortConnection>
    </SubComponent>
    <SubComponent name="membrane">
      <Component>
        <Definition url="http://nineml.net/9ML/2.0/catalog/basicMembrane.9ml"
          >BasicMembrane</Definition>
        <Property name="length" units="um">
          <SingleValue>15.0</SingleValue>
        </Property>
        <Property name="axialResistance" units="ohm_per_cm">
          <SingleValue>100.0</SingleValue>
        </Property>
        <Property name="diameter" units="um">
          <SingleValue>15.0</SingleValue>
        </Property>
        <Property name="C" units="uF">
          <SingleValue>1.0</SingleValue>
        </Property>
      </Component>
      <PortConnection port="i">
        <FromSister component="Na" name="i"/>
        <FromSister component="K" name="i"/>
        <FromSister component="leak" name="i"/>
      </PortConnection>
    </SubComponent>
    <PortExposure name="membraneVoltage" component="membrane" port="V"/>
    <PortExposure name="membraneCurrent" component="membrane" port="i">
      <Annotations>
        <Comment>This can be used to connect current synaptic input</Comment>
      </Annotations>
    </PortExposure>
  </MultiComponent>
  <Dimension name="time" t="1"/>
  <Dimension name="voltage" m="1" l="2" t="-3" i="-1"/>
  <Dimension name="conductance" m="-1" t="3" l="-2" i="2"/>
  <Dimension name="area" l="2"/>
  <Dimension name="length" l="1"/>
  <Unit symbol="mV" dimension="voltage" power="-3"/>
  <Unit symbol="um" dimension="length" power="-3"/>
  <Unit symbol="ms" dimension="time" power="-3"/>
  <Unit symbol="cm_square" dimension="area" power="-4"/>
  <Unit symbol="mS" dimension="conductance" power="-3"/>  
</NineML>

tclose added a commit that referenced this issue Feb 5, 2015
@tclose
Merge pull request #4 from zuckermont/kinetics
5da9db8 
Kinetics
@tclose tclose mentioned this issue Feb 24, 2015
Open
@tclose tclose changed the title Add sub-components to dynamics classes Multi-component dynamic models Apr 1, 2015
@tclose
Copy link
Contributor Author

tclose commented Apr 1, 2015

Issue #46 could form the basis for this extension

@tclose
Copy link
Contributor Author

tclose commented Apr 2, 2015

PortConnection -> <SiblingPortConnection sender="remotePortName" receiver="localPortName" sibling="componentName"/>

@tclose tclose added the accepted label Apr 2, 2015
tclose added a commit that referenced this issue Apr 6, 2015
@tclose
Merge pull request #4 from zuckermont/kinetics
ef8bb25 
Kinetics
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@tclose tclose

Labels
accepted dynamics enhancement in develop branch Priority standard extension
Projects
None yet
Milestone
Version 2.0
Development

No branches or pull requests
6 participants
@apdavison @tclose @pgleeson @robertcannon @iraikov @NineML-Committee