Importing morphologies into Brian from a NeuroML file

[kapilkd13]

This summer I would be working on "Importing morphologies into Brian from a NeuroML file" as part of the Gsoc 2018. I would be using this thread for keeping track of the milestones and the upcoming work. Also I would like to use this thread to discuss issues/ suggestions or to gain any other information.

Milestones to be achieved:

• [x] Setup Brian and supporting libraries like JneuroML, Pylems and libNeuroML
• [x] Setup Neuron( not urgent)
• [x] Study, compare and choose best parsing lib option. libNeuroML is choosen
• [x] getting familiar with lems/neuroml specification. under progress
• [x] convert neuroml morphology to python objects using parsing library for further usage.
• [ ] create "nmlimport" module inside brain2tools to load morphologies directly into Brian.
• [ ] create test cases for above implementation.
• [ ] Test, refactor and merge it.

After this I will start working on "accessing other information like ion channel from nml file" After this we will compare result from Brian, Neuron and other simulators. nml file exported from NEURON will be imported and tested in Brian. detailed milestones will be added later. @mstimberg

[kapilkd13]

Hi @mstimberg I was working on https://github.com/OpenSourceBrain/ACnet2/blob/master/neuroConstruct/generatedNeuroML2/pyr_4_sym.cell.nml trying to import morphologies through script. In this nml file there are multiple <segmentGroup> and each one can generate different Brian's morphology objects. So when we call a function like load_morphology('nml_file') should it return a dictionary of all the morphology objects with their id/name acting as key.

[mstimberg]

Hi. The morphology of the cell is given in the <segment> tags of the morphology -- the <segmentGroup> tags are not independent morphologies but are only names given to different subsets of the morphology. These are often representable as independent morphologies (each subtree of a morphology is a valid morphology) but this not necessarily the case. For example, you could define a <segmentGroup> as the most distal parts of several dendrites and this would not correspond to a morphology (the individual segments would not be connected to each other). This is a feature that does not have a direct equivalent in Brian 2, but it could actually be useful -- for now, referring to subsets of a morphology that are not simple subtrees is a bit ugly. This would be a good "nice to have" additional feature (directly in brian2) if you have time at the end of the project.

But long story short: the load_morphology should return a single Morphology object in general, the full morphology stored in the <segment> tags of the <cell>...<morphology>...</morphology></cell>. But files could actually have more than one <cell>, so your question is still relevant. I see several options:

1. Always return a dictionary (id of the <cell> as key)
2. Return a morphology if the file contains a single cell and a dictionary otherwise
3. Accept an optional argument to load_morphology, specifying the name/id of the cell the user is interested in (only required if there's more than one).

I think I'd prefer option 3 given that most files will only have a single cell (so 1 would be a bit annoying) and changing return types of a function (as for option 2) is not great. If you have another idea, I'm all ears.

[kapilkd13]

Hi @mstimberg There is a predefined logging model present in Brian2 which is also used in nmlexport package of brian2tools library. Should we use it for logging in our module too. I can see a Diagnostic level and other helper functions there. Will the logs be present alongside Brian's logs in same file?

[mstimberg]

Hi @kapilkd13 , yes please use Brian's logging module. Logs will end up in Brian's main log file and/or on screen depending on your configuration. We have some docs about it from the user's and the developer's point of view.

[kapilkd13]

Hi @mstimberg I have made a PR with current progress. Currently I am working on test suite. I am thinking of using a generic .nml file to create a python morphology object using libneuroml and perform unit test on our functions using this object. What do you think?

[mstimberg]

I am thinking of using a generic .nml file to create a python morphology object using libneuroml and perform unit test on our functions using this object. What do you think?

Sounds good! For the main loading function, we might also accept a file object instead of a filename as the argument, this is quite a standard thing to do (see e.g. numpy.loadtxt). With this, you would not have to give an actual filename, but could provide a string via StringIO. This would be cleaner for testing several different files as part of the test suite. Not super-important, though, tests using a file are fine as well.