Add numeric solver to synapses #1208
Conversation
Bencher Report
| y += [syn_stats["y"]] | ||
| z += [syn_stats["z"]] | ||
|
|
||
| # TODO: Adjust tolerance |
There was a problem hiding this comment.
Could you take care of this TODO?
There was a problem hiding this comment.
The tolerance is a bit high. The tests fail if I decrease the tolerance. I tried a few things, such as adjusting rtol and atol, but couldn't lower the difference. Do you have any ideas?
There was a problem hiding this comment.
I tried to plot the Lorenz system in a more familiar way, by giving it a higher temporal resolution, see pnbabu@4752f59
I thought that perhaps the high needed tolerance values are due to the reference simulation being one timepoint off (i.e. delayed or shifted forward by one timepoint). Unfortunately I didn't get a chance to test this further. I would be okay merging this PR with to-dos in place if they are additionally turned into a GitHub Issue.
There was a problem hiding this comment.
Plotting the high-temporal resolution for the NEST simulation is a bit tricky because the synapse values can only be captured at the end of a simulation run, which is set to 1 ms in the test. Do you think lowering it to 0.1 ms would benefit here?
There was a problem hiding this comment.
I just wanted to get some confidence in the reference simulation results; now that I see the familiar Lorenz dynamics, I am more happy about that. I still do not understand why the numerical error tolerances should be so high (1E-3) though. One hypothesis would be that the recorded values are shifted by one timepoint (one resolution timestep), but I haven't had time to look into this further yet. The basic problem is (explaining the) high numerical tolerances.
There was a problem hiding this comment.
I adjusted the test a bit to have the same start and end time points. Your hypothesis might be correct. A while back I had plotted the solution from both GSL and scipy solvers and they seemed to match well.
pynestml/codegeneration/resources_nest/point_neuron/common/SynapseHeader.h.jinja2
Outdated
Show resolved
Hide resolved
|
|
||
| if self.option_exists("strictly_synaptic_vars") and removesuffix(synapse.get_name(), FrontendConfiguration.suffix) in self.get_option("strictly_synaptic_vars").keys() and self.get_option("strictly_synaptic_vars")[removesuffix(synapse.get_name(), FrontendConfiguration.suffix)]: | ||
| strictly_synaptic_vars.append(self.get_option("strictly_synaptic_vars")[removesuffix(synapse.get_name(), FrontendConfiguration.suffix)]) | ||
| strictly_synaptic_vars.extend(self.get_option("strictly_synaptic_vars")[removesuffix(synapse.get_name(), FrontendConfiguration.suffix)]) |
There was a problem hiding this comment.
This was a bug, right? How could this ever have worked before?
There was a problem hiding this comment.
The synapse model used in the test in this PR has variables that strictly belong to the synapse. Hence, I added them to strictly_synaptic_vars in the codegen_opts introduced in #1229.
This then caused the append in the line to create a list of lists, which failed at line:
nestml/pynestml/utils/ast_utils.py
Line 1779 in 81ed384
That's why I changed it to
extend. Perhaps we should change all the append calls here to extend instead to avoid errors.
|
Could you also update |
doc/running/running_nest.rst
Outdated
| The synapse is allowed to contain an ``update`` block. Statements in the ``update`` block are executed whenever the internal state of the synapse is updated from one timepoint to the next; these updates are typically triggered by incoming spikes. The NESTML ``timestep()`` function will return the time that has elapsed since the last event was handled. | ||
|
|
||
| Synapses in NEST are not allowed to have any nonlinear time-based internal dynamics (ODEs). This is due to the fact that synapses are, unlike nodes, not updated on a regular time grid. Linear ODEs are allowed, because they admit an analytical solution, which can be updated in a single step from the previous event time to the current event time. However, nonlinear dynamics are not allowed because they would require a numeric solver evaluating the dynamics on a regular time grid. | ||
| Synapses can have ODEs with linear and non-linear dynamics. In the case of linear dynamics, the ODEs are solved with the propagators provided by the ODE-toolbox; for non-linear dynamics, the ODEs are solved using a fourth order Runge-Kutta solver with adaptive timestep. |
There was a problem hiding this comment.
Can the tolerances be adjusted like in the neuron model? Could you add a reference to GSL or to the GSL solver?
2 participants
No description provided.