-
Notifications
You must be signed in to change notification settings - Fork 50
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
Move code generator options into NESTML model #721
Comments
In general, it would be preferred to specify the ports mapping during the connection setup, that is, when Connect() is called to set up the connection; we also specify the synapse type there, so it's logical for these to go together. (This is preferred over setting "global options" of the code generator.) This would mean that we need a new argument to Connect(), or to the syn_spec, which we name "post_syn_port_map". Some proposals for syntax would be the following. Note the complication that synapse_models can be specified as a list, with the same size as the postsynaptic population (this only works for the "one_to_one" and "fixed_total_number" connection patterns). Assuming we have
nest.Connect(presyn_neuron, homoge_post_neuron,
syn_spec={"synapse_model": "stdp_synapse",
"post_syn_port_map": ["x:y", "p:q"]}) We can use the compacted "neuron_variable_name:synapse_variable_name" format, or something more expressive (equivalently): "post_syn_port_map": ["x:y", "p:q"]
"post_syn_port_map": [("x", "y"), ("p", "q")]
"post_syn_port_map": [{"neuron": "x",
"synapse": "y"},
{"neuron": "p",
"synapse": "q"} Note the internal renaming:
Simplifications:
Notes:
|
One additional thought: Maybe we should provide a list of such mappings for the models shipped with NEST(ML). I assume that users would not like it that much, if they had to provide such a list even for standard situations like connecting |
In the synapse, input ports are currently defined agnostic to whether they will connect to a pre- or postsynaptic partner:
They are only assigned during code generation, via the code generator options:
This works fine and is a flexible mechanism that was also adapted to map postsynaptic variables (like
V_m
) onto synaptic continuous-valued input ports with a potentially different name (likepost_V_m
), where they can be used as third factors for synaptic plasticity rules.The difficulty is, that this information cannot be extracted from the NEST simulation script, which means it is incompatible with the proposed JIT workflow.
For this reason, we suggest to move the "meaning" of input ports into the NESTML synapse model itself, using keywords such as "pre" and "post" (and "modulatory"):
This would be compatible with multisynapses, as there would just be more than one "pre" port.
The most general case, of mapping neuronal variables onto differently-named input ports, could be done by passing the code generator options by explicit call to the JIT mechanism, for instance
The disadvantage of this is that this is very far removed (in terms of lines of code) from the place in the script where the neurons and synapses actually get instantiated.
An external (my_network_codegen_opts.json) file would of course do the same trick.
The text was updated successfully, but these errors were encountered: