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

[Hugo Cornelis]

Hi,


I read the MUSIC RFC with interest.  The document provides a clear
description of scope, goals, API and behaviour.

First, I think the clear distinction between event based
communications and continous time based comms makes very good sense
(and probably simplifies the implementation?).  Also the availability
of general purpose message ports can come in handy.

Most of what is in the document, nicely lines up with the CBI
simulator architecture (see http://www.neurospaces.org/, we are
working on a paper).  In a one sentence summary, the CBI architecture
is a paradigm for software development of neuronal simulators (and
also other development like technical documentation).  The neurospaces
project is a specific implementation that closely follows the CBI
architecture, and offers a model container, solvers, input and output
objects, and other software components.  In the same context, the
MUSIC API is a messaging system for parallel hardware, and at the same
time maintains the global simulation time, such that it can activate
other software applications in the correct way.  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?

If I would be using the MUSIC environment in combination with the
software components of the neurospaces project, I would setup the
MUSIC connections directly from the Neurospaces model container, and
have MUSIC talk directly to the solvers and the input and output
objects.

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?

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?

Thanks,


Hugo


On Fri, May 16, 2008 at 6:27 AM, Örjan Ekeberg <orjan at nada.kth.se> wrote:
> Hi all,
>
> There is a small, but potentially confusing typo in the legend of figure
> 2.4 in the RFC document. The text says that application A executes
> ahead of application B, but in reality the figure shows the opposite
> situation: B starts before A and continuously runs ahead of A. The
> point is that the specified delay still makes it possible for data
> produced by A to reach B in time.
>
> Yours,
> Örjan
> _______________________________________________
> music-rfc mailing list
> music-rfc at incf.org
> http://lists.incf.org/mailman/listinfo/music-rfc
>



-- 
 Hugo Cornelis Ph.D.

 Research Imaging Center
 University of Texas Health Science Center at San Antonio
 7703 Floyd Curl Drive
 San Antonio, TX 78284-6240

 Phone: 210 567 8112
 Fax: 210 567 8152