Non-Determinism + Random Spikes in Data Plots

Description

The NRP does not compute simulations deterministically, running the same simulation two times different results are obtained. In addition, depending on the compute load of Gazebo and NEST different quality of resulting plots are generated, in particular random spikes may occur in the data.

Setup:
A sin(t) signal is generatd in the Transfer Function, fed into three identical LIF neurons in PYNN. The neural output is retrieved and assigned to a 1DOF revolute joint model in the NRP.

1) runnin the same simulation two times generates different plots of the resulting joint angle of the model.
See:

2) We add 1000 additional not connected neurons to PYNN to increase its workload. Afterwards without the additional neurons, we add a sleep(2) for two seconds in a Transfer Function:

Despite the exact same experiment setup, both these plots have a much better quality, in particular we do not see random spikes occuring.

The results may show the deficies of the CLE simulator calls, in particular if the procedure is implemented as
------ Gazebo ------
– NEST – – TF –
an increased workload in the brain pipe can lead to this:
------ Gazebo ------
— NEST — — TF —

Instead, simulator and Transfer funtion calls should always synchronize properly like:
------ Gazebo ------ — TF —
— NEST —
and
— Gazebo —
------ NEST ------ — TF —

Research experiments multiple simulation runs need to aim the exact same experiment result.

Benedikt

Attachments

5

Activity

Pro tip: press M to comment

Michael Zechmair 
November 8, 2019 at 9:11 AM

Divided into subtasks, see corresponding tasks

·

Michael Zechmair 
July 10, 2019 at 8:09 AM

Current status: Transfer function now waits for ROS messages before executing. This resolves the issue most of the time. Results are consistent roughly 90% of the executions, with random spikes occuring otherwise. Will create a new bug report to address these issues, which most likely have more to do with RNG seeds.

·

Benedikt Feldotto 
May 20, 2019 at 10:58 AM
(edited)

Another aspect related to this issue is described here:

Two transfer functions are added that both read out the same joint angle value from ros. Both TF run in parallel. However, when plotting both the result is significantly different, in particular one observes clean plots and a very messy one. Experiments are irreproducible if plots are even depending on which transfer function they are generated from..

update: the first transfer function is messy, the second one is fine. Idea just from the observation: In this case NEST finishes earlier than Gazebo, so directly after Gazebo finishes the Transfer functions are executed, however ros data transmission may take some time that is not taken into account, therefore the proper data is only apparent after short time, aka in the second transfer function.

Ugo suggested that also reducing the buffer size of ros topics may help, is this a global change that may be quick fix?

·
Done

Details

Assignee

Reviewer

Priority

Created April 15, 2019 at 8:49 AM
Updated November 22, 2019 at 11:33 AM
Resolved November 8, 2019 at 9:11 AM