IDF09-Poster
From Education
Contents |
High-level Description
This project constructs mechanisms necessary to harness a real-time high performance cluster based simulation of a Galaxy into an interactive immersive collaborative virtual environment. The Galaxy simulation is based on a simple N-body mathematical model; the virtual environment is the metaverse enabled by Opensim and sciencesim.com. This is a new capability both setting the standard and providing general interfaces for others to use. The ability to control the simulation and simultaneously re-examine the model from different view points with geographically dispersed participants is vital to developing new forms of teaching in this fast-paced digital era. Our project allows remote participants to observe the real-time simulation as if they were running on the participant's laptop, although the data might be coming from clusters anywhere in the world.
Technical Description
In the current implementation of the project, a GalaxSee simulation runs on a cluster, while the ExtSim plugin module for OpenSim actively pulls data from that run. In this manner, we've been able to dynamically visualize a GalaxSee run in the 3D virtual world of ScienceSim, running the OpenSim server. This environment allows a user to initiate a run of GalaxSee and watch as the simulation unfolds around them. There are multiple things that must be in place for this to work. First, there must be a system in place for catching user requests to initiate a GalaxSee run. This request is sent to a daemon running on a computational resource, which in turn starts the GalaxSee simulation. In between the daemon on the cluster and the user, another daemon is started which serves to channel the coordinate data from GalaxSee into the local ScienceSim server.
Future works
Explanation of problem
The current implementation is problematic for a couple reasons. It currently requires the virtual world to actively request more data, a "busy waiting" phenomenon, severely increasing the latency of all components throughout the system. Second, in order to support this model of busy waiting, there must be quite a few components that work together in a fairly complex, fragile manner. These troublesome aspects make the system difficult to understand, inextensible to simulations other than this particular test case, brittle and slow, and incapable of handling large amounts of data or large numbers of simultaneous simulations.
Possible Solution
Currently, we use a plugin to the OpenSim server which actively requests additional data. Instead, a more general solution to the above problems is a new plugin, alerting the Mini-Region-Module of new cluster data via an OpenSim event. This plugin would listen on a socket for more data. On the other end, the simulation is pushing data into the socket as fast as it can. As the plugin receives data, the event is raised and the data is passed into the Mini-Region-Module. It is then that module's responsibility to verify the data, and cause OpenSim objects to interact as dictated by the specific simulation.
This solution removes the need for the complex middle-ware components, reduces latency between data generation and data visualization, and provides a structure that is much more suitable for a wide range of simulations. The goal would be to provide an interface similar in principle to that of MPI, thus lowering the bar for anyone familiar with MPI wanting to tie in their own simulations to OpenSim.
