You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Alongside Time Series and per-individual outputs, an optional otuput containing data for each transmission event may be of interest for post processing, but come with a performance cost (due to data transfer and disk io).
It should be implemented as an optional via a cli parameter.
A subset of data included in the reference model will be emitted, incluiding:
Recipient information (id, age, house, occupancy network)
Event information (network of transmission, time)
Source information (id, age, house, occupancy network, when the source became infected)
This could then be expanded to include the duration of phases for this infection
Implementation in a flamegpu model is likely to be expensive, due to device to host data transfer and serial host implementation blocking the simulation thread from proceeding (for data correctness)
The naieve implemetnation would be:
Agents would require short term memory for additional transmission event information (time, source) which are set during infection (and potentially other state changes)
init function which prepares / initialises required host data structures
Host layer or step function which iterates agent data on the host for all agents, populating the data structures for output (and if support for very large files is desired, outputs the current data)
Exit function which finalises the data and outputs to disk
A more performant implementation would likely need to leverage FLAME GPU agent states and function conditions and use a host layer function rather than a step function. This would cause more data movement within the GPU (high bandwidth) but reduce the amount of data movement from device to host (low bandwidth) and serial iteration of data:
Agents would require short term memory for additional transmission event information (time, source) which are set during infection (and potentially other state changes)
init function which prepares / initialises required host data structures
During infection / infection state change, set an agent variable marking that there is transmission data to record
Agent function condition on the agent variable, moving the agent from the default state to a "transmission_output" state
Host layer function, which only iterates agents in the "transmission_output" state (in serial, on the host) updataing transmission file information
Agent function moving agents back to the default state.
This agent-state based approach may cause a change in behaviour for a given seed compared to without, due to how RNG states in FLAME GPU are coupled with the thread index not the FLAME GPU agent index, and after a state change agents may be in a different order.
An explicit agent sort by agent ID would resolve this, with a performance implication, alternatively this would need resolving in flame gpu (see FLAMEGPU/FLAMEGPU2#417, although a separate more specific issues should probably be created)
The text was updated successfully, but these errors were encountered:
Alongside Time Series and per-individual outputs, an optional otuput containing data for each transmission event may be of interest for post processing, but come with a performance cost (due to data transfer and disk io).
It should be implemented as an optional via a cli parameter.
A subset of data included in the reference model will be emitted, incluiding:
This could then be expanded to include the duration of phases for this infection
Implementation in a flamegpu model is likely to be expensive, due to device to host data transfer and serial host implementation blocking the simulation thread from proceeding (for data correctness)
The naieve implemetnation would be:
A more performant implementation would likely need to leverage FLAME GPU agent states and function conditions and use a host layer function rather than a step function. This would cause more data movement within the GPU (high bandwidth) but reduce the amount of data movement from device to host (low bandwidth) and serial iteration of data:
This agent-state based approach may cause a change in behaviour for a given seed compared to without, due to how RNG states in FLAME GPU are coupled with the thread index not the FLAME GPU agent index, and after a state change agents may be in a different order.
An explicit agent sort by agent ID would resolve this, with a performance implication, alternatively this would need resolving in flame gpu (see FLAMEGPU/FLAMEGPU2#417, although a separate more specific issues should probably be created)
The text was updated successfully, but these errors were encountered: