neuroml-channels Mailing List for NeuroML

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
 <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi, 
 
I assume you mean a case where the thickness of the shell varies on
different parts of the cell? If it's uniform over all the cell, no
extra info is needed in the mechanism element and the thickness should
be set in the ion_concentration element. If it varies the following can
be used: 
 
&lt;bio:mechanism name="CaPool" type="Ion Concentration"&gt; 
&nbsp;&nbsp;&nbsp; &lt;bio:parameter name="thickness" value="0.02"&gt; 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;bio:group&gt;soma&lt;/bio:group&gt; 
&nbsp;&nbsp;&nbsp; &lt;/bio:parameter&gt; 
&lt;/bio:mechanism&gt; 
 
&lt;bio:mechanism name="CaPool" type="Ion Concentration"&gt; 
&nbsp;&nbsp;&nbsp; &lt;bio:parameter name="thickness" value="0.01"&gt; 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;bio:group&gt;dendrite_group&lt;/bio:group&gt; 
&nbsp;&nbsp;&nbsp; &lt;/bio:parameter&gt; 
&lt;/bio:mechanism&gt; 
 
How does this sound? 
 
The second scenario you describe below (an ion conc mechanism on a
group other than all, with no parameters different than the
ion_concentration element) is more problematic, as the current
mechanism/parameter/group structure assumes a parameter element is
present. The new representation for these in NeuroML version 2 will
have to account for your scenario. For convenience the easiest way to
do this now might be to use: 
 
&lt;bio:mechanism name="CaPool" type="Ion Concentration"&gt; 
&nbsp;&nbsp;&nbsp; &lt;bio:parameter name="thickness" value="0.02"&gt; 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;bio:group&gt;soma&lt;/bio:group&gt; 
&nbsp;&nbsp;&nbsp; &lt;/bio:parameter&gt; 
&lt;/bio:mechanism&gt; 
 
i.e. simply repeat one of the parameters from the ChannelML mechanism. 
 
Re the example using fixed_pool_info, see the attached. Note that this
example is for the Traub et al [Ca2+] pool mechanism here: 
 
<a class="moz-txt-link-freetext" href="http://senselab.med.yale.edu/modeldb/ShowModel.asp?model=82894&file=\nrntraub\mod\cad.mod">http://senselab.med.yale.edu/modeldb/ShowModel.asp?model=82894&amp;file=\nrntraub\mod\cad.mod</a> 
 
and the "fixed pool info" parameter phi is a scaling factor on the Ca
current per unit surface area, rather than a scaling on the total Ca
current. This is not an ideal way to specify this parameter (as this
scaling should be independent of compartment/section size) and so while
this element does allow somewhat unsound modelling practice, it makes
it easier to determine if best practices are being used in models. 
 
Regards, 
Padraig 
 
 
 
 
Siji P George wrote:
<blockquote
 cite="mid:524...@ma..."
 type="cite">
 <pre wrap="">Hi,

can you also suggest a way to describe, scaling with respect to shell
thickness.

when you say that the parameter is not specified, do you mean that, will
the xml look like the following:

&lt;bio:mechanism name="CaPool" type="Ion Concentration"&gt;
       &lt;bio:group&gt;soma&lt;/bio:group&gt;
&lt;/bio:mechanism&gt;

can you point to an example where 'fixed_pool_info' is used?

  </pre>
  <blockquote type="cite">
    <pre wrap="">Hi,

I'd suggest in this case to use parameters named according to what they
represent, rather than basing the naming on usage in GENESIS, so:

&lt;bio:mechanism name="CaPool" type="Ion Concentration"&gt;
    &lt;bio:parameter name="specific_current_scaling_factor"
value="17.402e12"&gt;
        &lt;bio:group&gt;soma&lt;/bio:group&gt;
    &lt;/bio:parameter&gt;
&lt;/bio:mechanism&gt;

&lt;bio:mechanism name="CaPool" type="Ion Concentration"&gt;
    &lt;bio:parameter name="fixed_current_scaling_factor" value="8.96e-3"&gt;
        &lt;bio:group&gt;lat&lt;/bio:group&gt;
    &lt;/bio:parameter&gt;
&lt;/bio:mechanism&gt;

Where the first case assumes the form of the equation for conc is:

d[Ca]/dt = volume * specific_current_scaling_factor * Ik -  ([Ca] -
resting_conc)/decay_constant

and the second case represents:

d[Ca]/dt = fixed_current_scaling_factor * Ik -  ([Ca] -
resting_conc)/decay_constant

with Ik being the total Ca current into the compartment, and
resting_conc &amp; decay_constant set in the ChannelML for the CaPool.

Again, if neither of these parameters are specified in the
&lt;bio:mechanism&gt; element, the simulator can assume all the correct
parameters for the current scaling are set in the ChannelML (i.e. in
pool_volume_info or fixed_pool_info)

How does that sound?
Padraig

Siji P George wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">Hi Padraig,

Thanks for the comments.

i need to clarify one thing.

In CaPool, scaling for one group is 'off' and  other is 'volume', then
how
to represent using 'pool_volume_info' or 'fixed_pool_info'?
for eg:

&lt;bio:mechanism name="CaPool" type="Ion Concentration"&gt;
	&lt;bio:parameter name="B" value="17.402e12" scaling="off"&gt;
	    &lt;bio:group&gt;soma&lt;/bio:group&gt;
	&lt;/bio:parameter&gt;
&lt;/bio:mechanism&gt;

&lt;bio:mechanism name="CaPool" type="Ion Concentration"&gt;
	&lt;bio:parameter name="B" value="8.96e-3" scaling="volume"&gt;
	    &lt;bio:group&gt;lat&lt;/bio:group&gt;
	&lt;/bio:parameter&gt;
&lt;/bio:mechanism&gt;

      </pre>
      <blockquote type="cite">
        <pre wrap="">Hi Siji,

Thanks for these points. They're all issues that have come up before as
possible shortcomings of NeuroML version 1.x, and need to be dealt with
properly in v2.0. The main question will be how much effort to put into
them getting v1 to support these features, and whether it would be
better to wait to v2.0.

See below for specific comments...

Siji P George wrote:

        </pre>
        <blockquote type="cite">
          <pre wrap="">Dear all,

We have been implementing NeuroML reading functionality inside MOOSE
using
a little libNeuroML implementation that we are coding alongside. We
are
using NeuroML models available on the NeuroML website, and also files
generated by neuroConstruct. Finally we have been also trying to
encode
(by hand) a slightly modified version of Traub's early CA1 model, and
reading it in.

We ran into some difficulties with the grammar of these NeuroML files.
For
now, we have made some changes in the grammar of these files so that
we
could continue with the implementation/testing. These changes were
usually
such that our needs were met, and we did not try very much to come up
with
the most general/clean solution. Perhaps these problems have already
been
addressed in the latest version of NeuroML 2, but in absence of
concrete
examples from this specification, we have been trying to implement the
old
version. Below we list these difficulties, and our attempts at fixing
them:

1. Calcium Pool in MorphML file: The existing MorphML files treated
Calcium pools just like ion channels, and just by looking at a MorphML
file, it was impossible to ascertain whether a given mechanism is a
channel or a Ca-pool.

          </pre>
        </blockquote>
        <pre wrap="">True. This is probably due to the Ca pool being added in NEURON (insert
statement)/GENESIS (read cellfiles) in a similar way to how channels
are
added.

        </pre>
        <blockquote type="cite">
          <pre wrap="">The alternative was to load the corresponding
ChannelML file which was making the implementation unnecessarily
complicated. Further, in GENESIS style, these MorphML files specified
the
Ca-pools as having a "gmax" attribute, which stood in for the
Ca-pools'
"B" value.

Example of existing MorphML:

Changes we made:
	The attribute - type - is given as 'Ion Pool' instead of 'Channel
Mechanism'

          </pre>
        </blockquote>
        <pre wrap="">In the Schema file for ChannelML, "Ion Concentration" is a valid type
for mechanism.

        </pre>
        <blockquote type="cite">
          <pre wrap="">	The parameter name is B instead of gmax and another attribute
'scaling'
is allowed which can have any one of the following values.
		"off" : The B value will not be scaled.
		"shell" : B will be scaled by the volume of a shell with a given
thickness.
		"volume" : B will be scale by the volume of the corresponding
segment
(i.e., compartment).

	eg:
	&lt;bio:mechanism name="CaPool" type="Ion Pool"&gt;
		&lt;bio:parameter name="B" value="17.402e12" scaling="off"&gt;
			&lt;bio:group&gt;soma_group&lt;/bio:group&gt;
		&lt;/bio:parameter&gt;
	&lt;/bio:mechanism&gt;

          </pre>
        </blockquote>
        <pre wrap="">I agree that gmax is a bad name for this parameter. I think however
that
this "B" value should be calculated from the info in the CaPool
description itself, i.e. if a thickness is specified there it's a shell
or if the fixed_pool_info element is used it's a fixed value, etc. So
the preferred form you should output is:

            &lt;bio:mechanism name="CaPool" type="Ion Concentration"/&gt;

and an appropriate ChannelML file with &lt;ion_concentration&gt; should be
created with a pool_volume_info  or a fixed_pool_info element as
appropriate. If you have a cell where the B parameter of the Ca pool
varies over the cell, then maybe you should include the group specific
value above. The meaning of "B" then should be clear from the form of
the mechanism ChannelML file.

I'll update the exported NeuroML from neuroConstruct to export info on
calcium pools in this way.

An update for NeuroML version 2 will have to treat this in a better,
more generic way. One possible way is that interactions of subcellular
species in a region of the cell will be specified by an SBML file.
Extra
info in the cell description will have to say how the species might
diffuse along the cell but everywhere this SBML pathway is present, all
of its species are found.

        </pre>
        <blockquote type="cite">
          <pre wrap="">2. Rate constants for Hodgkin-Huxley channels have so far been
specified
either by mentioning the function type (one of "sigmoid",
"exponential"
and "exponential_linear"), or by specifying the math expression in a
string (e.g.: expr="ca_conc &lt; 0.00025 ? (ca_conc / 0.00025) : 1"). In
implementing the Traub's CA1 cell, we came across some rate-constant
curves which could not be specified using any of the 3 stereotyped
functions. While most of these curves could be approximated by fitting
one
of these 3 functions, one of the important cases (a roughly
bell-shaped
curved) could not be specified using this either. Writing a general
math
expression parser is not straightforward, and we will like to avoid
this
route at least for now.

We strongly think that one should be able to specify rates by giving
an
explicit table. This is not in keeping with the internal lookup-table
style representations of MOOSE and GENESIS, but rather simply because
this
method is enormously simple and completely general at the same time.
Perhaps even more importantly, original data from ion-channel
electrophysiology is usually in the form of tabulated rates, and it
seems
inappropriate to demand that mathematical abstractions, but not the
original data may be included.

Please refer to the attached file (K_AHPConductance.xml) to see how we
tried to include a table in a channel definition. We considered two
options for specifying a table:

    - A list of ( x, y ) pairs.
    - First specify a grid along X-axis with uniformly spaced points,
followed by a list of corresponding "y" values. This is done simply by
specifying the function's domain ("xmin" and "xmax"), while the number
of points in the grid is implicitly specified by the number of table
entries.

The first option seems cleaner and more general. For now, however, we
have
picked the second option simply because MOOSE uses a uniform grid
internally.

          </pre>
        </blockquote>
        <pre wrap="">I agree that this might be useful. I've added a v1.8.2 version of the
specifications in the NeuroML SVN repository which includes such as
example (voltage dependence only so far), along with an initial mapping
to a NEURON mod file. I'll try adding another mapping to a GENESIS.g
file too (or if anyone else is happy to edit the XSL file, be my
guest!). Your format seems fine for specifying these tables.

        </pre>
        <blockquote type="cite">
          <pre wrap="">3. In the existing MorphML, channels can be plugged into groups of
cables,
where each cable is a container for adjacent segments. This means that
all
the segments in a given cable must have the same channel composition.
In
the extreme case where every segment in a cell has a unique channel
composition, one must create one cable for every segment. A good
solution
is perhaps to leave out cables completely, and allow one to group
together
segments, where a segment may belong to more than one group. For now,
however, we have opted for the most straightforward method: allowing
channels to be plugged into individual segments directly.

	eg:
        &lt;bio:mechanism name="CaConductance" type="Channel Mechanism"&gt;
            &lt;bio:parameter name="gmax" value="50.0"&gt;
                &lt;bio:seg&gt;2&lt;/bio:seg&gt;
                &lt;bio:seg&gt;3&lt;/bio:seg&gt;
                &lt;bio:seg&gt;7&lt;/bio:seg&gt;
            &lt;/bio:parameter&gt;
        &lt;/bio:mechanism&gt;

          </pre>
        </blockquote>
        <pre wrap="">The full segment/cable/cable group structure will be overhauled in
version 2, and so unfortunately this issue will have to wait until then
(cables will be removed and there will only be segmentGroups). We can
add the ability to put channels directly onto segments then too.

For now it may be best just to automatically create a "cable" for each
compartment and groups for each cable and add the conductances like
that. If there are a number of individual compartments each with
different conductances, then it's likely it's a relatively small cell
and the overhead of creating groups, etc. shouldn't be too high

For larger cells it may be possible to create an algorithm to group
together comps with the same value of cond density and make unique
groups for those, this is what NEURON's Model View does. Unfortunately
GENESIS/MOOSE doesn't store any grouping information from the readcell
import (correct?) and so that can't be used.

        </pre>
        <blockquote type="cite">
          <pre wrap="">4. We were looking for ChannelML examples with Ca-dependent channels.
All
examples we found had exactly one gate, where the Ca-dependence was
encoded as an attribute for the entire channel, rather than for the
gate.
Since we were writing Ca-dependent channels with multiple gates, we
tried
to include an attribute in each of the gates specifying what it
depends
upon.

For now we have kept it crude but simple by adding an attribute called
"x_variable" to gates. The value of this variable may be simply either
"concentration" or "voltage". Of course, this needs to be improved by
specifying which Ca-pool entity needs to be referred, but we have kept
that implicit for now. The motivation behind the attribute name
"x_variable" is that some gates depend on both membrane potential as
well
as ion concentration, and this may perhaps be specified using
"x_variable"
and "y_variable" attributes.

	eg: Please find the attached K_CConductance.xml

          </pre>
        </blockquote>
        <pre wrap="">I have some other examples of voltage and concentration dependent
channels, unfortunately some are in pre NML v1.7.3 format. I'll try to
add these to the Example set for v1.8.2. I suspect the example you sent
would be supported if the rates were expressed in equations so
hopefully
the extension above for supporting tabulated channels can be used for
concentration dependence also. Can you send me on the original
GENESIS/MOOSE files for these channels?

Thanks,
Padraig

        </pre>
        <blockquote type="cite">
          <pre wrap="">thanks &amp; regards,
Siji
------------------------------------------------------------------------

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast
and
easy
Join now and get one step closer to millions of Verizon customers
<a class="moz-txt-link-freetext"
 href="http://p.sf.net/sfu/verizon-dev2dev">http://p.sf.net/sfu/verizon-dev2dev</a>
------------------------------------------------------------------------

_______________________________________________
Neuroml-channels mailing list
<a class="moz-txt-link-abbreviated"
 href="mailto:Neu...@li...">Neu...@li...</a>
<a class="moz-txt-link-freetext"
 href="https://lists.sourceforge.net/lists/listinfo/neuroml-channels">https://lists.sourceforge.net/lists/listinfo/neuroml-channels</a>

          </pre>
        </blockquote>
      </blockquote>
      <pre wrap="">thanks &amp; regards,
Siji

      </pre>
    </blockquote>
    <pre wrap="">    </pre>
  </blockquote>
  <pre wrap=""><!---->

thanks &amp; regards,
Siji

  </pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">-- 
-----------------------------------------------------
Padraig Gleeson
Room 321, Anatomy Building
Department of Neuroscience, Physiology &amp; Pharmacology
University College London
Gower Street
London WC1E 6BT
United Kingdom

+44 207 679 3214
<a class="moz-txt-link-abbreviated" href="mailto:p.g...@uc...">p.g...@uc...</a>
-----------------------------------------------------</pre>
</body>
</html>

2005	Jan	Feb	Mar	Apr (4)	May (2)	Jun	Jul (1)	Aug (6)	Sep	Oct	Nov	Dec
2006	Jan	Feb	Mar	Apr	May (1)	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec
2007	Jan (4)	Feb (2)	Mar (3)	Apr (6)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2009	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec
2010	Jan (7)	Feb (1)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

neuroml-channels Mailing List for NeuroML

neuroml-channels — This mailing list serves a working group on XML for channel specification.