Improbable Icon

Keeping entities on a single (dedicated) worker


#1

I’m planning to perform finite-element (network) type of simulations within SpatialOS, alongside traffic simulations. The later type of simulation obviously fits well with SpatialOS, so I don’t expect major issues there (updating of state of vehicle depends only on the state of the vehicle itself and its near surrounding).
However, for the calculation of a new state of an entity (node) in a finite-element simulation data of all the nodes in the network are required (for the intrigued, a large set of equations, representing the full network state is collectively solved). As a result, not only the state of a single entity is calculated but of all entities in the network. Consequently, the updated state needs to be written to all those entities as well (from within a single script and thus worker).

So it seems I have the need to keep the entities of a network together on a single (dedicated?) worker so that within a script I can easily collect (read) data from those entities, solve a collective problem, and write results to those entities.

I could also create a (fictive) “collector”-entity that initially stores the the states of all the entities in a network, and listens to events (or updates from the component properties) from all those entities to keep the state synced with the entities. In that way, the assignment of entities to workers does not matter, since the collective state is gathered in the “collector”. I could associate a script with this entity that is able to calculate the new collective state. However, how do I write the result to all the entities that are not necessarily situated on the worker where the “collector” resides?

Am I remotely on the right track? What would be a good way to solve this problem in SpatialOS?


#3

Having a single “dedicated” worker is certainly possible, here’s how.

Remember that a worker deals with components and indirectly with entities. If a worker is given permission to read/write only to one component, the load will be lower and the worker will be able to check-out all components of the specified type.

Keeping only one worker of this type is a matter of settings.

Keep in mind that this goes again the distributed nature of SpatialOS and may not work if your simulation is too big.

P.S. I had the idea of building a tool to study complex network when I ran into the same issue of how to collect all that data. Degree distribution, connectedness, sparsity, vulnerability to random failure, etc… if your familiar with network science.