Skip to content
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

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

Open
cristianoalessandro opened this issue Jul 15, 2020 · 9 comments

Comments

@cristianoalessandro
Copy link

cristianoalessandro commented Jul 15, 2020

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

cristianoalessandro commented Jul 15, 2020 via email

@mdjurfeldt
Copy link
Contributor

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
Copy link
Author

cristianoalessandro commented Jul 20, 2020 via email

@cristianoalessandro
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

cristianoalessandro commented Jul 27, 2020 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants