Neuron type not recognized in physiology config

[sivanni]

Hi guys. Yesterday I talked with Vafa and learned that currently in the master branch the neuron subtypes are catched in the physiology config file. It used to be types. This is now a problem for the CxConstructor which produces a lot of subtypes.

There is a need for a minor change in cxsystem2 master branch where the neuron type name catches the query if subtype is not defined in the physiology config file. E.g. if subtype L23_SS is not found, it would check for type SS.

This is rather urgent

[henhok]

@sivanni It will use the main neuron type if there is no subtype defined, so just leave the subtype column empty. The sole reason for this column is to act as a reference to physio config. I think it’s best not to let CxSystem automatically go for the main type parameters, because it can be a source of confusion, eg. when parameters are not found due to a typo. Still, I think the constructor should create the subtype names because we might need them later... easier to just delete that column at this point.

[henhok]

What do you think?

[sivanni]

@henhok I see. One problem. The layer index for cxconstructor is not going to match the histological layers because the model and n layers are changing by default. We need to see the layer name for reference, especially because the csv/xlsx file is the major document of the model structure. Can we then have another column, such as 'model_layer' which carries this name. At the moment it is in the subtype prefix. See the example table below, coming from cxconstructor.

[sivanni]

[henhok]

@sivanni Adding a column is easy & I can do it if you think it is necessary. If it is only used for annotation I would not however recommend it, because every older model config file will have to be modified. The BUI schema also. For mere annotation, I use the hashtag syntax at the end of the line.

[henhok]

To be a stickler (again), I would also not recommend changing the neuron_type names because this will also require changes to all config files and BUI schema. Is there a functional reason why there needs to be a VIP type? I personally use SS for excitatory point neurons, BC for inhibitory point neurons and PCs for cells with dendritic compartments. The only place where BC/MC distinction is currently used is in scaling wrt calcium level, but in retrospect, the calcium scaling constant should've also been placed in physiology config (now it's hidden in code).

My motivation for pointing this out is that the anatomy config system is quite inflexible, while the physio config system nicely tolerates new parameters without changes to previous model config files and the BUI schema. That's why I think anatomy config should be really bare bones (with annotation, sure) and physio include all the details. For example: When we will have the need for new synaptic parameters, there should be a reference column in anatomy config, which would point to the correct set of parameters in physio_config. Otherwise we will end up adding columns to anatomy config and all the time getting stuck making our old model config files up-to-date.

[sivanni]

Oh dear. So that when we start using more complex models all neurons will be of two types from year 2018? It is unfortunately not an option. The system needs to be flexible. In contrast, the 2018 models can use particular version of software, but the software needs to move on. BUI can use the same fixed version, but there needs to be development in the master branch or dev branch. The whole idea is flexibility, that should be our strength. The BUI's role will probably be educational. Already Margaux went successfully to csv:s in pycharm table format. If necessary, BUI can be updated at a later phase.

I did try to think what you suggest Henri, but then the structure of the model becomes obscure because I cannot see the cell types or layer names correctly in the anatomy file (see above table).

[sivanni]

[sivanni]

This is what Margaux is building and that can work with 2-3 types. However, without correct names of layers, or no flexibility in defining more cell group names, everything becomes difficult to understand.

[sivanni]

[sivanni]

These type of group names will come from Allen institute -- this is for rodent, but the human data is similar.

[sivanni]

@henhok In the step1 you seem to have all necessary info in the subtype name. Is the main type just hanging there?

[sivanni]

I guess the original idea was that main type physiology is reusable, like object programming. Then subtypes are nice addition for more details

[henhok]

Ok, I will make the neuron_subtype parameter such that it will fall back to main type parameters if it can’t find the subtype params.

[sivanni]

Thanks @henhok , and thanks for teaching me a new way to work with the config files! Given that the main param is so difficult to change, I could do a new class to CxConstructor and a new table holding the neuron_type -level parameters, and then make a subtype constructor class spawning subtypes to physiology file. It's name could hold the necessary info about the cell type and the histological layer.

[sivanni]

Diamonds are made in great pressure :)

[henhok]

Regarding neuron types, what I meant is that internally all the point neurons (BC, MC, SS, L1i) are handled in exactly the same way, so they really serve no other function than annotation. There's some redundant code in CxSystem because of this. E/I distinction is made at the level of the synapse definitions, not at neuron level (e.g. SS neuron can have both E and I synapses). All the BC/MC/L1i/SS could be called PointNeuron and that wouldn't internally change anything (except scaling wrt calcium currently).

So I didn't mean that we should cut down to only E/I types. I meant that the BC/MC/L1i/SS distinction in anatomy config is an illusion -- changing a BC group to SS group doesn't change anything internally. They only become different through parameter definitions in the physio config.

Anyway, I understand that the CSVs also act as documentation. But some ways of documenting can lead to redundant code and unnecessary confusion, which we've always been trying to avoid.

And regarding the subtype column: Before adding the neuron_subtype, all layer-specific/subtype-specific definitions were written in the anatomy config. For NeCo paper revisions, all the neuron groups had specific parameters and so all these parameters would've had to be in the anatomy config. Thus it was clear that there needed to be a reference pointing to physio config. For synapses, we have so far managed with static parameters (eg. all depressing synapses have the same set of params), but actually the Markram model has specific params for certain synapses... So, the synapses face a similar rehaul if we ever need to be more specific with params (other than weight), eg. L5 MC <-> L5 PC parameters need to be something that's different from the rest.

[sivanni]

Thanks Henri! I recognized this somewhat silly hard coded neuron type problem. I think we have a similar issue at 3 levels: neuron type, synapse type and equations. In addition, we might at some point want to have compartmental inhibitory neurons, and the PC neurons may point downwards. Would it be better to have subtype definitions so that the model structure permutations would make most sense. E.g. neuron type: PointNeuron, CompartmentalNeuron (with vertical (layer idx parametrization) and horizontal (micrometer) compartments); neuron subtype: other neuron level parameters, INCLUDING annotation at anatomy CSV in the subtype name. I think the equations go to the neuron type level, too. What do you think? Similar division could go to synapse type, synapse subtype. This approach would actually support a higher level abstraction of neuron/synapse construction, ie the CxConstructor.

Dont think of resources yet. Think whether it makes (good) sense.

[henhok]

Yeah, I think your suggestion makes a lot of sense. We need a place to store the parameters of many neuron groups/connections and a place to store the parameters of individual neuron groups/connections.

There are some asymmetries in our current implementation. We have the neuron groups table in anatomy config, which contains a reference to physio config, which contains a reference to a neuron model. Then again we have the connections table in anatomy config, which contains a reference to a synapse model, whose parameters are in the root of physio config. It's not always easy to decide where a certain parameter should go. It might also change between models where the best location is. Optimally, the user should be able to decide whether it's a group-level parameter or something that needs to be specified at the level of individual neuron group/connection.

I think it would be wise at some point to have a proper look at SONATA, which is a "data format for efficient description of large-scale network models". BBP and ABI are behind this, and they have a Python interface for the format. They didn't have us or Brian in mind when building this, but at least a loose alignment with SONATA could be useful. It would help us disseminate our work without having to explain CxSystemology too much. SONATA might be a bit too heavy for our current purposes, but they have faced similar design issues, so there should be a lot to learn from them. Their recent paper: https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1007696