I haven’t even begun writing a single-thread version of the EcoGillespie, but the goal for this project is to insulate the modeler from the details of execution—including, hopefully, leaving open the possibility of multithreaded execution, and ultimately even execution on a distributed-memory system (cluster).
The work-in-progress simulation algorithm goes something like this:
- Initialize model: simply call the top-level model object’s constructor, with parameter settings, and let it do its thing.
- Create a top-level simulation object that will manage sub-simulation objects, one for each processor.
- Partition the model into n pieces, where n is the number of processors available to the simulation. In the case of, say, two processors and a top-level model object that contains two lower-level objects (say, metapopulations that in turn contain subnetworks), this is easy: assign one object to one processor. If there’s just one high-level network—say, one scale-free disease network—the graph will be partitioned using a mincut algorithm or something like that to ensure that connections between subgraphs is minimized.
- Create a sub-simulation object for each of the pieces of the model. One thread, one simulation object. Also assign one random number generator per object.
- Execute the Gillespie algorithm in parallel on each sub-simulation.
That last step is the tricky part, because the question arises: what happens when an event occurs on one thread that affects another thread? Next post…