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

Add a page on recording observable quantities from NeuroML/LEMS simulations #15

Closed
sanjayankur31 opened this issue Jan 19, 2021 · 7 comments · Fixed by #79
Closed

Add a page on recording observable quantities from NeuroML/LEMS simulations #15

sanjayankur31 opened this issue Jan 19, 2021 · 7 comments · Fixed by #79
Assignees
Labels
C: content Improvements or additions to documentation T: enhancement Type: enhancement

Comments

@sanjayankur31
Copy link
Member

It isn't obvious or intuitive how one should record information from simulations, such as spike times or membrane potentials (or other quantities). So a page that gives an overview of how to refer to different things would be useful.

The recording bit also should be explained in each example so people can use them as reference.

@sanjayankur31 sanjayankur31 added C: content Improvements or additions to documentation T: enhancement Type: enhancement labels Jan 19, 2021
@sanjayankur31 sanjayankur31 self-assigned this Jan 19, 2021
@sanjayankur31
Copy link
Member Author

  • in general, all exposures can be accessed and so recorded

@sanjayankur31
Copy link
Member Author

Information on how paths are to be constructed is also required. It isn't clear when an id should be used and when the name is sufficient, for example.

@sanjayankur31
Copy link
Member Author

I think:

  • all components should have IDs, and these should be used to construct paths.
  • bits that are not components (like Exposures) should not have IDs, and the name should be used to construct the path

@borismarin
Copy link
Contributor

Information on how paths are to be constructed is also required. It isn't clear when an id should be used and when the name is sufficient, for example.

See also LEMS/LEMS#9

@sanjayankur31
Copy link
Member Author

We discussed this yesterday. The rule of thumb seems to be:

  • for any child elements, use the name
  • for children elements use the id

Related: NeuroML/NeuroML2#163 and NeuroML/NeuroML2#157 etc.

@jonrkarr
Copy link

I see XML id attributes, XML name attributes, and XML tag names are being used. Beyond that, the addressing scheme is unclear to me.

Consider hhpop[0]/bioPhys1/membraneProperties/NaConductances/NaConductance/m/q from LEMS_NML2_Ex5_DetCell.xml

  • [0] appears to be an index, rather than an id or name
  • hhop does not appear to be in the root namespaces of the LEMS file. Rather, hhpop is the id of the population of the target of the simulation in the LEMS file.
  • [0] appears to be an index within the size of the hhop population
  • bioPhys1 is the id of a child of hhpop
  • membraneProperties is the XML tag name of a child of bioPhys. This element doesn't have a XML id attribute. LEMS appears to make the id of this component also membraneProperties
  • NaConductances is an id of a child of membraneProperties
  • m is the id of a child of the ionChannel parameter of NaConductances
  • q is the name of a StateVariable child of the Dynamics child of the type parameter of m

Consider hhpop[0]/spiking from LEMS_NML2_Ex5_DetCell.xml

  • LEMS doesn't parse spiking as a child or parameter of hhpop

I have several questions:

  • What part of the addressing scheme is LEMS vs NeuroML?
  • What is scope of ids? For example, gateHHrates is not directly imported into NaConductance.channel.nml
  • How is the indexing intended to work?
  • What are all the ways that the tree of components and their inheritance are intended to be walked (e.g., component->child, component -> ionChannel, component -> StateVariable)?

@sanjayankur31
Copy link
Member Author

I see XML id attributes, XML name attributes, and XML tag names are being used. Beyond that, the addressing scheme is unclear to me.

Consider hhpop[0]/bioPhys1/membraneProperties/NaConductances/NaConductance/m/q from LEMS_NML2_Ex5_DetCell.xml

  • [0] appears to be an index, rather than an id or name

Yes, because it's a population, which can have different sizes but of the same component. So, in this case, one can use the [x] system to refer to the element in the population that we want to access.

  • hhop does not appear to be in the root namespaces of the LEMS file. Rather, hhpop is the id of the population of the target of the simulation in the LEMS file.

Yes, because you can have multiple populations in the network. So, we use the id of the population here.

  • [0] appears to be an index within the size of the hhop population

Yes, please see my note above.

  • bioPhys1 is the id of a child of hhpop

No, bioPhys1 is the id of the biophysicalproperties child element that the cell (hhpop[0]) includes from NML2_SingleCompHHCell.xml. Here, since biopysicalproperties is a child, one can also use the name. However, because these can be defined "standalone" outside a cell, the id can also be used.

  • membraneProperties is the XML tag name of a child of bioPhys. This element doesn't have a XML id attribute. LEMS appears to make the id of this component also membraneProperties

It's a child element of biophysicalproperties, so there can be only one. Thus, it can be referred using its name directly and does not need to have an id.

  • NaConductances is an id of a child of membraneProperties
  • m is the id of a child of the ionChannel parameter of NaConductances
  • q is the name of a StateVariable child of the Dynamics child of the type parameter of m

Consider hhpop[0]/spiking from LEMS_NML2_Ex5_DetCell.xml

  • LEMS doesn't parse spiking as a child or parameter of hhpop

It's an exposure in hhpop[0], which is the cell in the population hhpop.

I have several questions:

  • What part of the addressing scheme is LEMS vs NeuroML?

NeuroML uses LEMS---it just defines ComponentTypes that can be used directly. So, LEMS is sort of the programming language that defines basic types, and NeuroML uses these basic types to define classes---instances of which (objects) become components.

So, the addressing scheme comes from LEMS.

  • What is scope of ids? For example, gateHHrates is not directly imported into NaConductance.channel.nml

I'm not sure what you mean by "scope" here. It's a hierarchical path. gateHHrates extensions of gate, which are children elements of ionChannels:

https://docs.neuroml.org/Userdocs/Schemas/Channels.html?highlight=gatehhrates#ionchannelhh

  • How is the indexing intended to work?

My understanding is that elements that have "sizes" is where indexing can be used, since they'll have n elements of the same type, and the index can be used to refer to one of these n elements.

  • What are all the ways that the tree of components and their inheritance are intended to be walked (e.g., component->child, component -> ionChannel, component -> StateVariable)?

You go down the tree from the top most node, for example a population. Whenever you come across a component whose component type defines an exposure, you can access the value of the exposure.

We'll clarify this in the page with examples. I do realise that it's not as intuitive nor straight forward as it can be.

sanjayankur31 added a commit to NeuroML/pyNeuroML that referenced this issue Jul 21, 2021
Should help with NeuroML/Documentation#15

TODO: the LEMS functions that this wraps around seem to be incomplete. I
don't think the exposures listed there include ones inherited from their
superclasses/ancestors.
@sanjayankur31 sanjayankur31 linked a pull request Jul 28, 2021 that will close this issue
sanjayankur31 added a commit to NeuroML/pyNeuroML that referenced this issue Aug 4, 2021
Should help with NeuroML/Documentation#15

TODO: the LEMS functions that this wraps around seem to be incomplete. I
don't think the exposures listed there include ones inherited from their
superclasses/ancestors.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: content Improvements or additions to documentation T: enhancement Type: enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants