INCF / MUSIC

MUSIC, the MUltiSimulation Coordinator
GNU General Public License v3.0
38 stars 38 forks source link

Data exchange before calling runtime #21

Open uahic opened 8 years ago

uahic commented 8 years ago

Currently Music is not flexible enough for some (more or less special) use-cases. Especially in order to set up ports, they must be known a-priori on all communication sides. I've tried to use MPI4PY to send messages via the global communicator but it did not work out of the box. The "usual" message in/out ports are also not very suitable for this because they can only be used when calling tick(), which is only available after the Setup has been done.

For the moment its fine, we just want to get our neuro-robotics platform working with distributed NEST instances. In the long term, however, we would like to support all features and, thus, we would like to add a bit more flexibility. I could spent some time on doing this if the maintainers of music are interested.

@mdjurfeldt I recall that you were talking in Geneva about something like "out of order" ports, maybe this was exactly for this use-case?

mdjurfeldt commented 8 years ago

Yes, I've proposed "out-of-band" ports, ports which you can use to communicate when the simulation is standing still (the simulation loop is paused and no ticks being called).

This is an issue of great interest to the MUSIC maintainers. The most important first step towards this is to propose an extension to the MUSIC API, with associated semantics. You are welcome to come with such a proposal (basically what new calls there should be), and we could then discuss and develop it.

mdjurfeldt commented 8 years ago

Also feel free to consider a completely rewritten API. A new version of MUSIC could support two API:s.