Document: MUSIC RFC Response 19 May 2008 In response to: MUSIC RFC 18 April 2008 Author: Ben Mitchinson / IWG -------------------------------------------------------------------------- Hi We at the ABRG have developed an execution framework called BRAHMS for building integrated computable systems from separate computational processes. It strikes us there is some crossover between our aims (BRAHMS & MUSIC), and we think it might be worth establishing how they relate, at least, so as to minimize repetition and/or confusion. Why they have such similar names I couldn't tell you. I'll start by summarising what BRAHMS is, quickly - please see the attached file "BRAHMS Executive Summary" for more detail, and for much more detail than you want see the BRAHMS Wiki. BRAHMS is a general integration/execution framework (it is not "neural" in any sense). It is designed to play the same sort of role as Simulink (assuming you're familiar), but is open source and free, has a small deployment footprint, and offers substantial additional features that Simulink does not (see attached, but notably parallelisation and increased efficiency). You might also compare it to IKAROS: BRAHMS is ahead of IKAROS in terms of execution functionality and generality, but lacks its web-based and GUI features. BRAHMS has been or is being deployed within several research projects in which we are involved, including the successfully completed WhiskerBot project (for which it formed the laboratory simulation platform as well as the embedded control platform) and the current ICEA, BIOTACT and REVERB projects (same plans). Our intent is to begin publicising BRAHMS to the wider community starting around midsummer, with the planned release of V0.7 RC1 (Beta 2, 0.6.2, is currently available for download at SourceForge). BRAHMS is going to IROS 2008 (Nice, September) and (hopefully) to INCF 2008 (Stockholm, September), as well as making an appearance at SFN (Washington, November). BRAHMS has been in existence now for four years, and a recent flurry of activity has brought it up to release standard, hence the midsummer release target. BRAHMS represents part of our commitment to the philosophy and methodologies of neuroinformatics: developing general purpose tools that facilitate large-group working in neuroscience, and sharing and reusing resources (albeit, in this instance, models). In addition, Sheffield is also a funded member of the CARMEN consortium. CARMEN (as you are probably aware) is a four-year e-Science pilot project funded by the EPSRC. The objective is to create a virtual laboratory in which data on neuronal activity (electrical and optical measures) can be shared, stored, manipulated and modelled. Next, I'll summarise what I think we understood about MUSIC from reading the RFC. Apologies in advance if we didn't get it exactly right :). MUSIC is a communications library layer that sits on top of MPI, facilitating communication between compute processes that correspond to processes in the engineering sense (dynamic systems with inputs and outputs). This is much like the communications aspect of BRAHMS, though that offered by MUSIC includes event-based as well as continuous communications links. The MUSIC layer offers (over and above MPI) communication buffering, synchronisation, and of course satisfies the usual constraints of portability, inter-process independence, and high performance. It is targeted at integrating neural systems, but as far as we can tell is not restricted in that respect. MUSIC leaves application and simulation management entirely to the user, offering the least necessary to allow processes to intercommunicate. BRAHMS, in contrast, attempts to offer all of the services that systems need apart from the computation of process dynamics itself (time loop, OS interactions, structured data containers, inter-process synchronization, performance monitoring, parallelisation, data logging, etc. - see attached). To conclude, our summary comment would be to ask: "How much overlap do you see between MUSIC and BRAHMS?". There is clearly common ground in principle, but whether there is in practice is a separate question. Both aim to answer the overarching question of "How do we get separate computational processes to work together at run-time?" (freeing us to develop these processes separately). The difference is that the philosophies of BRAHMS and MUSIC are to offer a maximal and minimal, respectively, set of integration services with that; i.e. BRAHMS is an execution framework whereas MUSIC is a communications library. If BRAHMS and MUSIC are to coexist, it is worth asking whether there is anything we should be doing to make them interoperate: Is it useful to have BRAHMS support the MUSIC communications interface? Or to tie in MUSIC to the SystemML infrastructure by supplying a minimalist SystemML "process launcher" with it? Looking forward to your comments. Best Regards Ben Mitchinson On behalf of the Integration Working Group (IWG) Adaptive Behaviour Research Group (ABRG) The University Of Sheffield UK -------------------------------------------------------------------------- The IWG is: Jon Chambers Tak-Shing Chan Charles Fox Kevin Gurney Mark Humphries Ben Mitchinson Tony Prescott ABRG (incorp. IWG) http://abrg.group.shef.ac.uk BRAHMS Wiki (links to SystemML, SourceForge) http://brahms.pbwiki.com IROS 2008 http://users.aber.ac.uk/msh/WS08/speakers.html INCF 2008 http://www.neuroinformatics2008.org CARMEN http://www.carmen.org.uk WhiskerBot http://www.whiskerbot.org ICEA http://www.iceaproject.eu BIOTACT http://www.biotact.org REVERB http://www.abrg.group.shef.ac.uk/projects/reverb/public