Replace syn_type_id with connection_model for synapses.
#23
Conversation
Follow the convention for node files. This field should never be empty, but at the very least contain two values corresponding to mod files that have been previously used via `syn_type_id`. Follow up to #5. Recipe part to be defined in this PR still.
matz-e
changed the title
syn_type_id with model_template for synapses.syn_type_id with connection_model for synapses.
There was a problem hiding this comment.
I think leaving the mandatory start of the synapse type with E or I should be OK, this will simplify the handling on the recipe code side. It can be completely removed later.
I did not add any parameter changes to the specification here, because I don't know which fields will be required for all possible models.
jdcourcol
left a comment
jdcourcol
left a comment
There was a problem hiding this comment.
I am good with that. I think we can increase the sonata version number because of this change.
| where :math:`ca` denotes the simulated calcium concentration in | ||
| millimolar and :math:`y` a scalar such that at | ||
| :math:`ca = 2.0:\ u_\text{final} = u`. (Markram et al., 2015) | ||
| - `connection_model`, to specify the filename stub (without a final extension) that should |
There was a problem hiding this comment.
It's a matter of personal taste, but I would more easily relate the concepts if this was named synapse_model. Please disregard if we will model connections which are not synapses
There was a problem hiding this comment.
I would prefer that we stay with the generic 'model_template' like they have specified for edges in the SONATA paper with Allen: https://github.com/AllenInstitute/sonata/blob/master/docs/SONATA_DEVELOPER_GUIDE.md#representing-edges
In NEURON and other simulators, the generic word 'model' is used for various objects: ion channels, firing behavior, synapse, gap junction, etc
There was a problem hiding this comment.
Whatever is decided, it should match what is chosen for the column in #5. I'd prefer that we don't duplicate names in nodes and edges, simply because it makes it easier to grep for one or the other and it reduces potential confusion, but it's not a deal breaker for me.
There was a problem hiding this comment.
connection_model makes me think about the anatomical connection. synapse_model seems more appropriate to me.
There was a problem hiding this comment.
synapse_model does not work for the reason mentioned by @jamesgking - it is not only about synapses.
This field should never be empty, but at the very least contain two values corresponding to mod files that have been previously used via
syn_type_id.Follow up to #5.