MPI error with nest.Population.set(spike_times=...)

[Andrew Davison]

Setting spike times using the set() method fails when running with more than one MPI process, if the backend causes "spike_times" to be a computed parameter (e.g. by adjusting time offset, as pyNN.nest does).

Example script:

import matplotlib.pyplot as plt
import numpy as np
import pyNN.nest as sim
from pyNN.parameters import Sequence

sim.setup(min_delay=0.2)
rank = sim.rank()
num_procs = sim.num_processes()

spks = sim.Population(5, sim.SpikeSourceArray())
cells = sim.Population(10, sim.IF_cond_exp(tau_m=1.0, tau_syn_E=0.2))
cells.record('v')

prj = sim.Projection(spks, cells, sim.AllToAllConnector(), sim.StaticSynapse(weight=0.1, delay=0.2))

spike_trains = [
    Sequence(np.array([0.5, 2.3, 5.6])),
    Sequence(np.array([0.9, 2.5, 5.9])),
    Sequence(np.array([1.5, 3.0, 6.8])),
    Sequence(np.array([2.2, 3.5, 7.9])),
    Sequence(np.array([2.8, 4.7, 8.4]))
]

spks.set(spike_times=spike_trains)

sim.run(10.0)

vm = cells.get_data().segments[0].analogsignals[0]

if rank == 0:
    plt.plot(vm.times, vm[:, 0])
    plt.plot(vm.times, vm[:, 1])
    plt.savefig(f"spikesource_mpi_{sim.__name__}_np{num_procs}.png")

sim.end()

Error message:

Traceback (most recent call last):
  File "spikesource_mpi.py", line 24, in <module>
    spks.set(spike_times=spike_trains)
  File "/home/andrew/dev/PyNN/pyNN/common/populations.py", line 355, in set
    parameter_space.expand((self.size,), self._mask_local)
  File "/home/andrew/dev/PyNN/pyNN/parameters.py", line 466, in expand
    new_base_value[mask] = value.base_value
TypeError: float() argument must be a string or a number, not 'Sequence'

Reported by @antolikjan

[Andrew Davison]

We could fix the expand() method to handle non-numeric parameter values such as Sequence, but really spike_times should not be considered a computed parameter, since it doesn't depend on the values of any other parameters, so the code path with expand() shouldn't be taken in this case. Fixing this properly would require an overhaul of the parameter translation machinery, which we should do at some point, but I think making SpikeSourceArray a special case is an adequate fix for now.