diff --git a/.gitignore b/.gitignore index 756f9b9..c8d35f0 100644 --- a/.gitignore +++ b/.gitignore @@ -2,6 +2,28 @@ **/*.egg-info/ **/*~ src/pysonata/sonata/tests/tmp +src/pysonata/build +src/pysonata/dist +src/pysonata/.pytest_cache +**/mechanisms/x86_64 +examples/**/output/log.txt +examples/**/output/config.json .idea .cache **/mechanisms/x86_64 +/examples/sim_tests/biophysical/one_cell/soma_cm2_hh/.pytest_cache +/examples/sim_tests/intfire/**/.pytest_cache +.ipynb_checkpoints/ +/examples/checkouth5.sh +/examples/300_pointneurons/output/*.dat +/examples/sim_tests/intfire/*/test/x86_64 +/examples/sim_tests/intfire/*/test/LEMS*.xml +/examples/sim_tests/intfire/*/test/*.dat +/examples/sim_tests/intfire/*/test/report*txt +/examples/sim_tests/intfire/*/test/*spikes +/examples/sim_tests/intfire/*/test/*.net.nml +/examples/sim_tests/intfire/*/test/*_nrn.py +/examples/sim_tests/intfire/*/test/*.mod +/examples/sim_tests/intfire/*/test/output/*h5 +/examples/sim_tests/intfire/*/test/output/log.txt +/examples/sim_tests/intfire/*/test/output/*dat diff --git a/docs/SONATA_DEVELOPER_GUIDE.md b/docs/SONATA_DEVELOPER_GUIDE.md index 8037e08..7ae428e 100644 --- a/docs/SONATA_DEVELOPER_GUIDE.md +++ b/docs/SONATA_DEVELOPER_GUIDE.md @@ -113,10 +113,7 @@ The format used is SWC ( [http://www.neuronland.org/NLMorphologyConverter/Morpho - -* Point soma, interpreted as a sphere with radius from column 6 (**Cylindrical somas are not used**) - - Point soma will be interpreted in NEURON as cylinder with L=radius +* Single sample point soma, interpreted as a sphere with radius from column 6 (**Cylindrical somas are not used**). * Types: The following types are currently used. @@ -153,11 +150,16 @@ The format used is SWC ( [http://www.neuronland.org/NLMorphologyConverter/Morpho It is not required that the soma is located at 0,0,0 in the SWC file, but in cases where the morphology has a soma, the soma will be re-centered to 0,0,0 upon loading into the circuit. Node translations will then be applied to this recentered morphology. This behavior can be overridden by the optional reserved attribute "recenter" for nodes and node_types. See "Representing networks of neurons" for more details. -It is recommended, but not required, that morphologies in a network have a standardized orientation, so that their orientation vectors in the network can be inferred from node rotation angles. For circuits for which this is true, the circuit producer can declare it with the "standardized_morphology_orientation" entry in the circuit_config.json, so downstream users can safely assume it. See "Tying it all together - the circuit_config file" for more details. +It is recommended, but not required, that morphologies in a network have a standardized orientation, so that their orientation vectors in the network can be inferred from node rotation angles. ### Representing ion channel, point neuron and synapse models -To represent point neuron models, synapses and ion channels NEURON MOD files are used. Models provided as standard by NEURON are also valid, such as ExpSyn, IntFire1. +Representation of point neuron models, synapses and ion channels depends on +the target simulator. + +For NEURON, NEURON MOD files are used. Models provided as standard by NEURON +are also valid, such as ExpSyn, IntFire1. For NEST and PyNN, the names of +built-in/standard point neuron and synapse models are used. To support reproducible random numbers in NEURON, it is required to define conventions for the configuration of random number generators, and how they are assigned to channel models, synapses random number generators. To this end, NEURON mechanisms should follow idioms in the MOD files, so that a uniform and automated approach to random number configuration can be employed. Such an approach was out of scope of the current format specification, and will be the subject of future versions. @@ -401,18 +403,17 @@ The details of how node and edge populations are defined and represented are des In general, populations of neurons are heterogeneous in the types of cell models describing each node, implying heterogeneousequations and sets of parameters. We define a node group as a set of nodes with a homogeneous parameter namespace implying a uniform tabular layout. A population is defined as the union of one or more groups, which need not have uniform tabular layout among them, and further defines some indexing datasets. A population provides then a uniform view on a collection of nodes which have heterogeneous parameterization namespaces. -A model_type attribute allows nodes to be configured as "biophysical", “point_soma”, etc. and also “virtual” one may be provided to specify external (or “virtual”) nodes that are not explicitly simulated but provide inputs to the network. +A model_type attribute allows nodes to be configured as `biophysical`, `point_neuron`, etc. and also `virtual` one may be provided to specify external (or `virtual`) nodes that are not explicitly simulated but provide inputs to the network. A typical network may include multiple simulated populations as well as multiple populations of external input nodes. -Each node in a population has a node type. Attributes can be assigned to nodes and node types, whereby a node assumes attributes of itsnode type, and can override them at the individual node level. Below, attributes which have specified interpretation and expected units (where applicable) are defined, and are either "required" or “optional reserved”. +Each node in a population has a node type. Attributes can be assigned to nodes and node types, whereby a node assumes attributes of its node type, and can override them at the individual node level. Below, attributes which have specified interpretation and expected units (where applicable) are defined, and are either "required" or “optional reserved”. -Node types are defined in node types CSV files containing named columns, one for each attribute of a node type. First, the node_type_id column is required, and defines the node_type_id of each row. To allowmultiple populations define their own node_type_id’s independently, a population column is also required to resolve collisions between node_type_id’s among different populations. Other "required" attributes must either be defined by the population (see below), or be defined in a column in the associated node types CSV. The node types CSV may also include “optional reserved” columns names. Apart from these reserved names, the user is free to define any number of additional named columns to suit their needs. Node type columns will be assigned to node attributes with the column name as the key and the value coming from the row with a node’s assigned node_type_id. +Node types are defined in node types CSV files containing named columns, one for each attribute of a node type. First, the node_type_id column is required, and defines the node_type_id of each row. To allow multiple populations define their own node_type_id’s independently, a population column is also required to resolve collisions between node_type_id’s among different populations. Other "required" attributes must either be defined by the population (see below), or be defined in a column in the associated node types CSV. The node types CSV may also include “optional reserved” columns names. Apart from these reserved names, the user is free to define any number of additional named columns to suit their needs. Node type columns will be assigned to node attributes with the column name as the key and the value coming from the row with a node’s assigned node_type_id. +Non scalar attributes may be included in the node types CSV file provided the attribute values are quoted and their components are separated by spaces. Populations are serialized in nodes HDF5 files, and have a single associated node types CSV file to define the valid node_type_ids for the populations in the HDF5 file, and assign attributes applying to all nodes in with a given node_type_id. A node_types CSV file may be shared by multiple population HDF5 files. Node groups are represented as HDF5 groups (with population as parent) containing a dataset for each parameter of length equal to the number of nodes in the group. In the case a node attribute is defined in both the node types CSV and the nodes HDF5, the value in the nodes HDF5 overrides the node types CSV value. - - The HDF5 nodes file layout is designed to store multiple named populations that each may have multiple node groups, but each population with all of its node groups must be self-contained within one HDF5 file.. For each population, the node_id and node_type_id datasets are required because they uniquely identify nodes within a population irrespective of a model_type used. The node_group and node_group_index are required because they identify the location of the group specific data for each node.The model_type attribute is required, but may be defined only in the node_types CSV. The layout of the nodes HDF5 is as shown in Table 1.
| - | - | - | Model Type | -- |
| - | - | point_process | -point_soma | -biophysical | -
| Parameter -Override | -Node -level | -dynamics_params HDF5 group | -- | - |
| - | Node_type -level | -dynamics_params .json | -- | - |
| Model -Object | -Parameter -Namespace | -point process | -Section ∪ pas ∪ -user mechanism | -|
| - | Model | -point process name | -mechanism name | -.nml file | -