[music-rfc] comments and questions on the MUSIC RFC

[Örjan Ekeberg]

Hugo,
Thanks for your interest in MUSIC and for taking the time to provide
feedback.  I am pleased to hear that you find the current specification
quite compatible with the design used in the neurospaces project.

On Sat, 2008-05-24 at 15:22 -0500, Hugo Cornelis wrote:
> Following the CBI
> architecture, this classifies MUSIC as a 'scheduler' as well as a
> communication infrastructure.  A first question is how well does the
> implementation distinguish between these two?

I see MUSIC primarily as a communication infrastructure but in order to
be efficient, i.e. to avoid handshaking, MUSIC needs to be in control of
advancing time.  It also makes use of decoupled simulation clocks ("time
zones") to hide communication delays.  Thus, internal scheduling is
clearly not separated from the communication strategy.  Still, we have
tried to make scheduling invisible to the applications by only requiring
each application to call the tick() function.

> An implementation that bridges between an NS solver and MUSIC would
> have to (1) inspect the model container to figure its connections with
> other solvers in the system, (2) consruct MUSIC ports by calling
> publish_event_input(), publish_event_output(),  and map() for each
> connection (as appropriate, restricted to events for simplicity), and
> (3) during the simulation call insert_event() when an event occurs,
> such that MUSIC calls the () operator on the receiving side.  Is that
> correct?  Because, at first sight, all configuration data is available
> and accessible at run-time from the model container, this seems
> relatively easy to do?

Correct, with one essential addition: you would have to call the tick()
function at regular intervals (in simulation time).  Also note that the
event handler calls (the ()-operator calls) are not guaranteed to occur
in time-order, so you will need to sort arriving spikes, typically by
using a priority queue.

> A last question: is it possible to serialize the state of the MUSIC
> environment to a file, and reconstruct the environment state from that
> file?  Or is the environment essentially stateless?  What happens with
> buffered events?
> 
> Related to this question, an experimental feature of the NS
> components, is that a simulation running in a NS environment can be
> serialized, stopped, and later reconstructed from a set of files,
> including the current simulation time.  Would that be possible when
> running in a MUSIC environment?

This is an interesting aspect that we have not considered.  In the
current specification there is no way to access the internal buffers via
the API.  However, it should in principle be possible to make a version
of the MUSIC library which would allow for such snapshotting of the
state, without violating the API.  The snapshot operations would then
have to be initiated from the "outside".  Another possibility would be
to flush the buffers by waiting out all events on the receiving sides
and then, after restart, reinject the events in the receivers buffers
(outside of MUSIC).  A minor obstacle is that MUSIC always starts a
simulation at time zero, but this can easily be circumvented.

Regards,
Örjan