The semester has started and development of my simulation continues. Last semester I left the project in a state where I could deploy the simulation using SpatialOS, however it only ran on one virtual machine so only served as a demonstration of my understanding of the SpatialOS pipeline. I did have a multi-worker deployment but the lack of communication between the workers was a big issue and was my priority going into this year.

After thinking about the problem, I identified two key needs. The first is the creation of a data structure which would hold all of the information about a body which would be distributed. This structure would hold the minimum amount of data possible to make the solution scalable without using excess bandwidth. The key pieces of data required are the mass of the body and the position of the centre of mass. Additionally, the data structure could be combined with other local objects to produce a compound structure which holds the combined mass and centre of mass for a group of bodies. This would make the accuracy of the simulation lower, as the exact position of individual bodies is required for a true simulation of gravity, but the network usage performance gains could be enough to outweigh the negative effects.

The second key need would be a simulation manager, a global object which would control the passing of the data structures so that each body, or group of bodies, has enough information about the rest of the system. This problem is not as easily designed around. The global manager would have to be managed by a worker which means that it does not have continuous access to data originating from other workers. To access this data, queries would need to be sent through the SpatialOS platform. SpatialOS provides Streaming Queries  which are specifically for use by objects which need regular updates about other objects in the world, rather than regular Queries which are for infrequent requests to various objects. However, the regularity these are designed for is completely different to the regularity required by this simulation. This feature is designed for periodic (~2.0 seconds) updates about newly available information, rather than frame-by-frame updates needed for the calculations being performed.

Whilst this could still potentially work, all the accuracy and performance of the simulation would be completely lost and it would certainly not be scalable. The aims of this project are to test how SpatialOS can be used to run a performant and accurate scientific simulation. Getting used to SpatialOS’s unique design and programming patterns has been written about and there’s lots of helpful discussion on their website. In particular this blog talks about how do rethink world management in a way that agents are their own manages and do not rely on any global manager. Fortunately for these developers, they were developing a city simulation which has great granularity with little need for agents in vastly different physical locations to interact with one another. Unlike the n-body gravity simulation.

I came to the realisation that it would probably be best to cut my losses and start work on a different simulation model, something that was more inherently suited to way in which SpatialOS is designed. My next tasks are to speak with my supervisor to see if this is feasible at this stage and to see if she has any suggestions on alternate simulations.