248
X-Machines for Agent-Based Modeling: FLAME Perspectives
The GPU needs all memory allocated in advance, before the simulation
starts, due to agents executed as threads on the cards. This means that
all dynamic arrays in a model had to be changed to static arrays of specific sizes, causing considerable changes on the model, reducing some of
the model complexity by limiting the memory size of agents.
In addition to the strict memory sizes, the grid version allows memory
data structures of multiple data types to be created. This capability was
not exhibited by FLAME GPU, allowing only a specific type of variable
of fixed lengths data types. This raises issues if there are certain data
structures used in the model which act as records of multiple datasets
used by the agent such as a product inventory or biological rules. The cell
model [35] was changed from a data structure into a 1D array and stored
in memory where agents could globally read it serially. This caused a
considerable rewriting of the model itself, however it did reduce the potential processing time of the model as data were being accessed serially
rather than as dynamic data structures in the HPC version.
Message Communication between Agents. In FLAME HPC, signals
can be passed between agents as messages with each agent creating multiple messages as needed. FLAME GPU limits this to only one message
per function to be created, which limited the amount of information that
was possible with one function. The model has to be broken down to allow multiple function transitions within one function to allow messages
to be communicated, making the model quite complex or expanding
the message at times to create much more information than previously
designed. This constraint was introduced due to the manner in which
the agent threads communicate, allowing only a single message to be
synchronized per function.
Simpler versus Complex. Although both versions of grid and GPU are
suitable for simulation, the GPU version seems more suitable for simpler
model executions, with agents with basic memory allowing much faster
simulations as compared to the grid version. This makes it suitable for
game-based simulations to visualize the results quickly and where data
analysis is not an extensive requirement. However, with more complex
models such as the model of the complete European economy, with 15
different agent types with increasing complexity and multiple interactions, such models could not be processed on GPU cards.
Looping through Messages. Following is an example of looping through a
message list as defined in FLAME HPC, which allows an agent to read
through all messages in the list, and find agent id and state from the
message and record it in memory.
int MyFunction (xmachine_memory* agent, xmachine_message_list* list)
{
X-Machines for Agent-Based Modeling: FLAME Perspectives
The GPU needs all memory allocated in advance, before the simulation
starts, due to agents executed as threads on the cards. This means that
all dynamic arrays in a model had to be changed to static arrays of specific sizes, causing considerable changes on the model, reducing some of
the model complexity by limiting the memory size of agents.
In addition to the strict memory sizes, the grid version allows memory
data structures of multiple data types to be created. This capability was
not exhibited by FLAME GPU, allowing only a specific type of variable
of fixed lengths data types. This raises issues if there are certain data
structures used in the model which act as records of multiple datasets
used by the agent such as a product inventory or biological rules. The cell
model [35] was changed from a data structure into a 1D array and stored
in memory where agents could globally read it serially. This caused a
considerable rewriting of the model itself, however it did reduce the potential processing time of the model as data were being accessed serially
rather than as dynamic data structures in the HPC version.
Message Communication between Agents. In FLAME HPC, signals
can be passed between agents as messages with each agent creating multiple messages as needed. FLAME GPU limits this to only one message
per function to be created, which limited the amount of information that
was possible with one function. The model has to be broken down to allow multiple function transitions within one function to allow messages
to be communicated, making the model quite complex or expanding
the message at times to create much more information than previously
designed. This constraint was introduced due to the manner in which
the agent threads communicate, allowing only a single message to be
synchronized per function.
Simpler versus Complex. Although both versions of grid and GPU are
suitable for simulation, the GPU version seems more suitable for simpler
model executions, with agents with basic memory allowing much faster
simulations as compared to the grid version. This makes it suitable for
game-based simulations to visualize the results quickly and where data
analysis is not an extensive requirement. However, with more complex
models such as the model of the complete European economy, with 15
different agent types with increasing complexity and multiple interactions, such models could not be processed on GPU cards.
Looping through Messages. Following is an example of looping through a
message list as defined in FLAME HPC, which allows an agent to read
through all messages in the list, and find agent id and state from the
message and record it in memory.
int MyFunction (xmachine_memory* agent, xmachine_message_list* list)
{