nest simulation does not receive events from a non-nest script

[cristianoalessandro]

Hi all,

I am running into the following issue with a very simple music example. I have a non-nest script sending spikes to a nest simulation. The latter simply consists of a parrot neuron that should just replicate the received events, and a spike detectors that should write the spikes to a file. Unfortunately, the file remains empty as if no spikes are received.

I debugged it as follows:

1. use a nest script as a sender while keeping the original nest receiver. This works: the receiver writes appropriate spike events to the file. Meaning that the receiver should be fine.
2. use the original non-nest sender, and a non-nest receiver (it does the same thing as the original nest receiver). This works as well. Meaning that the sender should be fine.
3. use a nest sender and a nest receiver (both doing the same thing as the original scripts). This works too: the receiver writes appropriate events to the file.

The only case that does not work is when I have a non-nest sender and a nest-receiver. Do you have a clue why that could be the case? Code is as follows...

Non-nest sender

import music
import sys

timestep = 0.001
stoptime = 1.0     # This is the actual execution time, not the simulated time span

setup = music.Setup()
outp = setup.publishEventOutput("out")

firstId = 0 
size = 1 
buf = 1 

outp.map (music.Index.GLOBAL,
          base=firstId,
          size=size,
          maxBuffered=buf)

runtime = setup.runtime(timestep)

tickt = runtime.time()
while tickt <= stoptime:
    # Send an event for each tick, util stoptime
    outp.insertEvent(tickt, firstId, music.Index.GLOBAL)
    runtime.tick()
    tickt = runtime.time()

Nest receiver

import nest

N = 1

nest.SetKernelStatus({"overwrite_files": True})

meip = nest.Create ('music_event_in_proxy', N)
nest.SetStatus (meip, [{'port_name': 'spikes_in', 'music_channel': 0}])

delay=2.0

nest.SetAcceptableLatency('spikes_in', delay)

# Parrot neuron
n_in = nest.Create ("parrot_neuron", N)
nest.Connect(meip, n_in, 'one_to_one', {"weight":1.0, "delay": delay})

# Create a spike detecor
sdetector = nest.Create("spike_detector")
nest.SetStatus(sdetector, {"withgid": True, "withtime": True, "to_file": True,
    "label": "receive", "file_extension": "spikes"})
nest.Connect(n_in, sdetector)

nest.Simulate (1000.0)

Music config file

[from]
  binary=./sender.py
  np=1

[to]
  binary=./receiver_nest.py
  np=1

from.out -> to.spikes_in [1]

[mdjurfeldt]

Dear Cristiano,

MUSIC has a flexible buffering facility. If the topology of connections between applications allows for it, it buffers spikes which are sent in a chunk.

I'm not at a keyboard now, but I suspect that what is happening here is that the sender buffers spikes and then exits before sending them.

Unfortunately, the examples that I have provided lack a statement that should always should be at the end of a Python script:

runtime.finalize ()

Try adding this and tell me what happens.

The reason why this occurs only when NEST is receiving and Python sending is that the NEST script hasn't specified limits on buffering and the Python sender doesn't call finalize () while the NEST sender does.

[cristianoalessandro]

Thanks a lot! Unfortunately the command you propose throws the error 'pymusic.Runtime' object has no attribute 'finalize'

I saw the finalize() command in the C++ examples, but it does not appear in any pymusic example.

[mdjurfeldt]

This should now work in current github master (commit 262f6f5).

(I have still not fixed the dist-packages/site-packages problem, so remember to move the lib/music files to the correct place after installation.)

Please let me know if this solves your problems.

[cristianoalessandro]

thanks, I'll let you know tomorrow. Should I run the code as it was, or you added the finalize() method that I should now add to the old code?

On Wed, Jul 15, 2020 at 6:13 PM mdjurfeldt notifications@github.com wrote:

This should now work in current github master (commit 262f6f5 https://github.com/INCF/MUSIC/commit/262f6f501b21ee8ba0cd8fbf8c784978577717cc ).

(I have still not fixed the dist-packages/site-packages problem, so remember to move the lib/music files to the correct place after installation.)

Please let me know if this solves your problems.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/INCF/MUSIC/issues/66#issuecomment-658846557, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJNSRLGR3IVB3G4OHTRMV3DR3XISXANCNFSM4O2JQP6Q .

[mdjurfeldt]

You should add runtime.finalize() at the end of the script.

If you want to buffer less spikes (for example those from one tick) per communication, you can achieve this by setting maxBuffered (e.g. to 1) on either the sending or receiving port.

[cristianoalessandro]

Sorry for the delay. I have installed the updated github master. I added runtime.finalize() at the end of the sender script. This call does not throw any error now, but it does not solve the issue: The receiver still gets no events. Note that maxBuffered is set to 1. Any idea? Thanks a lot!

On Wed, Jul 15, 2020 at 7:41 PM mdjurfeldt notifications@github.com wrote:

You should add runtime.finalize() at the end of the script.

If you want to buffer less spikes (for example those from one tick) per communication, you can achieve this by setting maxBuffered (e.g. to 1) on either the sending or receiving port.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/INCF/MUSIC/issues/66#issuecomment-658905571, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJNSRLGTNXQ72SGXLUTVLKDR3XS6HANCNFSM4O2JQP6Q .

[cristianoalessandro]

I debugged and found the issue! I wonder, though, if it is a bug in MUSIC or simply something I do not understand. The code above only works (i.e. the receiver actually receives spikes) if in the nest receiver I set a delay (for the Parrot neurons) and an acceptable latency (for the input MUSIC port) higher than 1.0 and with a decimal different than 0. For example: delay=0.9, no spikes; delay=1.0, no spikes; delay=1.1, spikes received; delay=1.9, spikes received; delay=2.0, no spikes; delay=2.1, spikes received, etc. Can anybody explain? Thanks a lot in advance.

[mdjurfeldt]

Dear Cristiano,

I'm currently on vacation. Can I look at this in detail after a few days? Maybe you can send example files to my email address mikael@djurfeldt.com and I can return to you?

A net delay around the loop which is smaller than the MUSIC tick rate is impossible. So, firstly, there needs to be a modeled delay on incoming spikes and, secondly, MUSIC should be informed that it is OK to deliver those spikes late (by as much as the delay).

What you are experiencing is probably related to the interpretation of the boundary of these conditions. To be safe, make sure that acceptable latency is larger than the minimum delay over the connection by some tiny number (eps). Also, make sure that the tick rate is sufficiently small.

[cristianoalessandro]

Hi Mikael,

of course no problem if you take a look in a few days; in fact, thanks a lot for your help! I'll send you a few examples at your email address.

Best Cristiano

On Mon, Jul 27, 2020 at 8:07 PM mdjurfeldt notifications@github.com wrote:

Dear Cristiano,

I'm currently on vacation. Can I look at this in detail after a few days? Maybe you can send example files to my email address mikael@djurfeldt.com and I can return to you?

A net delay around the loop which is smaller than the MUSIC tick rate is impossible. So, firstly, there needs to be a modeled delay on incoming spikes and, secondly, MUSIC should be informed that it is OK to deliver those spikes late (by as much as the delay).

What you are experiencing is probably related to the interpretation of the boundary of these conditions. To be safe, make sure that acceptable latency is larger than the minimum delay over the connection by some tiny number (eps). Also, make sure that the tick rate is sufficiently small.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/INCF/MUSIC/issues/66#issuecomment-664553251, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJNSRLAWDQVCYNKICBBFMGLR5W66RANCNFSM4O2JQP6Q .