Epic : TVB Nest co-simulation multiscale (computer to supercomputer)

lionelkusch commented 4 years ago

Aspect	Detail
Summary	Creation the tools of co-simulation Nest and TVB
Task Area	Functionality
Assignee	@lionelkusch , @sdiazpier, @maedoc, @dionperd
Information	@w-klijn, Michiel van der Vlag
Prerequisites
Dependencies

Summary

The proof of concept for TVB and Nest co-simulation was created in this repertory (https://github.com/multiscale-cosim/TVB-NEST). The goal is create a robust application.

Tasks

[x] Test the public repository to check if everything is working
[x] Develop a method for deployment and testing installation of the prototype on super computer
[x] Finish the integration the MPI I/O of Nest (https://github.com/nest/nest-simulator/pull/1456 )
[x] integrate the I/O in TVB ( https://github.com/the-virtual-brain/tvb-root/pull/190 )
[x] improve the communication between Nest and the translator TVB to Nest
[x] Test the performance of the prototype
[x] Create documentation of the implementation
[x] Create a collab with an example of the use of the proof of concept
[ ] Have feedback of users ( example : https://neurophil-freewill.org/ )
[ ] Creation of application for ebrains where the user can define the function of the translation function

Requirements

The development of available tools in ebrains like collab.

Acceptance criteria

Need to be defined with people in charge. For the performance, the goal is to reduce the time of the communication between simulator and translator. The actual bottleneck is the communication between Nest and translator. For the publication and the integration of the project in ebrains, the demonstration of the prototype in ebrains during the next HBP summit.

maedoc commented 4 years ago

seems like we need @dionperd here, see also https://tvb-nest.apps.hbp.eu which is currently just a notebook, but which will already set expectations.

maedoc commented 4 years ago

Though the kernel dies while running through the notebook.

w-klijn commented 4 years ago

When I start the kernel it appears to work. Lots of warning. For the lionel work to be accessible from a container we need to think about the interface. The whole multi-node deployment does not lend it self for interactive Jupyter work.

dionperd commented 3 years ago

Following up at this discussion, and as Lionel and I are trying to have our implementations of TVB - NEST co-simulation converge with the following two objectives: -parallel co-simulation which is currently missing in my implementation, -a more user-friendly -mid-term, temporary- interface that will allow us to do some science with tvb-multiscale in the weeks/months to come,

I came across this software Ray, which has the following nice features:

it can parallelize for both PC and Cluster, e.g., see configuration for slurm: https://docs.ray.io/en/latest/cluster/slurm.html it has a very easy and intuitive user-interface, where remote class objects stand out, making it possible to e.g., run a notebook on a Head node and control interactively TVB and NEST running on other processes and resources (e.g., cluster nodes); I can have an example running in a few weeks I think, and I think it can work well with containers: https://docs.ray.io/en/ray-0.4.0/using-ray-and-docker-on-a-cluster.html So, I would like to take a step forward from just using the subprocess Python module and use files in order to coordinate the Co-simulation, mainly because I want to support a similar user-experience people in my lab now have with sequential tvb-multiscale Co-simulation, on the scientific use-cases and projects that are currently running.

The use I envision is that the application starts from one Head node, perhaps running a Jupyter notebook, and two remote objects are formed, a TVB and a NEST orchestrator, which run on different processes and potentially different computational resources and can

build the TVB and NEST network models, prepare the translators, including the MPI communication Lionel is currently using, perform several rounds of simulation - analysis - visualization, and finally terminate and clean up. Initially, I envision this working on a single machine, but I hope that it could scale to a cluster, perhaps giving up some of this interactiveness.

I hope you find this a nice idea in the mid-term that could offer some more experience on the user interface(s) we need to implement for our project.

maedoc commented 3 years ago

xmlrpc is in the standard lib and does what you want, I would not look further: https://docs.python.org/3/library/xmlrpc.server.html#simplexmlrpcserver-example

For the longer/larger scale, the cosim group is producing the solution of interest.

I think the fancy solutions like Ray that are trying to gain traction will have hidden assumptions or clever tricks built in that cost you/us time to debug later on. XMLRPC is old and boring, with debugging advice built into the docs.

multiscale-cosim / EBRAINS-cosim