-
Notifications
You must be signed in to change notification settings - Fork 4
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
Replace syn_type_id
with connection_model
for synapses.
#23
base: master
Are you sure you want to change the base?
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.
syn_type_id
with model_template
for synapses.syn_type_id
with connection_model
for synapses.
source/recipe.rst
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am good with that. I think we can increase the sonata version number because of this change.
@@ -332,6 +333,9 @@ be given for all `SynapsesClassification` elements: | |||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
connection_model
makes me think about the anatomical connection. synapse_model
seems more appropriate to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.