Multiple, concurrent simulations

Post Reply
w-de
Posts: 2
Joined: Wed Oct 18, 2017 2:55 am

Multiple, concurrent simulations

Post by w-de » Wed Oct 18, 2017 3:06 am

Hi,

I would like to run multiple concurrent simulations and then analyse their results after they have run, before running another set of simulations and repeating the process.

Essentially I'm implementing a genetic algorithm and would like to parallelise the simulation of each population member -- however I am unsure of how to implement multiple parallel simulations.

Currently I am calling glutmain(...) to initialise my simulation, and then controlling it with a state-machine implemented into the update() function. The process currently runs indefinitely (executing a genetic algorithm optimisation in a wholly serial manner).

Any examples or help are greatly appreciated!

User avatar
drleviathan
Posts: 550
Joined: Tue Sep 30, 2014 6:03 pm
Location: San Francisco

Re: Multiple, concurrent simulations

Post by drleviathan » Thu Oct 19, 2017 8:52 pm

I can think of several ways to do this.

(1) If you need 15 or fewer simulations then it would be possible to run them all at the same location in one World instance but give each its own collision group configured to only collide with other things in its same group: 15 simultaneous simulations, 1 World.

(2) If you need more than 15 then it would be possible to separate the simulations spatially such that each was in its own "simulation island" not near any of the others. That is, you could create an NxNxN grid of simulations spaced far enough out that none of them touched the others. N^3 simultaneous simulations, 1 World.

(3) You could combine (1) and (2): 15 * N^3 simultaneous simulations, one World.

(4) Given M CPU's you could multi-thread (3): 15 * N^3 simultaneous simulations per World, M Worlds.

Basroil
Posts: 463
Joined: Fri Nov 30, 2012 4:50 am

Re: Multiple, concurrent simulations

Post by Basroil » Mon Nov 20, 2017 12:41 am

I had plenty of success doing just that for some research projects I had. Now that Bullet is more multithread compatible (btDantzig had a memory share bug a while ago that I used to have to manually patch all the time until about 2.82/2.83), it's a piece of cake.

Don't bother using the GUI setups and it's easier, faster, and much more accurate.

After that, just build a world pool (one per CPU core), create your own initialization (and reinitialization) method, and then a quick job dispatcher. You should be able to run about 1 simulation minute per real second (or more) at the industry standard 2kHz (most servo control loops are that speed, though some are 200 and others 20000) simulation rate with a newish high end desktop processor.

Just watch out for data storage, managing what data is important and what is not will save you headaches when trying to record how the evolution is progressing.

w-de
Posts: 2
Joined: Wed Oct 18, 2017 2:55 am

Re: Multiple, concurrent simulations

Post by w-de » Tue Nov 28, 2017 9:37 am

Basroil wrote:I had plenty of success doing just that for some research projects I had. Now that Bullet is more multithread compatible (btDantzig had a memory share bug a while ago that I used to have to manually patch all the time until about 2.82/2.83), it's a piece of cake.

Don't bother using the GUI setups and it's easier, faster, and much more accurate.

After that, just build a world pool (one per CPU core), create your own initialization (and reinitialization) method, and then a quick job dispatcher. You should be able to run about 1 simulation minute per real second (or more) at the industry standard 2kHz (most servo control loops are that speed, though some are 200 and others 20000) simulation rate with a newish high end desktop processor.

Just watch out for data storage, managing what data is important and what is not will save you headaches when trying to record how the evolution is progressing.

Hey,

This is fantastic news! It sounds like you're doing something very similar to what I desire to do. Would you be able to share an example of a previous project? Or of the basic code to achieve these kind of concurrent graphic-less simulations?

I have begun implementing parallelisation of simulation with the use of separate processes, but this is tedious and your method is superior - I would like to begin changing to this, knowing that it is possible.

I'm quite new to bullet and would appreciate any help you can offer.

Cheers,
Wade

Basroil
Posts: 463
Joined: Fri Nov 30, 2012 4:50 am

Re: Multiple, concurrent simulations

Post by Basroil » Thu Nov 30, 2017 4:43 am

w-de wrote: Hey,

This is fantastic news! It sounds like you're doing something very similar to what I desire to do. Would you be able to share an example of a previous project? Or of the basic code to achieve these kind of concurrent graphic-less simulations?

I have begun implementing parallelisation of simulation with the use of separate processes, but this is tedious and your method is superior - I would like to begin changing to this, knowing that it is possible.

I'm quite new to bullet and would appreciate any help you can offer.

Cheers,
Wade
Unfortunately I can't share the implementation right now, but basically you just need a few items:
1) A simple job system with a job pool and as many worker threads as you have CPU cores (sometimes more, don't get greedy though since scaling is a tricky thing, and watch out for HT vs real core issues)
2) A way to reset the simulation environment to default starting condition (check the GUI examples to see how it's done, per worker thread it should be called before the next job starts on that worker)
3) A way to plug in the changes you want to make (what gene information actually is doing)
4) A definition for your fitness function that does not require the entire simulation state trace (i.e. don't expect to record body positions for 2000 specimens for 10min at 2000Hz, the memory use and computation increase is huge for little to no benefit)
5) A way to save results from a few simulations you want to see later
6) A reasonably fast computer (don't expect to run a million simulations a day on one raspberry pi)

In general, just look through the GUI examples to find out how bullet works, then just base off of the core code without the GUI classes and you'll have something up and running in no time

Post Reply