-
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?
Changes from 3 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -267,7 +267,8 @@ To assign synapse properties, the classification field needs to be set: | |
.. note:: | ||
|
||
The type has to start with either ``E`` for excitatory connections or | ||
``I`` for inhibitory connections. | ||
``I`` for inhibitory connections. This legacy behavior may be overriden by | ||
specifying the `connection_model` parameter for the `SynapsesClassification` section. | ||
|
||
Two optional attributes may be set: | ||
|
||
|
@@ -318,7 +319,7 @@ property name: | |
Truncated Normal distributions are limited to the central value ±σ and are | ||
re-rolled until positive values has been obtained. | ||
|
||
Two optional attributes can be specified, where each attribute will have to | ||
Three optional attributes can be specified, where each attribute will have to | ||
be given for all `SynapsesClassification` elements: | ||
|
||
- `gsynSRSF`, the scale factor for the conductance; `SRSF`: 'synaptic receptor scaling factor' | ||
|
@@ -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 commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
||
appear in the field with the same name in the corresponding SONATA edge file. Presence | ||
of this attribute will suppress creating the `syn_type_id` field in the edge file. | ||
|
||
These attributes will be copied for each synapse corresponding to its | ||
classification. If they are not specified, no corresponding columns will | ||
|
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
orI
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.