NeuroLexId handling

[MRIO]

I searched and didn't find. Also, let me know if this is the correct repo to report this on. We would like to better understand the Neurolexid's of segment groups. Is there documentation about why they are necessary and how to use them? The context of the request is that we want our models to have 'proximal' and 'distal' dendrite regions (rather than basal and apical, as these aren't pyramidal cells). The .nml exports from neuroConstruct ommitted the 'sao864921383 'continuous cable secret directive, which seems to completely knock out all active channels.

[pgleeson]

Good point, it's a bit opaque... A key point is though that the NeuroLexId is metadata, and any NeuroML supporting application should be free to ignore them. Most of the usages apart from sao864921383 are indeed ignored by the current tool chain. However some segment_groups are more special than others and cells exported from neuroConstruct or Neuron, which gather segments into unbranched groups, and which are the basis for NEURON sections are flagged with sao864921383. See:

https://github.com/OpenSourceBrain/SmithEtAl2013-L23DendriticSpikes/blob/f9acc360a1ba53540370b34e7cef766736d228d9/NeuroML2/L23_NoHotSpot.cell.nml#L12062

This is mainly important so that when it gets exported back into NEURON those set of segments/points become one section there, and you can control independently the number of points actually simulated (nseg) with the numberInternalDivisions value (this will usually be smaller than the original number of points/nml segments).

If you do manually add sao864921383, make sure all segments are included in an unbranched group... Can you add an example that's not working?

[njhulst]

Thank you for explaining! So as it turns out, our problem did not really have to do with the neuroLexID, but wanting to split the dendrites within an unbranched segment, like you pointed out here: NeuralEnsemble/neuroConstruct#67 (for future readers). So, no need to look at a specific example anymore, thank you though!

[pgleeson]

Sure, that's better handled at NeuralEnsemble/neuroConstruct#67 as you say...